From ipsec-bounces@ietf.org Mon Aug 4 21:25: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 7AA2D3A6A9E; Mon, 4 Aug 2008 21:25:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE003A6A92 for ; Mon, 4 Aug 2008 21:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITTTM20FGxDs for ; Mon, 4 Aug 2008 21:25:03 -0700 (PDT) Received: from ns.64translator.com (ns.64translator.com [202.214.123.16]) by core3.amsl.com (Postfix) with ESMTP id 5CB473A68F3 for ; Mon, 4 Aug 2008 21:25:03 -0700 (PDT) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id m754NuNg068584 for ; Tue, 5 Aug 2008 13:24:08 +0900 (JST) (envelope-from akisada@tahi.org) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id m754Nj3P069835 for ; Tue, 5 Aug 2008 13:23:48 +0900 (JST) (envelope-from akisada@tahi.org) Date: Tue, 5 Aug 2008 13:23:12 +0900 From: Yukiyo Akisada To: ipsec@ietf.org Message-Id: <20080805132312.c9b3d252.akisada@tahi.org> Organization: TAHI Project X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Subject: [IPsec] IKEv2 tester update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, all. As I announced at 72nd IETF meeting, we, TAHI Project released IKEv2 conformance tester. In that time, v1.0.0a1 was the newest, but it contained some inconsistency from the test specification. Now, v1.0.0a2 has been ready. Please use v1.0.0a2 instead of v1.0.0a1, if you have interesting in it. It can be downloaded from . Thanks, -- Yukiyo Akisada _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 4 23:11:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3269E3A6AE4; Mon, 4 Aug 2008 23:11:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8423A6B14 for ; Mon, 4 Aug 2008 23:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 W89albu5G+Po for ; Mon, 4 Aug 2008 23:11:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A88733A689A for ; Mon, 4 Aug 2008 23:11:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CABB2294006; Tue, 5 Aug 2008 09:12:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F3A78294001 for ; Tue, 5 Aug 2008 09:12:09 +0300 (IDT) Received: from [172.31.21.149] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m756C9jI014700 for ; Tue, 5 Aug 2008 09:12:09 +0300 (IDT) Message-ID: <4897EF3A.5080003@checkpoint.com> Date: Tue, 05 Aug 2008 09:12:10 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] IKEv2 bis guidelines X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Following the Dublin meeting, we would like to clarify the charter regarding the scope of the IKEv2 bis document. General: The goal of the IKEv2 bis document is to clarify the protocol. The goal is not to extend it. Specifically: * The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarifications), but no other RFCs. * The document will add clarifications based on the community's deployment experience. * It is OK to correct minor technical errors and contradictions in the source documents. Any such corrections will be pointed out explicitly - preferably in an appendix (so that people using the old documents can scan it to discover problem areas). * The document will not add any "nice to have" extensions, no matter how much technical sense they make. Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 5 04:59:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21923A6D1E; Tue, 5 Aug 2008 04:59:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AAD3A6AE4 for ; Tue, 5 Aug 2008 04:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 ZxaYKaCrcjRc for ; Tue, 5 Aug 2008 04:59:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D66F03A6B86 for ; Tue, 5 Aug 2008 04:59:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m75BvYe09712 for ; Tue, 5 Aug 2008 11:57:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 06:59:32 -0500 Message-ID: In-Reply-To: <4897EF3A.5080003@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IKEv2 bis guidelines Thread-Index: Acj2wj2FX70R5KvdS1yfRWDzXj4+1gAL/1YA References: <4897EF3A.5080003@checkpoint.com> From: "Ahmad Muhanna" To: "Yaron Sheffer" , Subject: Re: [IPsec] IKEv2 bis guidelines X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, I agree. That should be the way to go. Thanks for the clarification! Regards, Ahmad > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Yaron Sheffer > Sent: Tuesday, August 05, 2008 1:12 AM > To: ipsec@ietf.org > Subject: [IPsec] IKEv2 bis guidelines > > Hi, > > Following the Dublin meeting, we would like to clarify the > charter regarding the scope of the IKEv2 bis document. > > General: The goal of the IKEv2 bis document is to clarify the > protocol. > The goal is not to extend it. Specifically: > > * The document will combine RFC 4306 (IKEv2) and RFC 4718 > (IKEv2 clarifications), but no other RFCs. > * The document will add clarifications based on the > community's deployment experience. > * It is OK to correct minor technical errors and > contradictions in the source documents. Any such corrections > will be pointed out explicitly - preferably in an appendix > (so that people using the old documents can scan it to > discover problem areas). > * The document will not add any "nice to have" extensions, no > matter how much technical sense they make. > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 00:05: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 785683A6819; Wed, 6 Aug 2008 00:05:09 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FC73A6819 for ; Wed, 6 Aug 2008 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 szPyy5UOfKGL for ; Wed, 6 Aug 2008 00:05:07 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id 942FD3A67DD for ; Wed, 6 Aug 2008 00:05:06 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1018308nfh.39 for ; Wed, 06 Aug 2008 00:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=Yv4MCPSbabgyl9HMSSYwoCHfD3VRX2HzS+XGGMTF4cU=; b=v/j4FllKge4A9FewkfcBIGoZPosG2A3NFbkbaYr2SR4b4R3ZN6B5Gh1bTLdpyjvkDX sIdMbPdBzJ0cMwgD/AjKk/755aF5XcxhkWfxkPDUpznQgoLDOzTci1TM8C9AUt7dF3zh pvU8QkHtGQZAS3eNzNhH2yl9R9OXCrIImvH08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=gq4HWzlSMZ6Ji47s/mnMoh5bsTO5+yEKduol9nEQJRKwLLjwn79MXYr5fi3K1TptfR 1ImPS16gZFWCGVJQ2wSVcHLN9BKhlSPM0VfjqQa2eV6co+E+LA+17U37m+CTifsfRMd1 ZA01n+ByyyI+1+H99GxH7sY51N0ST4pPfvaEE= Received: by 10.210.76.12 with SMTP id y12mr2100846eba.151.1218006338355; Wed, 06 Aug 2008 00:05:38 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t2sm668458gve.9.2008.08.06.00.05.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 06 Aug 2008 00:05:37 -0700 (PDT) To: ipsec@ietf.org Date: Wed, 6 Aug 2008 09:05:39 +0200 User-Agent: KMail/1.9.9 References: <18573.51130.528112.634560@fireball.kivinen.iki.fi> In-Reply-To: <18573.51130.528112.634560@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808060905.39540.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: pasi.eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, On Monday 28 July 2008, Tero Kivinen wrote: > > 6. =A0Solution Sketch > > 6.1. =A0Initial Exchanges > > > > =A0 =A01) During IKE_AUTH, the client sends a new configuration > > attribute, INTERNAL_IP6_LINK, which requests a virtual link to be > > created. =A0The attribute contains the client's interface ID for > > link-local address (other addresses may use other interface IDs). > > =A0Typically, the client would also ask for DHCPv6 server address; > > this is used only for configuration, not address assignment. > > ... > > > =A0 =A0(To be determined: is it necessary to include the gateway's > > link- local interface ID? =A0Probably the client does not need it.) > > I do not think clinet needs the gateway's link-local interface ID, > and in that case we can change the INTERNAL_IP6_LINK attribute to > follow the standard rule almost all other attributes use, i.e. client > proposes something, and server replies with the acceptable value. > I.e. client would send its own link-local interface ID (and > optionally IKEv2 Link ID) to the server in INTERNAL_IP6_LINK and > server would reply with that same link-local interface ID to verify > that client is allowed to use that address (and the IKEv2 link ID). I'm understanding this as implying it's possible that the gateway = replies with a different link-local interface ID which have to be used = by the client. = If that is a correct understanding, note that the client would in this = case be prevented to use a link-local CGA it generated prior to = initiating, and proposed in the IKE_AUTH. If we are going with that configuration payload semantic (i.e., client = proposes something, and server replies with the acceptable value) then = we should specify that the gateway MUST reply with the link-local = interface ID that the client "proposed", and MUST choose for itself a = link-local address that doesn't collide with that of the client. This would maintain the semantic of the configuration payloads, and = avoid link-local address collisions. Thoughts? --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 06:35:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DB328C33F; Wed, 6 Aug 2008 06:35:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073FD28C2A4 for ; Wed, 6 Aug 2008 06:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 Hql2fQmZTi8x for ; Wed, 6 Aug 2008 06:35:22 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0DAAA3A68AE for ; Wed, 6 Aug 2008 06:35:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7C9E4294004; Wed, 6 Aug 2008 16:35:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 570D8294003 for ; Wed, 6 Aug 2008 16:35:36 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m76DZZjI020329 for ; Wed, 6 Aug 2008 16:35:36 +0300 (IDT) Message-ID: <4899A8A1.7040808@checkpoint.com> Date: Wed, 06 Aug 2008 16:35:29 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] Motivation for ESP-null marking X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Although we have a charter item on special marking of ESP packets with null encryption, there have been some questions raised about the rationale for doing this. No matter which solution we choose, this is a very fundamental protocol addition (layer 3, directly handled by hardware), so Paul and I would like to have one more round of discussion on whether this is really needed. Let us ignore the details of the solution proposals for a while (1 protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), and consider whether there is a need to have any solution at all for this problem: * What is the security/threat environment that we are dealing with? In other words, what is the security policy for which we want an efficient enforcement? * Are there alternative ways to detect unencrypted traffic in the existing ESP, e.g. heuristics? Are they easy to implement in software or in hardware? How significant is the problem of false positives? * For a "reasonable security policy" (as above) can we provide a hardware-only enforcement solution with current technology, or do we have to send every packet into software (general CPU or network processor)? And if software is involved, does it make the entire "efficient to implement in hardware" discussion irrelevant? When you respond, please describe your personal or your company's experience with hardware-based packet processing, for extra points :-) Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 07:21:38 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 17E553A6CF2; Wed, 6 Aug 2008 07:21:38 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43EC28C0FC for ; Wed, 6 Aug 2008 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 8ibipIjHTqcn for ; Wed, 6 Aug 2008 07:21:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6E65C3A6CF2 for ; Wed, 6 Aug 2008 07:21:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 48F8E294003; Wed, 6 Aug 2008 17:22:05 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7DBCC294001 for ; Wed, 6 Aug 2008 17:22:04 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m76EM4jI004577 for ; Wed, 6 Aug 2008 17:22:04 +0300 (IDT) Message-Id: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 17:22:03 +0300 X-Mailer: Apple Mail (2.928.1) Subject: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966223390==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0966223390== Content-Type: multipart/signed; boundary=Apple-Mail-3--792844844; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-3--792844844 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This is a followup to my mini-presentation in Dublin. The problem we're trying to solve is that of a state de- synchronization between two IKE peers. This could take several minutes to discover and resolve, and no IPsec traffic can flow in that time. The following Wiki page describes the problem, and two proposed solutions. http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery We would like to solicit input from the WG about these two solutions, so that we can either combine them or choose between them, and proceed with a unified draft. Thanks in advance Frederic, Pratima and Yoav --Apple-Mail-3--792844844 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgwNjE0 MjIwM1owIwYJKoZIhvcNAQkEMRYEFNqyh9HBbi66KqZ5mlsawzuezW+jMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQAZDhchfhaC zS/Fn3+TW+f8AgclfeoFJGGqlgbA6jAYL6YG6Jrb6fV6v3wlfBPXboOP38W2MugUa587sHja7+Wm O6wKXI8M4SpvK4k7qMwRagLMLblkOHpJS2hODlDsrW/D3HvgunvNAk67scG2YpRvwDU6E5vny7Vz GrG78CjteLyyi5MlHwrRWc68PoYcYiSL3+FbxHh2GourE35G0zJO7ZUICsp2v3AcY2zKj1Br9IA/ JamGbfbMNdO0ltsy1i7KDvyLChT2zB3A3ATgQkHVLjE1B1FGE3l4O2Qu+zadPk1euv+ha2MXyjDs QK33zK1KuGYsl5CPc8oYyn1rZOgzAAAAAAAA --Apple-Mail-3--792844844-- --===============0966223390== 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 --===============0966223390==-- From ipsec-bounces@ietf.org Wed Aug 6 09:46:38 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 8AECA3A67D4; Wed, 6 Aug 2008 09:46:38 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826223A67D4 for ; Wed, 6 Aug 2008 09:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 tagged_above=-999 required=5 tests=[AWL=1.724, 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 8CeG6dWN5nCo for ; Wed, 6 Aug 2008 09:46:36 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 9911D3A67B4 for ; Wed, 6 Aug 2008 09:46:36 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m76Gl8DM017425 for ; Wed, 6 Aug 2008 16:47:08 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m76Gl7OO018887 for ; Wed, 6 Aug 2008 10:47:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76Gl6J9010971; Wed, 6 Aug 2008 11:47:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76Gl4Z4010970; Wed, 6 Aug 2008 11:47:04 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 6 Aug 2008 11:47:04 -0500 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20080806164703.GA25547@Sun.COM> Mail-Followup-To: Yaron Sheffer , ipsec@ietf.org References: <4899A8A1.7040808@checkpoint.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4899A8A1.7040808@checkpoint.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] Motivation for ESP-null marking 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 Wed, Aug 06, 2008 at 04:35:29PM +0300, Yaron Sheffer wrote: > Let us ignore the details of the solution proposals for a while (1 > protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), > and consider whether there is a need to have any solution at all for > this problem: > > * What is the security/threat environment that we are dealing with? > In other words, what is the security policy for which we want an > efficient enforcement? Clearly the security policy would be: use confidentiality protection. Of course, there's no way to ensure that the SAs' keys haven't be made public or otherwise shared with interested third parties. That's what makes ESP-null marking seem silly -- it's like the reverse of the "secure" bit gag, an "insecure" bit which tells you nothing about the security of packets that don't have that bit set. One might argue that middle box enforcement of confidentiality protection policies adds some value where you can trust end nodes not to reveal their secret keys. But in such an environment you might as well assume that end nodes have the correct policies too, and so there's no need to enforce those policies in middle boxes. > * Are there alternative ways to detect unencrypted traffic in the > existing ESP, e.g. heuristics? Are they easy to implement in > software or in hardware? How significant is the problem of false > positives? I suspect there'd be enough header content, even in transport mode ESP payloads, that simple heuristics are workable. Whether such heuristics are easy to implement in hardware is another story. Of course, this still does nothing for the case where the end nodes are sharing their secret keys with third parties. > * For a "reasonable security policy" (as above) can we provide a > hardware-only enforcement solution with current technology, or do > we have to send every packet into software (general CPU or network > processor)? And if software is involved, does it make the entire > "efficient to implement in hardware" discussion irrelevant? An "insecure" bit is trivial to check in hardware. It's also useless (see above). > When you respond, please describe your personal or your company's > experience with hardware-based packet processing, for extra points :-) Sun has quite a bit of experience with hardware-based packet processing (think of the Neptune NIC); I don't have any direct experience with it -- that doesn't stop me from telling you my opinion of the value of this "insecure" bit as the hardware aspects aren't relevant to that issue. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 09:49: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 A893F3A6903; Wed, 6 Aug 2008 09:49:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDE23A68D7 for ; Wed, 6 Aug 2008 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xufvxRXaRsa7 for ; Wed, 6 Aug 2008 09:45:28 -0700 (PDT) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) by core3.amsl.com (Postfix) with ESMTP id 49A133A68F1 for ; Wed, 6 Aug 2008 09:45:22 -0700 (PDT) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 6 Aug 2008 09:43:37 -0700 From: Soo-Fei Chew To: "ipsec@ietf.org" Date: Wed, 6 Aug 2008 09:43:47 -0700 Thread-Topic: Clarification on Protocol ID Thread-Index: Acj345i15THQbKkcSUOP4UYOV3zsPw== Message-ID: <50DADDE6B33B1B47904E685AAFDC182410176326E6@yugi.mocana.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] Clarification on Protocol ID 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="===============1846910670==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1846910670== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_50DADDE6B33B1B47904E685AAFDC182410176326E6yugimocanaloc_" --_000_50DADDE6B33B1B47904E685AAFDC182410176326E6yugimocanaloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Can you clarify about the Protocol ID as follows: When the initiator 'retries' IKE_SA_INIT with a COOKIE Notify Payload (with= responder supplied cookie data), should the Protocol ID be 0 or 1? In this= case, it does involve an existing SA as far as the initiator is concerned. --SNIP rfc 4306 Section 3.10 --- o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. --SNIP rfc 4306 Section 3.10 --- Thanks, SooFei --_000_50DADDE6B33B1B47904E685AAFDC182410176326E6yugimocanaloc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Can you clarify about the Protocol ID = as follows:

 

When the initiator ‘retries̵= 7; IKE_SA_INIT with a COOKIE Notify Payload (with responder supplied cookie da= ta), should the Protocol ID be 0 or 1? In this case, it does involve an existing= SA as far as the initiator is concerned.

 

--SNIP rfc 4306 Section 3.10 ---
o  Protocol ID (1 octet) - If this notification concerns an existing
      SA, this fiel= d indicates the type of that SA.  For IKE_SA
      notifications= , this field MUST be one (1). = For notifications
      concerning IP= sec SAs this field MUST contain = either (2) to
      indicate AH o= r (3) to indicate ESP.  For notifications that do not
      relate to an existing SA, this field MUST= be sent as zero and MUST=
      be ignored on receipt.  All other values for this field are
      reserved to I= ANA for future assignment.
--SNIP rfc 4306 Section 3.10 ---<= /font>

 

Thanks,

SooFei

--_000_50DADDE6B33B1B47904E685AAFDC182410176326E6yugimocanaloc_-- --===============1846910670== 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 --===============1846910670==-- From ipsec-bounces@ietf.org Wed Aug 6 09:56: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 231A73A67D4; Wed, 6 Aug 2008 09:56:29 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BFE3A63EC for ; Wed, 6 Aug 2008 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=1.436, 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 QNv9jFSKF9T2 for ; Wed, 6 Aug 2008 09:56:27 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id C2B273A63CB for ; Wed, 6 Aug 2008 09:56:26 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m76GuqAj024509 for ; Wed, 6 Aug 2008 16:56:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m76Guqlb024792 for ; Wed, 6 Aug 2008 10:56:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76GupjQ010987; Wed, 6 Aug 2008 11:56:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76GupnH010986; Wed, 6 Aug 2008 11:56:51 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 6 Aug 2008 11:56:51 -0500 From: Nicolas Williams To: Yaron Sheffer , ipsec@ietf.org Message-ID: <20080806165650.GB25547@Sun.COM> Mail-Followup-To: Yaron Sheffer , ipsec@ietf.org References: <4899A8A1.7040808@checkpoint.com> <20080806164703.GA25547@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080806164703.GA25547@Sun.COM> User-Agent: Mutt/1.5.7i Subject: Re: [IPsec] Motivation for ESP-null marking 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 should add that without ESP-null middle box filtering that requires the use of ESP is, indeed, filtering on the basis of an "insecure" bit since there's no way for the middle box to ensure that IPsec and ESP are actually being used correctly. And yet I wouldn't advocate that middle boxes don't filter on the basis of whether or not ESP is being used. Therefore I suppose that checking for an ESP-null marker is no different than checking for ESP in the first place. And that if one would not oppose the latter then one should not oppose the former. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 13:07: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 2E25D3A6AD1; Wed, 6 Aug 2008 13:07:11 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2513A680B for ; Wed, 6 Aug 2008 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 5S6VWOKFtIEy for ; Wed, 6 Aug 2008 13:07:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D3EFD3A6A24 for ; Wed, 6 Aug 2008 13:07:08 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 66AEE294001; Wed, 6 Aug 2008 23:07:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8BB6B294002; Wed, 6 Aug 2008 23:07:36 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m76K7ajP001241; Wed, 6 Aug 2008 23:07:36 +0300 (IDT) Message-Id: From: Yoav Nir To: Nicolas Williams In-Reply-To: <20080806164703.GA25547@Sun.COM> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 23:07:31 +0300 References: <4899A8A1.7040808@checkpoint.com> <20080806164703.GA25547@Sun.COM> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Motivation for ESP-null marking 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="===============0774003354==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0774003354== Content-Type: multipart/signed; boundary=Apple-Mail-4--772116934; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-4--772116934 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote: >> * What is the security/threat environment that we are dealing with? >> In other words, what is the security policy for which we want an >> efficient enforcement? > > Clearly the security policy would be: use confidentiality protection. > > Of course, there's no way to ensure that the SAs' keys haven't be made > public or otherwise shared with interested third parties. That's what > makes ESP-null marking seem silly -- it's like the reverse of the > "secure" bit gag, an "insecure" bit which tells you nothing about the > security of packets that don't have that bit set. I don't think this was the author's intention. The two parties could of course use AES and post their secret keys to Wikipedia, but if the policy is to drop marked ESP-NULL packets, all the parties really have to do, is to negotiate ESP-NULL and use the old ESP with no markings. I think the policy is "don't send encrypted stuff out, because I (the middlebox) want to deep inspect all traffic". That would translate to dropping all ESP-non-NULL traffic. Otherwise, I agree that an "insecure" bit is ridiculous. A "deep inspection welcome" bit is less so. But you can't just pass the packet marked as ESP-NULL - you need to really make sure they're not running encrypted stuff, and also you need to deep inspect. So the question is whether it really adds any processing time to make sure a packet is really not encrypted, given that you're running all kinds of other filtering. --Apple-Mail-4--772116934 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgwNjIw MDczMVowIwYJKoZIhvcNAQkEMRYEFFjFUnMUk+6Q8jW1Z35HrtX4KHkWMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQAk9lVhm9GT T8+9L6NHJPcLfefLVfXekcuIkzGivBKSWy7yMDdCwqghXCBM8bfJJSOxeyyVu6PwMokjw728EPZA sPHpyMg3F1hWjOovWMe5LfyFa/e6UOUC+CEarfcBjUVQ0E8FeRLVeOqEi020BW9odTFZEblAl1Af S8Vo8dgLC6PaJa3bmEFB+LrmjGknEAy84+zPzDC16pMthObzjMQ9GSU8ymETDrjn47FoM5pO7Y82 2nIwpmb/20ygEud8wri8/mrCF9z3/kmU80rFo2UPQExCGfzbK8/WOd+WyJmG7hR6snXdDzsZy27y DoAN24cQwg7FCS0soN3DAP19HeylAAAAAAAA --Apple-Mail-4--772116934-- --===============0774003354== 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 --===============0774003354==-- From ipsec-bounces@ietf.org Wed Aug 6 13:11: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 45D5A3A6A33; Wed, 6 Aug 2008 13:11:42 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA1C3A6A33 for ; Wed, 6 Aug 2008 13:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 2geDIPE4l1rI for ; Wed, 6 Aug 2008 13:11:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DD8263A695D for ; Wed, 6 Aug 2008 13:11:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AB572294003; Wed, 6 Aug 2008 23:12:13 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 785EE294002; Wed, 6 Aug 2008 23:12:12 +0300 (IDT) Received: from [172.31.21.60] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m76KCBjI002356; Wed, 6 Aug 2008 23:12:11 +0300 (IDT) Message-Id: From: Yoav Nir To: Nicolas Williams In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 23:12:11 +0300 References: <4899A8A1.7040808@checkpoint.com> <20080806164703.GA25547@Sun.COM> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Motivation for ESP-null marking 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="===============1173220011==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1173220011== Content-Type: multipart/signed; boundary=Apple-Mail-7--771837287; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-7--771837287 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thinking it over, it doesn't have to be very deep inspection. It could be as simple as "drop all FTP, even if it's tunneled" On Aug 6, 2008, at 11:07 PM, Yoav Nir wrote: > > On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote: > > >>> * What is the security/threat environment that we are dealing with? >>> In other words, what is the security policy for which we want an >>> efficient enforcement? >> >> Clearly the security policy would be: use confidentiality protection. >> >> Of course, there's no way to ensure that the SAs' keys haven't be >> made >> public or otherwise shared with interested third parties. That's >> what >> makes ESP-null marking seem silly -- it's like the reverse of the >> "secure" bit gag, an "insecure" bit which tells you nothing about the >> security of packets that don't have that bit set. > > I don't think this was the author's intention. The two parties could > of course use AES and post their secret keys to Wikipedia, but if > the policy is to drop marked ESP-NULL packets, all the parties > really have to do, is to negotiate ESP-NULL and use the old ESP with > no markings. > > I think the policy is "don't send encrypted stuff out, because I > (the middlebox) want to deep inspect all traffic". That would > translate to dropping all ESP-non-NULL traffic. Otherwise, I agree > that an "insecure" bit is ridiculous. A "deep inspection welcome" > bit is less so. > > But you can't just pass the packet marked as ESP-NULL - you need to > really make sure they're not running encrypted stuff, and also you > need to deep inspect. So the question is whether it really adds any > processing time to make sure a packet is really not encrypted, given > that you're running all kinds of other filtering. --Apple-Mail-7--771837287 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgwNjIw MTIxMVowIwYJKoZIhvcNAQkEMRYEFEqlflogqNiOegbaqqzYeA21SOplMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQAb193Vd3Dm NgIHNnZUF781hWJ6RUEnRAZvDR8BhmXaIbUgwK2x+HHq3Lk5w4lsB1Pzn76c7zzpDExeQAZR8Ozs lKJzw6K0XKZfia6+JOHofZm/qz4YlX2DMi0txA9aWyMxjz+XG6EAa0kXidBRuVUIDLPF603V3PS3 9d2oqfqn/3NKbp0lZ3ubvjlE/b3qKmS+fRq7BkfNwb9N014gLjUjRpBPbTF7nM99wOmTB0E0LAv6 cJI6B/aIPwdW6JBTDoR6vvrfiQQg97KkirS1wlZH9sLq8pRWTFfigdlYdnPqMeEuvA5dVJe34kuX KYbZScIpvPff1/hHQFYnRXmv+VY6AAAAAAAA --Apple-Mail-7--771837287-- --===============1173220011== 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 --===============1173220011==-- From ipsec-bounces@ietf.org Wed Aug 6 17:08: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 9E8163A6B13; Wed, 6 Aug 2008 17:08:33 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6443A6B3C for ; Wed, 6 Aug 2008 17:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU+q4aqLXSQn for ; Wed, 6 Aug 2008 17:08:30 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id B049D3A6B0B for ; Wed, 6 Aug 2008 17:08:30 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 06 Aug 2008 17:07:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.31,317,1215414000"; d="scan'208";a="323859557" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga002.jf.intel.com with ESMTP; 06 Aug 2008 17:09:29 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 17:09:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 17:08:08 -0700 Message-ID: In-Reply-To: <4899A8A1.7040808@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Motivation for ESP-null marking Thread-Index: Acj3yWAmKvWaSt/YQzSrUd7QlhMCNwAOdxZA References: <4899A8A1.7040808@checkpoint.com> From: "Grewal, Ken" To: "Yaron Sheffer" , X-OriginalArrivalTime: 07 Aug 2008 00:09:03.0605 (UTC) FILETIME=[CCF18A50:01C8F821] Subject: Re: [IPsec] Motivation for ESP-null marking X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, All, Some comments inline... Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Yaron Sheffer >Sent: Wednesday, August 06, 2008 6:35 AM >To: ipsec@ietf.org >Subject: [IPsec] Motivation for ESP-null marking > > >Hi, > > >Although we have a charter item on special marking of ESP packets with >null encryption, there have been some questions raised about the >rationale for doing this. No matter which solution we choose, this is a >very fundamental protocol addition (layer 3, directly handled by >hardware), so Paul and I would like to have one more round of discussion >on whether this is really needed. > > >Let us ignore the details of the solution proposals for a while (1 >protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), >and consider whether there is a need to have any solution at all for >this problem: [Ken] I am surprised that there are questions being raised about this goal, given that its presence in the charter indicates that it's a worthy one. Are there any strong arguments for reversing that consensus? > > * What is the security/threat environment that we are dealing with? > In other words, what is the security policy for which we want an > efficient enforcement? [Ken] This solution is targeting an environment where intermediary devices would like to inspect the packet on route and optionally make access control decisions based on local policy and the results of the packet inspection. Some examples of policies are: Dropping packets with certain characteristics (based on protocol / port or deeper inspection). E.g. Do not allow any encrypted data; Allow encrypted data to only these systems; Do not allow FTP/TFTP traffic between these endpoints, but allow for others. The list goes on...basically any 5-tuple firewall rules + additional enforcement based on payload examination and intrusion prevention. In order to make these decisions, the packets needs to be inspected and the current IPsec ESP spec does not allow you to infer if the packet is encrypted or in the clear (ESP-NULL). This has been a deployment barrier to using IPsec in Enterprise environments as IT departments would like to employ E2E security, but not at the cost of circumventing existing network monitoring / diagnostics tools. This charter item is looking at removing this barrier and allowing IPsec to be employed in these environments. > * Are there alternative ways to detect unencrypted traffic in the > existing ESP, e.g. heuristics? Are they easy to implement in > software or in hardware? How significant is the problem of false > positives? [Ken] Heuristics will never be free of false positives, all we can do is play the probability game and reduce false positives to a very small value. False positives have a high cost as they can lead to incorrectly applying policies (e.g. because we falsely determine that an ESP encrypted packet is ESP-NULL) and can cause almost impossible-to-diagnose network glitches (e.g. which packet(s) out of the millions being processed actually generated the false positives). Heuristics can also become very complex with numerous rules to cater for different protocols / payloads (including catering for the protocols of tomorrow). As for employing heuristics in SW Vs. HW, this is really implementation dependent. Having said that, in the multi-core environment of today, numerous vendors employ IO acceleration techniques in HW for fast data movement between the HW (e.g. NIC) and SW components. These techniques are needed to ensure that data is moved directly to the correct CPU/NPU core, which is the consumer of that data. These decisions are typically based on stream identifiers (e.g. 5-tuples in the packet) to ensure full load-balancing capabilities between the multiple cores. In order to make these decisions, the HW needs to extract this data and hence any heuristics would need to run in the HW. Implementing heuristics in HW is very costly, compared with our proposed approach of an ESP wrapper. > * For a "reasonable security policy" (as above) can we provide a > hardware-only enforcement solution with current technology, or do > we have to send every packet into software (general CPU or network > processor)? And if software is involved, does it make the entire > "efficient to implement in hardware" discussion irrelevant? > [Ken] Please see above - HW demuxing is needed. >When you respond, please describe your personal or your company's >experience with hardware-based packet processing, for extra points :-) How many points and what is the value? :-) Perhaps we can discuss this offline... > >Thanks, > > Yaron > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 17:13: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 A64D33A6B42; Wed, 6 Aug 2008 17:13:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A103A6B56 for ; Wed, 6 Aug 2008 17:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNR3lI9kymWc for ; Wed, 6 Aug 2008 17:13:30 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id CD9D13A6812 for ; Wed, 6 Aug 2008 17:13:30 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 06 Aug 2008 17:14:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.31,317,1215414000"; d="scan'208";a="30666455" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 06 Aug 2008 17:14:05 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 17:14:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 17:13:13 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Motivation for ESP-null marking Thread-Index: Acj4AB0oPeuNf889SryiseLZHNmFjwAIZzBw References: <4899A8A1.7040808@checkpoint.com> <20080806164703.GA25547@Sun.COM> From: "Grewal, Ken" To: "Yoav Nir" , "Nicolas Williams" X-OriginalArrivalTime: 07 Aug 2008 00:14:04.0613 (UTC) FILETIME=[805BB750:01C8F822] Cc: ipsec@ietf.org Subject: Re: [IPsec] Motivation for ESP-null marking 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 Yoav - you hit the nail on the head and I do like the 'deep inspection welcome' bit instead of the 'insecure bit', as the packet is still integrity protected. As for the processing time overhead, please see my other response on this thread where the proposed solution is deterministic and 'HW friendly', as well as motivation for doing this in HW. Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Yoav Nir >Sent: Wednesday, August 06, 2008 1:08 PM >To: Nicolas Williams >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Motivation for ESP-null marking > > >On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote: > > >>> * What is the security/threat environment that we are dealing with? >>> In other words, what is the security policy for which we want an >>> efficient enforcement? >> >> Clearly the security policy would be: use confidentiality protection. >> >> Of course, there's no way to ensure that the SAs' keys haven't be made >> public or otherwise shared with interested third parties. That's what >> makes ESP-null marking seem silly -- it's like the reverse of the >> "secure" bit gag, an "insecure" bit which tells you nothing about the >> security of packets that don't have that bit set. > >I don't think this was the author's intention. The two parties could >of course use AES and post their secret keys to Wikipedia, but if the >policy is to drop marked ESP-NULL packets, all the parties really have >to do, is to negotiate ESP-NULL and use the old ESP with no markings. > >I think the policy is "don't send encrypted stuff out, because I (the >middlebox) want to deep inspect all traffic". That would translate to >dropping all ESP-non-NULL traffic. Otherwise, I agree that an >"insecure" bit is ridiculous. A "deep inspection welcome" bit is less >so. > >But you can't just pass the packet marked as ESP-NULL - you need to >really make sure they're not running encrypted stuff, and also you >need to deep inspect. So the question is whether it really adds any >processing time to make sure a packet is really not encrypted, given >that you're running all kinds of other filtering. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 6 19:20: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 C77BA3A6909; Wed, 6 Aug 2008 19:20:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623D93A6909 for ; Wed, 6 Aug 2008 19:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=1.551, 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 OqLl87QOICKp for ; Wed, 6 Aug 2008 19:20:43 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 95E7D3A6864 for ; Wed, 6 Aug 2008 19:20:43 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m772Krma016743 for ; Thu, 7 Aug 2008 02:20:57 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m772Kq7C053486 for ; Wed, 6 Aug 2008 20:20:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m772Kpxq011422; Wed, 6 Aug 2008 21:20:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m772KoaO011421; Wed, 6 Aug 2008 21:20:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 6 Aug 2008 21:20:50 -0500 From: Nicolas Williams To: "Grewal, Ken" Message-ID: <20080807022050.GV25547@Sun.COM> Mail-Followup-To: "Grewal, Ken" , Yoav Nir , ipsec@ietf.org References: <4899A8A1.7040808@checkpoint.com> <20080806164703.GA25547@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Motivation for ESP-null marking 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 Wed, Aug 06, 2008 at 05:13:13PM -0700, Grewal, Ken wrote: > Thanks Yoav - you hit the nail on the head and I do like the 'deep > inspection welcome' bit instead of the 'insecure bit', as the packet is > still integrity protected. Yes, that makes more sense. Middle boxes will still need to apply some heuristics to decide whether such packets are indeed in the clear, but that will be easy if the policies it applies require inspecting tunneled next protocol headers. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 7 13:09: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 131F93A698D; Thu, 7 Aug 2008 13:09:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F5C3A69A3 for ; Thu, 7 Aug 2008 13:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVD61GZiMi1l for ; Thu, 7 Aug 2008 13:09:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1888A3A698D for ; Thu, 7 Aug 2008 13:09:46 -0700 (PDT) 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 m77K9EaV025391; Thu, 7 Aug 2008 23:09:15 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 23:09:14 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 23:09:13 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 23:09:12 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> In-Reply-To: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Secure Crash Discovery for IKEv2 Thread-Index: Acj3z9mFSQATUfy8SXi3jSgcRaT+UQA9mfmg References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 20:09:13.0821 (UTC) FILETIME=[766080D0:01C8F8C9] X-Nokia-AV: Clean Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Couple of comments (not wearing any hats): I like the QCD proposal -- it's simple, and doesn't seem to change the security properties of IKE (unlike the SIR proposal; more below). On the web page, you asked for comments about "constrained devices" like cell phones. For a cell phone that can implement IKEv2, keeping 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA and ESP/AH SAs is anyway much more). The SIR proposal, on the other hand, relies on totally unauthenticated exchange. You can treat it as a hint and wait until you're sure you're not going to get a real authenticated response -- but then it's not clear why it's better than normal INVALID_IKE_SPI notification. And if you treat it as something else than hint (and don't wait long time to hear from the real server), you're exposing yourself to DoS that wasn't possible earlier. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Yoav Nir > Sent: 06 August, 2008 17:22 > To: ipsec@ietf.org > Subject: [IPsec] Secure Crash Discovery for IKEv2 > > This is a followup to my mini-presentation in Dublin. > > The problem we're trying to solve is that of a state de- > synchronization between two IKE peers. This could take > several minutes > to discover and resolve, and no IPsec traffic can flow in that time. > > The following Wiki page describes the problem, and two proposed > solutions. > > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery > > We would like to solicit input from the WG about these two > solutions, > so that we can either combine them or choose between them, > and proceed > with a unified draft. > > Thanks in advance > > Frederic, Pratima and Yoav > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 7 13:11: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 99E383A698A; Thu, 7 Aug 2008 13:11:31 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EDCF3A698A for ; Thu, 7 Aug 2008 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.866, 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 IJphmTsrCeq2 for ; Thu, 7 Aug 2008 13:11:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A50013A6819 for ; Thu, 7 Aug 2008 13:11:28 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77KAkHr027371; Thu, 7 Aug 2008 23:11:00 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 23:10:25 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 23:10:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 23:10:12 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C6296@vaebe104.NOE.Nokia.com> In-Reply-To: <50DADDE6B33B1B47904E685AAFDC182410176326E6@yugi.mocana.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on Protocol ID Thread-Index: Acj345i15THQbKkcSUOP4UYOV3zsPwA5epkQ References: <50DADDE6B33B1B47904E685AAFDC182410176326E6@yugi.mocana.local> From: To: , X-OriginalArrivalTime: 07 Aug 2008 20:10:12.0772 (UTC) FILETIME=[9983B640:01C8F8C9] X-Nokia-AV: Clean Subject: Re: [IPsec] Clarification on Protocol ID 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="===============1601428424==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1601428424== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F8C9.996EA573" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F8C9.996EA573 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi SooFei, =20 Take a look at RFC 4718, Section 7.8. =20 Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of ext Soo-Fei Chew Sent: 06 August, 2008 19:44 To: ipsec@ietf.org Subject: [IPsec] Clarification on Protocol ID =09 =09 Hi =20 Can you clarify about the Protocol ID as follows: =20 When the initiator 'retries' IKE_SA_INIT with a COOKIE Notify Payload = (with responder supplied cookie data), should the Protocol ID be 0 or 1? = In this case, it does involve an existing SA as far as the initiator is = concerned. =20 --SNIP rfc 4306 Section 3.10 --- o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do = not relate to an existing SA, this field MUST be sent as zero and = MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. --SNIP rfc 4306 Section 3.10 --- =20 Thanks, SooFei ------_=_NextPart_001_01C8F8C9.996EA573 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi SooFei,
 
Take a look at RFC 4718, Section=20 7.8.
 
Best regards,
Pasi

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei=20 Chew
Sent: 06 August, 2008 19:44
To:=20 ipsec@ietf.org
Subject: [IPsec] Clarification on Protocol=20 ID

Hi

 

Can you = clarify about=20 the Protocol ID as follows:

 

When the = initiator=20 =91retries=92 IKE_SA_INIT with a COOKIE Notify Payload (with responder = supplied=20 cookie data), should the Protocol ID be 0 or 1? In this case, it does = involve=20 an existing SA as far as the initiator is=20 concerned.

 

--SNIP rfc 4306 Section 3.10=20 ---
o  Protocol ID (1 octet) - If this = notification=20 concerns an existing
      SA, this field = indicates the=20 type of that SA.  For IKE_SA
      notifications, = this=20 field MUST be one = (1).  For=20 notifications
      concerning IPsec = SAs this=20 field MUST contain = either (2)=20 to
     =20 indicate AH or (3) to indicate ESP.  For notifications that do=20 not
     =20 relate to an existing SA, this field=20 MUST be sent as zero and=20 MUST
      be ignored on = receipt. =20 All other values for this field are
      reserved to IANA = for future=20 assignment.
--SNIP rfc = 4306=20 Section 3.10 ---

 

Thanks,

SooFei

------_=_NextPart_001_01C8F8C9.996EA573-- --===============1601428424== 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 --===============1601428424==-- From ipsec-bounces@ietf.org Thu Aug 7 14:15:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7770B28C1A5; Thu, 7 Aug 2008 14:15:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6847C28C1A5 for ; Thu, 7 Aug 2008 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nikwyZaJ6nj3 for ; Thu, 7 Aug 2008 14:15:44 -0700 (PDT) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) by core3.amsl.com (Postfix) with ESMTP id 1517928C165 for ; Thu, 7 Aug 2008 14:15:43 -0700 (PDT) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Thu, 7 Aug 2008 14:13:24 -0700 From: Soo-Fei Chew To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Thu, 7 Aug 2008 14:13:11 -0700 Thread-Topic: [IPsec] Clarification on Protocol ID Thread-Index: Acj345i15THQbKkcSUOP4UYOV3zsPwA5epkQAAIKqmA= Message-ID: <50DADDE6B33B1B47904E685AAFDC182410176327C6@yugi.mocana.local> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C6296@vaebe104.NOE.Nokia.com> 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] Clarification on Protocol ID 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="===============0688780547==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0688780547== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_50DADDE6B33B1B47904E685AAFDC182410176327C6yugimocanaloc_" --_000_50DADDE6B33B1B47904E685AAFDC182410176327C6yugimocanaloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi If combine RFC4718 7.8 and the following statements in RFC 4306, then it se= ems to indicate that a Protocol ID of 1 with an empty SPI should never exis= t!! 3.10. Notify Payload ... o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). ... o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. 7.8. Protocol ID/SPI Fields in Notify Payloads Section 3.10 says that the Protocol ID field in Notify payloads "For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt". However, the specification does not clearly say which notifications are related to existing SAs and which are not. Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty. There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA. Thanks, -SooFei ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 1:10 PM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] Clarification on Protocol ID Hi SooFei, Take a look at RFC 4718, Section 7.8. Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Soo-Fei Chew Sent: 06 August, 2008 19:44 To: ipsec@ietf.org Subject: [IPsec] Clarification on Protocol ID Hi Can you clarify about the Protocol ID as follows: When the initiator 'retries' IKE_SA_INIT with a COOKIE Notify Payload (with= responder supplied cookie data), should the Protocol ID be 0 or 1? In this= case, it does involve an existing SA as far as the initiator is concerned. --SNIP rfc 4306 Section 3.10 --- o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. --SNIP rfc 4306 Section 3.10 --- Thanks, SooFei --_000_50DADDE6B33B1B47904E685AAFDC182410176327C6yugimocanaloc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

If combine RFC4718 7.8 and the followi= ng statements in RFC 4306, then it seems to indicate that a Protocol ID of 1 w= ith an empty SPI should never exist!!

 

3.10.  Notify Paylo= ad

…

   o  Protocol ID (1 octet) - If = this notification concerns an existing

      SA, this field indicates the type of that SA.  For IKE_SA

      notifications, th= is field MUST be one (1). …<= /p>

 

   o  SPI Size (1 octet) - Length= in octets of the SPI as defined by the

      IPsec protocol ID= or zero if no SPI is applicable.  For a

      notification concerning the IKE_SA, the SPI Size MUS= T be zero.

 

7.8.  Protocol ID/SPI Fields in No= tify Payloads

 

   Section 3.10 says that the Protocol= ID field in Notify payloads "For

   notifications that do not relate to= an existing SA, this field MUST=

   be sent as zero and MUST be ignored on receipt".&nbs= p; However, the

   specification does not clearly say which notifications are related to

   existing SAs and which are not.

 

   Since the main purpose of the Proto= col ID field is to specify the

   type of the SPI, our interpretation= is that the Protocol ID field

   should be non-zero only when the SP= I field is non-empty.

 

   There are currently only two notifications where this is the case:

   INVALID_SELECTORS and REKEY_SA.

 

Thanks,

-SooFei

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, August 07, 2= 008 1:10 PM
To: Soo-Fei Chew; ipsec@ietf= .org
Subject: RE: [IPsec] Clarifi= cation on Protocol ID

 

Hi SooFei,

 

Take a look at RFC 4718, Section 7.8.<= /span>

 

Best regards,=

Pasi

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei Chew
Sent: 06 August, 2008 19:44<= br> To: ipsec@ietf.org
Subject: [IPsec] Clarificati= on on Protocol ID

Hi

 

Can you clarify about the Protocol ID = as follows:

 

When the initiator ‘retries̵= 7; IKE_SA_INIT with a COOKIE Notify Payload (with responder supplied cookie da= ta), should the Protocol ID be 0 or 1? In this case, it does involve an existing= SA as far as the initiator is concerned.

 

--SNIP rfc 4306 Section 3.10 ---
o  Protocol ID (1 octet) - If this notification concerns an existing
      SA, this fiel= d indicates the type of that SA.  For IKE_SA
      notifications= , this field MUST be one (1). = For notifications
      concerning IP= sec SAs this field MUST contain = either (2) to
      indicate AH o= r (3) to indicate ESP.  For notifications that do not
      relate to an existing SA, this field MUST= be sent as zero and MUST=
      be ignored on receipt.  All other values for this field are
      reserved to I= ANA for future assignment.
--SNIP rfc 4306 Section 3.10 ---<= /font>

 

Thanks,

SooFei

--_000_50DADDE6B33B1B47904E685AAFDC182410176327C6yugimocanaloc_-- --===============0688780547== 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 --===============0688780547==-- From ipsec-bounces@ietf.org Thu Aug 7 15:57: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 E02723A6BCF; Thu, 7 Aug 2008 15:57:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE843A6BCF for ; Thu, 7 Aug 2008 15:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=1.039, 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 WQjgceavbTgz for ; Thu, 7 Aug 2008 15:57:34 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3ABFC3A6B77 for ; Thu, 7 Aug 2008 15:57:34 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77MvGxh003696; Thu, 7 Aug 2008 17:57:18 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:57:14 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:57:07 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 01:57:21 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62AD@vaebe104.NOE.Nokia.com> In-Reply-To: <50DADDE6B33B1B47904E685AAFDC182410176327C6@yugi.mocana.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on Protocol ID Thread-Index: Acj345i15THQbKkcSUOP4UYOV3zsPwA5epkQAAIKqmAAA7kNIA== References: <1696498986EFEC4D9153717DA325CB72014C6296@vaebe104.NOE.Nokia.com> <50DADDE6B33B1B47904E685AAFDC182410176327C6@yugi.mocana.local> From: To: , X-OriginalArrivalTime: 07 Aug 2008 22:57:07.0184 (UTC) FILETIME=[EA91B700:01C8F8E0] X-Nokia-AV: Clean Subject: Re: [IPsec] Clarification on Protocol ID 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="===============1060910141==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1060910141== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F8E0.EAA041EA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F8E0.EAA041EA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes -- draft-hoffman-ikev2bis clarifies that none of the currently = defined notifications would use Protocol ID 1. =20 Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of ext Soo-Fei Chew Sent: 08 August, 2008 00:13 To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org Subject: Re: [IPsec] Clarification on Protocol ID =09 =09 Hi =20 If combine RFC4718 7.8 and the following statements in RFC 4306, then = it seems to indicate that a Protocol ID of 1 with an empty SPI should = never exist!!=20 =20 3.10. Notify Payload ... o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). ... =20 o SPI Size (1 octet) - Length in octets of the SPI as defined by = the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. =20 7.8. Protocol ID/SPI Fields in Notify Payloads =20 Section 3.10 says that the Protocol ID field in Notify payloads "For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt". However, the specification does not clearly say which notifications are related = to existing SAs and which are not. =20 Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty. =20 There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA. =20 Thanks, -SooFei =09 ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Thursday, August 07, 2008 1:10 PM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] Clarification on Protocol ID =20 Hi SooFei, =20 Take a look at RFC 4718, Section 7.8. =20 Best regards, Pasi =20 =09 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of ext Soo-Fei Chew Sent: 06 August, 2008 19:44 To: ipsec@ietf.org Subject: [IPsec] Clarification on Protocol ID Hi =20 Can you clarify about the Protocol ID as follows: =20 When the initiator 'retries' IKE_SA_INIT with a COOKIE Notify Payload = (with responder supplied cookie data), should the Protocol ID be 0 or 1? = In this case, it does involve an existing SA as far as the initiator is = concerned. =20 --SNIP rfc 4306 Section 3.10 --- o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do = not relate to an existing SA, this field MUST be sent as zero and = MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. --SNIP rfc 4306 Section 3.10 --- =20 Thanks, SooFei ------_=_NextPart_001_01C8F8E0.EAA041EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes -- draft-hoffman-ikev2bis clarifies that = none of the=20 currently defined notifications would use Protocol ID = 1.
 
Best regards,
Pasi

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei=20 Chew
Sent: 08 August, 2008 00:13
To: Eronen Pasi=20 (Nokia-NRC/Helsinki); ipsec@ietf.org
Subject: Re: [IPsec]=20 Clarification on Protocol ID

Hi

 

If combine = RFC4718=20 7.8 and the following statements in RFC 4306, then it seems to = indicate that a=20 Protocol ID of 1 with an empty SPI should never exist!!=20

 

3.10. =20 Notify Payload

=85

   = o =20 Protocol ID (1 octet) - If this notification concerns an=20 existing

     =20 SA, this field indicates the type of that SA.  For=20 IKE_SA

     =20 notifications, this field MUST=20 be one (1).=20 =85

 

   = o  SPI=20 Size (1 octet) - Length in octets of the SPI as defined by=20 the

     =20 IPsec protocol ID or zero if no SPI is applicable.  For=20 a

     =20 notification concerning the IKE_SA, the SPI Size MUST be zero.

 

7.8. =20 Protocol ID/SPI Fields in Notify Payloads

 

   = Section 3.10=20 says that the Protocol ID field in Notify payloads=20 "For

   = notifications=20 that do not relate to an existing SA, this field MUST

   be = sent as=20 zero and MUST be = ignored on=20 receipt".  However, the

   = specification=20 does not clearly say which notifications are related=20 to

   = existing SAs=20 and which are not.

 

   = Since the=20 main purpose of the Protocol ID field is to specify=20 the

   = type of the=20 SPI, our interpretation is that the Protocol ID=20 field

   = should be=20 non-zero only when the SPI field is = non-empty.

 

   = There are=20 currently only two notifications where this is the=20 case:

  =20 INVALID_SELECTORS and REKEY_SA.

 

Thanks,

-SooFei

From:=20 Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, August 07, 2008 = 1:10=20 PM
To: Soo-Fei = Chew;=20 ipsec@ietf.org
Subject: RE:=20 [IPsec] Clarification on Protocol = ID

 

Hi=20 SooFei,

 

Take a look = at RFC=20 4718, Section 7.8.

 

Best=20 regards,

Pasi

 

From:=20 ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei=20 Chew
Sent: 06 = August, 2008=20 19:44
To:=20 ipsec@ietf.org
Subject:=20 [IPsec] Clarification on Protocol ID

Hi

 

Can you = clarify=20 about the Protocol ID as follows:

 

When the = initiator=20 =91retries=92 IKE_SA_INIT with a COOKIE Notify Payload (with = responder supplied=20 cookie data), should the Protocol ID be 0 or 1? In this case, it = does=20 involve an existing SA as far as the initiator is=20 concerned.

 

--SNIP rfc 4306 Section 3.10=20 ---
o  Protocol ID (1 octet) - If this = notification=20 concerns an existing
      SA, this field = indicates=20 the type of that SA.  For IKE_SA
      notifications, = this=20 field MUST be one = (1). =20 For notifications
      concerning IPsec = SAs this=20 field MUST contain = either (2)=20 to
      indicate AH or = (3) to=20 indicate ESP.  For notifications that do = not
      relate to an = existing SA,=20 this field MUST be = sent as=20 zero and=20 MUST
      be ignored on=20 receipt.  All other values for this field = are
      reserved to IANA = for=20 future assignment.
--SNIP rfc=20 4306 Section 3.10 ---

 

Thanks,

SooFei

------_=_NextPart_001_01C8F8E0.EAA041EA-- --===============1060910141== 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 --===============1060910141==-- From ipsec-bounces@ietf.org Thu Aug 7 16:26: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 AE8583A6BCF; Thu, 7 Aug 2008 16:26:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB553A6B03 for ; Thu, 7 Aug 2008 16:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 G6-K6SlXzA+b for ; Thu, 7 Aug 2008 16:26:08 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 72D173A6B19 for ; Thu, 7 Aug 2008 16:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1218151568; x=1249687568; 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<489B8489.70008@qualcomm.com>|Date:=20Thu, =2007=20Aug=202008=2016:26:01=20-0700|From:=20Lakshminath =20Dondeti=20|User-Agent:=20Thunde rbird=202.0.0.16=20(Windows/20080708)|MIME-Version:=201.0 |To:=20Yoav=20Nir=20|CC:=20ipsec@iet f.org|Subject:=20Re:=20[IPsec]=20Secure=20Crash=20Discove ry=20for=20IKEv2|References:=20<54B6B88E-C321-452D-9FAE-D 9A48D6F3371@checkpoint.com>|In-Reply-To:=20<54B6B88E-C321 -452D-9FAE-D9A48D6F3371@checkpoint.com>|Content-Type:=20t ext/plain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5200,2160,5356"=3B=20a=3D"5243739"; bh=MwOlsC5cQcfsum0GV70qaq1Qu26x6jPEm0pMxQJOHS4=; b=Ih+3xmAdiTjdHCuIJMpa+hCZ4qqLqpdEroIASvI0hSqyL2t6AM4FdZPX sH5kwWzj7lgs5tqp0NykAAICFYwS0o2vbnuo6tdh47xplVQKr0zhCSHAp GHhxUrg4gC02uI/fnHi+Rpv9lJatEoKrJt2PJCMgbNhB7GTlWcrSqS5Rz M=; X-IronPort-AV: E=McAfee;i="5200,2160,5356"; a="5243739" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2008 16:26:07 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m77NQ75K027154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Aug 2008 16:26:07 -0700 Received: from [129.46.74.169] (ldondeti.na.qualcomm.com [129.46.74.169]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m77NQ2w6030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 16:26:06 -0700 Message-ID: <489B8489.70008@qualcomm.com> Date: Thu, 07 Aug 2008 16:26:01 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Yoav Nir References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> In-Reply-To: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Question on the QCD proposal. Is it possible for an attacker to send HDR(a, b) SK{..} for arbitrary values of a and b, receive N(QCD_TOKEN) and build a database of QCD_TOKENs? Throttling mechanisms are not appropriate in this case, as far as I can see. I realize that it is a large database to build :) but whatever secret and crypto algorithm is used to generate QCD_TOKENs need to take that interaction into consideration. Another question: Why are a and b equal to 0 in the N(QCD_TOKEN) exchange? Do they need to be? thanks, Lakshminath On 8/6/2008 7:22 AM, Yoav Nir wrote: > This is a followup to my mini-presentation in Dublin. > > The problem we're trying to solve is that of a state de-synchronization > between two IKE peers. This could take several minutes to discover and > resolve, and no IPsec traffic can flow in that time. > > The following Wiki page describes the problem, and two proposed solutions. > > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery > > We would like to solicit input from the WG about these two solutions, so > that we can either combine them or choose between them, and proceed with > a unified draft. > > Thanks in advance > > Frederic, Pratima and 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 Fri Aug 8 01:31: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 8C9293A6B7D; Fri, 8 Aug 2008 01:31:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2A53A6963 for ; Fri, 8 Aug 2008 01:31:05 -0700 (PDT) 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 qYHbMI0ZWQOU for ; Fri, 8 Aug 2008 01:31:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A51383A6B7D for ; Fri, 8 Aug 2008 01:30:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 95204294002; Fri, 8 Aug 2008 11:30:51 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A9451294001; Fri, 8 Aug 2008 11:30:50 +0300 (IDT) Received: from [172.31.21.63] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m788UojI012546; Fri, 8 Aug 2008 11:30:50 +0300 (IDT) Message-Id: From: Yoav Nir To: Lakshminath Dondeti , ipsec@ietf.org In-Reply-To: <489B8489.70008@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 8 Aug 2008 11:30:35 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <489B8489.70008@qualcomm.com> X-Mailer: Apple Mail (2.928.1) Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552351379==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0552351379== Content-Type: multipart/signed; boundary=Apple-Mail-1--641132728; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-1--641132728 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Lakshminath. See my replies below On Aug 8, 2008, at 2:26 AM, Lakshminath Dondeti wrote: > Question on the QCD proposal. > > Is it possible for an attacker to send HDR(a, b) SK{..} for > arbitrary values of a and b, receive N(QCD_TOKEN) and build a > database of QCD_TOKENs? Throttling mechanisms are not appropriate > in this case, as far as I can see. [yn] Yes, it's possible, but assuming that both Alice and Bob use good PRFs to generate the IKE SPIs, it's a 2^128 entry database. If only Bob generates good IKE SPIs and Alice generates 0x0000000000001000, 0x0000000000001001, 0x0000000000001002, etc. it's still bigger than 2^64. > I realize that it is a large database to build :) but whatever > secret and crypto algorithm is used to generate QCD_TOKENs need to > take that interaction into consideration. [yn] There's also the option of periodic rollover to a new secret > > Another question: Why are a and b equal to 0 in the N(QCD_TOKEN) > exchange? Do they need to be? [yn] Good catch. I didn't intend them to be. I'll clear that up. > > > thanks, > Lakshminath --Apple-Mail-1--641132728 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgwODA4 MzAzNlowIwYJKoZIhvcNAQkEMRYEFNjbLLkcV6kemcf9IFwICo1EOZU1MIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBPhdOMWnfy kVs8om6XS+TsIB/v22EwomWf+cW3XXWP7zveSdIXlCH5eKZwHI1a714wS57pUe40LFQx4wArjvt8 PGr0USfysgC/8FTqIIIDBE7/8PfkeviYRrMotV4dOAa7OcAWeUI+yzjTIY106GEYuMJPFKcrTdOx NiFZmop0tZRy5qBlrDqVg0CPNGLlDhFxSv5uRgPKrGjVrfwD0iRIw7PQqq7ed67UV/fx5OdNiDbV 6IwmXVNuWlLBcHXKYHgHa3H8I0wL2m2XlwYEshY7TEgk50WwtIANIY6qhM3cQNvHfLCIsgBRoycz 8MsU3gP7Dicdka8Ksd+7n/xce4YTAAAAAAAA --Apple-Mail-1--641132728-- --===============0552351379== 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 --===============0552351379==-- From ipsec-bounces@ietf.org Fri Aug 8 11:39:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55423A6D0F; Fri, 8 Aug 2008 11:39:00 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F4E3A67CC for ; Fri, 8 Aug 2008 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l-r9KAoV756H for ; Fri, 8 Aug 2008 11:38:54 -0700 (PDT) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) by core3.amsl.com (Postfix) with ESMTP id D57893A68E7 for ; Fri, 8 Aug 2008 11:38:53 -0700 (PDT) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Fri, 8 Aug 2008 11:36:30 -0700 From: Soo-Fei Chew To: "ipsec@ietf.org" Date: Fri, 8 Aug 2008 11:36:27 -0700 Thread-Topic: [IPsec] Clarification on Protocol ID Thread-Index: Acj345i15THQbKkcSUOP4UYOV3zsPwA5epkQAAIKqmAAA7kNIAApQlQA Message-ID: <50DADDE6B33B1B47904E685AAFDC1824101763281A@yugi.mocana.local> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62AD@vaebe104.NOE.Nokia.com> 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] Clarification on Protocol ID 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="===============1871288969==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1871288969== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_50DADDE6B33B1B47904E685AAFDC1824101763281Ayugimocanaloc_" --_000_50DADDE6B33B1B47904E685AAFDC1824101763281Ayugimocanaloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks like Protol ID of 1 can *never* be used if we follow both RFC 4718 se= ction 7.8 and RFC 4306 3.10, since they contradict each other as follows: rfc4306 If (ProtoID =3D=3D 1) then SpiSize =3D=3D 0 rfc4718 If (ProtoID !=3D 0) then SpiSize !=3D 0 which infers that If (ProtoID =3D=3D 1) then SpiSize !=3D 0 <-- this contra= dicts 4036 -SooFei ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 3:57 PM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] Clarification on Protocol ID Yes -- draft-hoffman-ikev2bis clarifies that none of the currently defined = notifications would use Protocol ID 1. Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Soo-Fei Chew Sent: 08 August, 2008 00:13 To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org Subject: Re: [IPsec] Clarification on Protocol ID Hi If combine RFC4718 7.8 and the following statements in RFC 4306, then it se= ems to indicate that a Protocol ID of 1 with an empty SPI should never exis= t!! 3.10. Notify Payload ... o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). ... o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. 7.8. Protocol ID/SPI Fields in Notify Payloads Section 3.10 says that the Protocol ID field in Notify payloads "For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt". However, the specification does not clearly say which notifications are related to existing SAs and which are not. Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty. There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA. Thanks, -SooFei ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 1:10 PM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] Clarification on Protocol ID Hi SooFei, Take a look at RFC 4718, Section 7.8. Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Soo-Fei Chew Sent: 06 August, 2008 19:44 To: ipsec@ietf.org Subject: [IPsec] Clarification on Protocol ID Hi Can you clarify about the Protocol ID as follows: When the initiator 'retries' IKE_SA_INIT with a COOKIE Notify Payload (with= responder supplied cookie data), should the Protocol ID be 0 or 1? In this= case, it does involve an existing SA as far as the initiator is concerned. --SNIP rfc 4306 Section 3.10 --- o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. --SNIP rfc 4306 Section 3.10 --- Thanks, SooFei --_000_50DADDE6B33B1B47904E685AAFDC1824101763281Ayugimocanaloc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks like Protol ID of 1 can *never* be used if we follow both RFC = 4718 section 7.8 and RFC 4306 3.10, since they contradict each other as follows:

 

rfc4306

If (ProtoID =3D=3D 1) then SpiSize =3D= =3D 0

 

rfc4718

If (ProtoID !=3D 0) then SpiSize !=3D = 0  

which infers that I= f (ProtoID =3D=3D 1) then SpiSize !=3D 0 ß this contradicts 4036

 

-SooFei

 

From: Pasi.Ero= nen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, August 07, 2= 008 3:57 PM
To: Soo-Fei Chew; ipsec@ietf= .org
Subject: RE: [IPsec] Clarifi= cation on Protocol ID

 

Yes -- draft-hoffman-ikev2bis clarifie= s that none of the currently defined notifications would use Protocol ID 1.

 

Best regards,=

Pasi

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei Chew
Sent: 08 August, 2008 00:13<= br> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org
Subject: Re: [IPsec] Clarifi= cation on Protocol ID

Hi

 

If combine RFC4718 7.8 and the followi= ng statements in RFC 4306, then it seems to indicate that a Protocol ID of 1 w= ith an empty SPI should never exist!!

 

3.10.  Notify Paylo= ad

…

   o  Protocol ID (1 octet) - If = this notification concerns an existing

      SA, this field indicates the type of that SA.  For IKE_SA

      notifications, th= is field MUST be one (1). …<= /p>

 

   o  SPI Size (1 octet) - Length= in octets of the SPI as defined by the

      IPsec protocol ID= or zero if no SPI is applicable.  For a

      notification concerning the IKE_SA, the SPI Size MUS= T be zero.

 

7.8.  Protocol ID/SPI Fields in No= tify Payloads

 

   Section 3.10 says that the Protocol= ID field in Notify payloads "For

   notifications that do not relate to= an existing SA, this field MUST=

   be sent as zero and MUST be ignored on receipt".&nbs= p; However, the

   specification does not clearly say which notifications are related to

   existing SAs and which are not.

 

   Since the main purpose of the Proto= col ID field is to specify the

   type of the SPI, our interpretation= is that the Protocol ID field

   should be non-zero only when the SP= I field is non-empty.

 

   There are currently only two notifications where this is the case:

   INVALID_SELECTORS and REKEY_SA.

 

Thanks,

-SooFei

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, August 07, 2= 008 1:10 PM
To: Soo-Fei Chew; ipsec@ietf= .org
Subject: RE: [IPsec] Clarifi= cation on Protocol ID

 

Hi SooFei,

 

Take a look at RFC 4718, Section 7.8.<= /span>

 

Best regards,=

Pasi

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Soo-Fei Chew
Sent: 06 August, 2008 19:44<= br> To: ipsec@ietf.org
Subject: [IPsec] Clarificati= on on Protocol ID

Hi

 

Can you clarify about the Protocol ID = as follows:

 

When the initiator ‘retries̵= 7; IKE_SA_INIT with a COOKIE Notify Payload (with responder supplied cookie data), should = the Protocol ID be 0 or 1? In this case, it does involve an existing SA as far = as the initiator is concerned.

 

--SNIP rfc 4306 Section 3.10 ---
o  Protocol ID (1 octet) - If this notification concerns an existing
      SA, this fiel= d indicates the type of that SA.  For IKE_SA
      notifications= , this field MUST be one (1). = For notifications
      concerning IP= sec SAs this field MUST contain = either (2) to
      indicate AH o= r (3) to indicate ESP.  For notifications that do not
      relate to an existing SA, this field MUST= be sent as zero and MUST=
      be ignored on receipt.  All other values for this field are
      reserved to I= ANA for future assignment.
--SNIP rfc 4306 Section 3.10 ---<= /font>

 

Thanks,

SooFei

--_000_50DADDE6B33B1B47904E685AAFDC1824101763281Ayugimocanaloc_-- --===============1871288969== 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 --===============1871288969==-- From ipsec-bounces@ietf.org Sun Aug 10 22:20: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 888C53A6B56; Sun, 10 Aug 2008 22:20:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289BB3A6B56 for ; Sun, 10 Aug 2008 22:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 58ZWJs5g3b0Z for ; Sun, 10 Aug 2008 22:20:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 92D843A6921 for ; Sun, 10 Aug 2008 22:20:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7B5KlU05903; Mon, 11 Aug 2008 07:20:47 +0200 (CEST) Received: from [10.61.254.6] (ams-stealth-fdetienn-6.cisco.com [10.61.254.6]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7B5KbA29017; Mon, 11 Aug 2008 07:20:37 +0200 (CEST) From: Frederic Detienne To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> Organization: Cisco Date: Mon, 11 Aug 2008 07:20:36 +0200 Message-Id: <1218432036.25898.30.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com 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, couple of answers 0- disclaimer ------------- We participate in QCD as well as in SIR and we do see the pros and cons of both protocols. QCD does look simpler but there is still some work to be done to make it a secure protocol specification as opposed to a specification that may allow a secure implementation. Same goes to robustness. Apparent simplicity of QCD will eventually suffer. We invite everyone to look beyond the surface. There is also a fitness for purpose issue that we need to sort out in QCD. SIR is more appropriate in some cases and simply covers more cases than QCD. Finally, for large clusters, SIR works without the help of a management station or a cluster synchronization protocol (e.g. for updating the key regularly). The deployment scalability of SIR is independent of any back-channel (e.g. cluster management protocol), which makes SIR fit for accepting various vendors in the cluster. We agreed with Yoav to present both protocols for public review before one is eventually voted out. Meanwhile, we do defend SIR to the degree that it will suit all the use cases that we have been given to see or think about. 1- constrained devices ---------------------- The wiki is a cooperative write up and I overlooked the "cell phone" statement -- this was not precisely our main concern. Constrained was meant for devices that will not allow spending extra memory/CPU for various reasons. I will update the wiki. The real concern is the amount of memory used and operations to be performed by any device, including the head-end. Over the years, we have seen the memory requirements growing exponentially. Believe it or not, there are a lot of other protocols out there than just IKE that ask for "a few bytes per connection" or some "small amount of memory". We built our protocol like we would for an internal functional spec or code review. If you do not need something, do not use it. Hence the call for an abstraction that I called "Constrained device". The protocol is simple enough to have been implemented by a novice and hence we think we did not trade off simplicity. SIR qualifies as it does not use any resource that IKE would not use already (under normal circumstances, it even uses less). 2- security of SIR ------------------ The same SIR method can be used with or without tickets. 2.1- Ticket based recovery -------------------------- Ticket based recovery does not suffer from a DoS attack more than QCD or Resumption. SIR just consumes a little less memory, and takes less packets but like we stated in our draft, this method can be adapted to QCD. We think this is a useful exchange whenever you want to spend the little extra memory _and_ distribute a key in the cluster _and_ not play with too complex designs -- i.e. good whenever Resumption is applicable. And again, Ticket based SIR does not use more resources than IKE+Resumption would use. 2.2- Stateless recovery ----------------------- Yet the protocol is simple, we appreciate that the _rationale_ of stateless recovery is a little complex for the unwary. Most people stop when they think they found a "great attack". Notions such as "secure enough" deserve an explanation. I will try a deconstructive approach. Strength: - The worst case for SIR is an O(n) attack where n is the number of IKE_SA's already present in the system. This attack only affects recovery; NEW AND EXISTING CONNECTIONS ARE UNAFFECTED. Dampening and other techniques reduce the effectiveness of the attack further. - The worst case for IKEv2 is an O(N) where N is the max number of SA's the system can hold or accept. This attack can go on continuously, preventing legitimate keying (including new connections) from taking place. Please observe that - the magnitude of the IKE attack is higher than the SIR attack - the range of the IKE attack is higher than the SIR attack Ease of attack: - IKEv2 can be attacked via MitM or remotely in some cases - SIR can only be attacked via MitM So far, SIR is "as strong as" or "stronger" than IKEv2 which makes it fit for purpose. Now can you backup your feelings with some facts ? Could you please elaborate an attack that can not be turned against IKE alone ? Can you also please show me how our list of requirements are met with any other crash detection/recovery protocol ? thanks, fred On Thu, 2008-08-07 at 23:09 +0300, Pasi.Eronen@nokia.com wrote: > Couple of comments (not wearing any hats): > > I like the QCD proposal -- it's simple, and doesn't seem to change the > security properties of IKE (unlike the SIR proposal; more below). > > On the web page, you asked for comments about "constrained devices" > like cell phones. For a cell phone that can implement IKEv2, keeping > 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA > and ESP/AH SAs is anyway much more). > > The SIR proposal, on the other hand, relies on totally unauthenticated > exchange. You can treat it as a hint and wait until you're sure you're > not going to get a real authenticated response -- but then it's not > clear why it's better than normal INVALID_IKE_SPI notification. And > if you treat it as something else than hint (and don't wait long time > to hear from the real server), you're exposing yourself to DoS that > wasn't possible earlier. > > Best regards, > Pasi > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of ext Yoav Nir > > Sent: 06 August, 2008 17:22 > > To: ipsec@ietf.org > > Subject: [IPsec] Secure Crash Discovery for IKEv2 > > > > This is a followup to my mini-presentation in Dublin. > > > > The problem we're trying to solve is that of a state de- > > synchronization between two IKE peers. This could take > > several minutes > > to discover and resolve, and no IPsec traffic can flow in that time. > > > > The following Wiki page describes the problem, and two proposed > > solutions. > > > > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery > > > > We would like to solicit input from the WG about these two > > solutions, > > so that we can either combine them or choose between them, > > and proceed > > with a unified draft. > > > > Thanks in advance > > > > Frederic, Pratima and 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 Aug 12 01:57: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 D6EFF3A684A; Tue, 12 Aug 2008 01:57:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9B03A696F for ; Tue, 12 Aug 2008 01:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9jbfsevhccJ for ; Tue, 12 Aug 2008 01:57:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 46FC73A6784 for ; Tue, 12 Aug 2008 01:56:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7C8uY7Z011718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 11:56:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7C8uWPw001119; Tue, 12 Aug 2008 11:56:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18593.20544.706013.155833@fireball.kivinen.iki.fi> Date: Tue, 12 Aug 2008 11:56:32 +0300 From: Tero Kivinen To: Julien Laganier In-Reply-To: <200808060905.39540.julien.laganier.IETF@googlemail.com> References: <18573.51130.528112.634560@fireball.kivinen.iki.fi> <200808060905.39540.julien.laganier.IETF@googlemail.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 8 min X-Total-Time: 27 min Cc: ipsec@ietf.org, pasi.eronen@nokia.com Subject: Re: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Julien Laganier writes: > I'm understanding this as implying it's possible that the gateway > replies with a different link-local interface ID which have to be used > by the client. Yes, but I think we should have text there that gateway SHOULD NOT do that. > If that is a correct understanding, note that the client would in this > case be prevented to use a link-local CGA it generated prior to > initiating, and proposed in the IKE_AUTH. Yes, so thats why gateway should not change address, but on the other hand if client proposes something that is not acceptable (for example using non-link-local address there), then it gateway has two options, either reject whole negotiation, or just reject the invalid address proposed. > If we are going with that configuration payload semantic (i.e., client > proposes something, and server replies with the acceptable value) then > we should specify that the gateway MUST reply with the link-local > interface ID that the client "proposed", and MUST choose for itself a > link-local address that doesn't collide with that of the client. The current semantic for all other configuration payloads is so that client proposes value (or just send empty value if it does not care), and server either accepts the value proposed or fills in acceptable value. The current text is problematic as it changes this normal behavior for just this one configuration parameter. Is there any need for client to know the server's link-local interface ID? We could put MUST there that server MUST either accept the link-local address client proposed, or fail the whole IPv6 configuration if it is acceptable, but I think SHOULD would be enough for that. > This would maintain the semantic of the configuration payloads, and > avoid link-local address collisions. Current semantics of configuration payload is that client uses CFG_REQUEST where it requests values to be used, and server using CFG_REPLY to reply which parameters were given. Here is the text from RFC4306 section 3.15: "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration Payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Requestors MUST ignore returned attributes that they do not recognize. I would like to keep IPv6 configuration so it keeps this same generic guideline, so there is no need to change generic configuration payload processing code when implementing this extension. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 12 03: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 B0CC83A69EE; Tue, 12 Aug 2008 03:57:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900483A69EA for ; Tue, 12 Aug 2008 03:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpxIf4iQuXib for ; Tue, 12 Aug 2008 03:57:38 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.178]) by core3.amsl.com (Postfix) with ESMTP id 1F96A3A68B6 for ; Tue, 12 Aug 2008 03:57:37 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so2832587ika.5 for ; Tue, 12 Aug 2008 03:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=rZHPx8UDfW+yUUEd/rCs62fEQgceJDSk+Yx3n2m/cc8=; b=f3yQiyGhg5NwWd/JXDZtco4wmlvoX7TDjSvTVAPN4+4kErQF+/sQKbL9X10IFLMGZq L7e0FjMaMtOmufsBxjCYmBoSxoljfcCDcJ4JJ06d/xIYqDGaG6MC7T1vGh+ht/ztCFWa HKMBSXjJfZGh4s2EGTsd9noDmOwyrF0WCcXHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=vbEu3rFr51SiGTXiXY1J40JoGXBPnDl/kohBBNTcqdMdWTiLkkFYaRQtgnuaMVJfeF h8nlhWrQjuWEHce9qmdzuMKrzq5qfZna4IDQjsJee2HJVlmMYn2Y+/l10X0bEB7g7Yd5 9CqDlggX+nHicPAoMXRSdTqRTzHzRbNRyfDo0= Received: by 10.103.1.5 with SMTP id d5mr6900753mui.99.1218538628376; Tue, 12 Aug 2008 03:57:08 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e8sm3520077muf.0.2008.08.12.03.57.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Aug 2008 03:57:07 -0700 (PDT) To: Tero Kivinen Date: Tue, 12 Aug 2008 12:57:31 +0200 User-Agent: KMail/1.9.9 References: <18573.51130.528112.634560@fireball.kivinen.iki.fi> <200808060905.39540.julien.laganier.IETF@googlemail.com> <18593.20544.706013.155833@fireball.kivinen.iki.fi> In-Reply-To: <18593.20544.706013.155833@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808121257.32234.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: ipsec@ietf.org, pasi.eronen@nokia.com Subject: Re: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tuesday 12 August 2008, Tero Kivinen wrote: > Julien Laganier writes: > > I'm understanding this as implying it's possible that the gateway > > replies with a different link-local interface ID which have to be > > used by the client. > > Yes, but I think we should have text there that gateway SHOULD NOT do > that. I think we agree, this is what I had in mind as well, but with a stronger requirement level, i.e. MUST instead of SHOULD. More on the requirement level below. > > If that is a correct understanding, note that the client would in > > this case be prevented to use a link-local CGA it generated prior > > to initiating, and proposed in the IKE_AUTH. > > Yes, so thats why gateway should not change address, but on the other > hand if client proposes something that is not acceptable (for example > using non-link-local address there), then it gateway has two options, > either reject whole negotiation, or just reject the invalid address > proposed. Right. But 'not acceptable' address should exclude a link local address the GW wanted to use for itself. IOW it's not acceptable to refuse a valid link-local addresss. > > If we are going with that configuration payload semantic (i.e., > > client proposes something, and server replies with the acceptable > > value) then we should specify that the gateway MUST reply with the > > link-local interface ID that the client "proposed", and MUST choose > > for itself a link-local address that doesn't collide with that of > > the client. > > The current semantic for all other configuration payloads is so that > client proposes value (or just send empty value if it does not care), > and server either accepts the value proposed or fills in acceptable > value. The current text is problematic as it changes this normal > behavior for just this one configuration parameter. Agree. > Is there any need for client to know the server's link-local > interface ID? We could put MUST there that server MUST either accept > the link-local address client proposed, or fail the whole IPv6 > configuration if it is acceptable, but I think SHOULD would be enough > for that. Agree there's no need for the client to know's the server's link local as far as no collision occur. How about: The server SHOULD accept the link-local address the client proposed (which implies the server chooses for itself a link-local address that differs from that of the client). In case the server cannot accept the link-local address the client proposed, the server MUST fail the whole IPv6 configuration. ? > > This would maintain the semantic of the configuration payloads, and > > avoid link-local address collisions. > > Current semantics of configuration payload is that client uses > CFG_REQUEST where it requests values to be used, and server using > CFG_REPLY to reply which parameters were given. Here is the text from > RFC4306 section 3.15: > > "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request > information from its peer. If an attribute in the CFG_REQUEST > Configuration Payload is not zero-length, it is taken as a suggestion > for that attribute. The CFG_REPLY Configuration Payload MAY return > that value, or a new one. It MAY also add new attributes and not > include some requested ones. Requestors MUST ignore returned > attributes that they do not recognize. > > I would like to keep IPv6 configuration so it keeps this same generic > guideline, so there is no need to change generic configuration > payload processing code when implementing this extension. Again, agree. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 12 04:53: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 43F6E3A685D; Tue, 12 Aug 2008 04:53:14 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C034D3A685D for ; Tue, 12 Aug 2008 04:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 RD-rLCdL+Ggu for ; Tue, 12 Aug 2008 04:53:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id A55863A6833 for ; Tue, 12 Aug 2008 04:53:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7CBr1Vl023950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 14:53:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7CBr07n007998; Tue, 12 Aug 2008 14:53:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18593.31131.888367.946778@fireball.kivinen.iki.fi> Date: Tue, 12 Aug 2008 14:52:59 +0300 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <4899A8A1.7040808@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 60 min X-Total-Time: 99 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Motivation for ESP-null marking 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 Grewal, Ken writes: > >Let us ignore the details of the solution proposals for a while (1 > >protocol number vs. 2, ESP wrapper vs. keeping the existing ESP > header), > >and consider whether there is a need to have any solution at all for > >this problem: > [Ken] I am surprised that there are questions being raised about this > goal, given that its presence in the charter indicates that it's a > worthy one. Are there any strong arguments for reversing that consensus? Standard track mechanism does not need to be protocol change, it can be also documentation of how to do the thing with heuristic checks. I think there is no point of doing this on the protocol level as to deploy it requires changes to ALL IPsec endpoints. If we document and implement heuristic checks those can be done directly on the middleboxes, thus requiring only upgrading those small amount of boxes, not all the network endnodes. This means that the heuristic methods are deployable within one year from now or even faster (especially as they do not require interoperability testing or actual protocol specifications, thus vendors can start implementing them NOW). If we now define extension for IKEv2 to allow this (and I hope nobody is even going to suggest implementing anything to the now already obsoleted IKEv1 protocol), it will most likely take about year to finish the protocol document, and then vendors will start implementing it thus first implementations would most likely be end of 2009 or beginning of 2010, and then you need to wait for couple of more years before most of the operating systems support that new extension (i.e. around 2012-2014). After most of the operating systems start supporting it, then you still need to wait 3-5 years to make sure all of the old devices in the network has been updated to support that latest operating system, before you can make sure that all network endnodes support this. So in best you could be able to use it in 2012 or so and in reality you would have to wait until 2015-2018... In the mean time you most likely still want to have solution that will work NOW, not in 10 years time, thus middle box vendors will implement the heuristic methods anyways regardless whether we define protocol for it or not. This protocol change is again something that will disrupt deployment of IPsec, i.e. there will always be implementations which do not support it, and which then cannot be used in some environments. It can also cause delays in deployment, when enterprices decide that they wait until they have this protocol ready for all platforms before even starting to use IPsec. I would much more like to see IPsec to spread out as fast as possible, and not waste time for something that can be done in the middle boxes quite easily with just heuristic checks. > > * What is the security/threat environment that we are dealing with? > > In other words, what is the security policy for which we want an > > efficient enforcement? > [Ken] This solution is targeting an environment where intermediary > devices would like to inspect the packet on route and optionally make > access control decisions based on local policy and the results of the > packet inspection. Some examples of policies are: Dropping packets with > certain characteristics (based on protocol / port or deeper inspection). > E.g. Do not allow any encrypted data; Allow encrypted data to only these > systems; Do not allow FTP/TFTP traffic between these endpoints, but > allow for others. The list goes on...basically any 5-tuple firewall > rules + additional enforcement based on payload examination and > intrusion prevention. > In order to make these decisions, the packets needs to be inspected and > the current IPsec ESP spec does not allow you to infer if the packet is > encrypted or in the clear (ESP-NULL). I do not see any reason why both ESP-NULL and encrypted ESP shuld be allowed between 2 end nodes, i.e. I see only reason where there is either only ESP-NULL allowed or only any type of ESP allowed (i.e. encrypted or not, but not inspected at all). If both ESP-NULL and encrypted ESP is allowed between pair of end nodes, then anybody who wants to bybass middlebox checks will simply use encrypted ESP. If someone disagrees with this, I would like him to explain me why this is needed, and what kind of policy is used for that. Using that premisis, that means that for every single ESP packet coming in to the device, we know immediately after matching the IP-addresses in the header to the policy whether ESP-NULL is mandated, or not. If it is not mandated, then packet is passed forward, as there is no point of inspecting encrypted packets. If ESP-NULL is mandated, then you simply assume packet is ESP-NULL and inspect the packet, and if it looks like encrypted ESP (or garbage) then you do the normal thing firewalls do, i.e drop it. > This has been a deployment barrier to using IPsec in Enterprise > environments as IT departments would like to employ E2E security, but > not at the cost of circumventing existing network monitoring / > diagnostics tools. This charter item is looking at removing this barrier > and allowing IPsec to be employed in these environments. It will be really, really expensive and time consuming to update all end nodes in the network to allow them to use this new protocol extension. It is much faster and cheaper to update those network monitoring / diagnostic tools with ones that support heuristic checks. Also if IT department has full control of the end node configurations (which they must have if they assume they can update all end node implementations at will) they can simply mandate them to use one specific ESP-NULL algorithim, i.e. simply say that no other ESP-NULL algoritm is allowed except AUTH_HMAC_SHA1_96, and that will remove all heuristic checks needed. This kind of solution is implementatable in extremely fast timeframe. > > * Are there alternative ways to detect unencrypted traffic in the > > existing ESP, e.g. heuristics? Are they easy to implement in > > software or in hardware? How significant is the problem of false > > positives? > [Ken] Heuristics will never be free of false positives, all we can do is > play the probability game and reduce false positives to a very small > value. Depends what you mean with false positives. If you mean that encrypted ESP packet will pass the ESP-NULL heuristics and pass the firewall, then the probability of that will go very quickly way below the 96 bits offered by the AUTH_HMAC_SHA1_96 if you do any kind of deep inspection. Also as there should not be any encrypted ESP packets between the nodes who by policy should use ESP-NULL, if they happen to negotiate encrypted ESP for some reason, they might get 15 packets through for every million packets they try to send, even when if you only check TCP checksum (16 bits). If yo do TCP flow checking (source and destination ports, sequence number, acknowledgement number) you do check close to the 96 bits worth of data already. For that to match from the random encrypted packet to some ESP-NULL flow is about the same probability that the randomly generated packet will pass your AUTH_HMAC_SHA1_96 check. > False positives have a high cost as they can lead to incorrectly > applying policies (e.g. because we falsely determine that an ESP > encrypted packet is ESP-NULL) and can cause almost > impossible-to-diagnose network glitches (e.g. which packet(s) out of the > millions being processed actually generated the false positives). No. For the end nodes point of view the encrypted ESP connection between the nodes is broken regardless whether there is one packet every 2^16 or 2^96 going through it. They will see that as broken link and user who misconfigured boths ends (note, that it is not enough for one user to misconfigure his node, but both ends must be misconfigured to allow enctypted ESP) to allow encrypted ESP will notice this and fix his configuration. For attacker doing the same thing, he can continue using encrypted packets but as 99.99999999999999999999999999% of his packets will get dropped by simple tcp flow checking his attacks will be detected very quickly. Note, that there cannot be valid encrypted ESP packet dropped because of these heuristic checks, as encrypted ESP packets are not inspected, but they are passed by (when allowed by policy). > Heuristics can also become very complex with numerous rules to cater for > different protocols / payloads (including catering for the protocols of > tomorrow). As for employing heuristics in SW Vs. HW, this is really > implementation dependent. Having said that, in the multi-core > environment of today, numerous vendors employ IO acceleration techniques > in HW for fast data movement between the HW (e.g. NIC) and SW > components. These techniques are needed to ensure that data is moved > directly to the correct CPU/NPU core, which is the consumer of that > data. These decisions are typically based on stream identifiers (e.g. > 5-tuples in the packet) to ensure full load-balancing capabilities > between the multiple cores. In order to make these decisions, the HW > needs to extract this data and hence any heuristics would need to run in > the HW. Implementing heuristics in HW is very costly, compared with our > proposed approach of an ESP wrapper. No. None of those heuristics needs to really run on the HW. Only the SPI checking needs to run on the HW. I.e. the hardware must understand that it is matching six tuple if IP header protocol is ESP, i.e. source ip/destination ip/spi/protocol number inside ESP-NULL/source port inside ESP-NULL/destination port inside ESP-NULL. Immediately when it sees the SPI it will know where the protocol number and actual header information is. If the SPI is uknown, then HW throws the packet to slowpath, which will do the heuristics, calculate the offsets for the actual protocol information and for the protocol number, and store that information along with the 6-tuple to the packet matching hardware and resume the packet. In almost all the hardware I have seen (our own SafeXcel-5160, Octeon) the flow creation is always done on the softpath anyways. For Intel Tolapai chips can do it both ways (i.e. either from the microcode controlled fastpath, or from the softpath). Doing flow creation on the fastpath is so complicated, that I expect all chips doing so are running some kind of microcode inside the chip doing the actual flow creation, thus chip vendors can most likely add support for IPsec SPI flow creation there in firmware updates when it is widely requested. Note, that if we change the ESP any way (i.e. define new protocol number, or add new bytes or whatever), all the existing hardware will need at minimum firmare updates anyways. In some cases like in Octeon it would be just writing new code, in some cases like in SafeXcel-5160 or Tolapai chips it would require the chip vendor to update the microcode. So from hardware point of view it does not really matter what we do (i.e. heuristics or ESP-NULL marker) the firmware needs to be updated. In some chip architectures firmware require smaller updates for the heuristics method, as heuristics can be done on the softpath, as the full ESP-NULL marker processing needs to be done on the firmware (none of that processing can be pushed to the showpath). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 01:13: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 0E75B3A6B3F; Thu, 14 Aug 2008 01:13:27 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDF73A6A2F for ; Thu, 14 Aug 2008 01:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 niHwjMJQDoHj for ; Thu, 14 Aug 2008 01:13:24 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by core3.amsl.com (Postfix) with ESMTP id ACCFB3A67A7 for ; Thu, 14 Aug 2008 01:13:24 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so497213wra.17 for ; Thu, 14 Aug 2008 01:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=bgiIWStngvnwwaDAHlb1P5N4tKr0zLbJyHCFp0wfsh0=; b=StLe6VRp29jLnNSatU5Ak9AzU8A8fyFSgsRkJXAPxJm/tIkkAcb20KIyEcCpXg+kQU VCCQUImRI6fNuvuSlyy5CS/wuUJNEqzCKz2KOX0KcH/oEYxp+GrlPWK38fr+JJI8I7UA qBDg3MPeImsCpjnWPgymCNQsJVg18OuRR9Vj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=fCMayCZy2ukYFJoMU9+ECJ0Iv7meqxKD8Qh3nBYNYBQnDtNlFAGD3WeBfADACQ1R0g Mi0I/rahE2/W1KDTCCKWSeFncXivMLV5PcD/XeZjaFY103Vi6LA1/DjRbJjJJUUmB1bm SW0YDsOJ8ST75QfcRsiyfEF/5XO1pzEQoy16M= Received: by 10.90.96.15 with SMTP id t15mr1381414agb.116.1218701583317; Thu, 14 Aug 2008 01:13:03 -0700 (PDT) Received: by 10.90.66.4 with HTTP; Thu, 14 Aug 2008 01:13:03 -0700 (PDT) Message-ID: <850df0c40808140113g493e3233v8d4e0b2e031d2ddf@mail.gmail.com> Date: Thu, 14 Aug 2008 10:13:03 +0200 From: "balaji raghavan" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] IKEv1 Identification payload processing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balaji.raghavan@ieee.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I have one question regarding IKEv1. How is an IKE peer expected to respond to a peer identification failure ? i.e more specifically If it chooses to send a notification what is the notify message type should it send ? RFC 2408 sections 4.3,4.4,4.6 state the following in case of errors in ID payload exchanges: " One possible action is the transmission of a Notify payload as part of an Informational Exchange. " There is section 5.8 in rfc2408 which sheds more light on what to do if the ID type is unsupported but can this section be extrapolated to specify behaviour in the case of an unacceptable ID ? ie it " may " send a INVALID-ID-INFORMATION notification to the peer. or is any other notification also an acceptable reply ( for example NO-PROPOSAL-CHOSEN ) ? ---SNIP------ RFC2408 5.8: When an Identification payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Identification Type is supported. This may be based on the DOI and Situation. If the Identification determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID ID INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-ID-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. ---SNIP------ And finally: RFC 4309: Has the following text for identification failures in quick mode exchanges. "Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent." Does this apply to identification failures in other exchanges as well ? -Best Regards Balaji Raghavan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 01:24: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 90F513A6D1C; Thu, 14 Aug 2008 01:24:11 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AC63A682F for ; Thu, 14 Aug 2008 01:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=1.018, 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 T5jWqobRGppt for ; Thu, 14 Aug 2008 01:24:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D9C023A6D1C for ; Thu, 14 Aug 2008 01:24:08 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B2D9F294009; Thu, 14 Aug 2008 11:23:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 367EA294008; Thu, 14 Aug 2008 11:23:54 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7E8NrjI007330; Thu, 14 Aug 2008 11:23:54 +0300 (IDT) Message-Id: <0B81DDDB-1B56-410C-BA21-CFDFAFA35E7F@checkpoint.com> From: Yoav Nir To: balaji.raghavan@ieee.org In-Reply-To: <850df0c40808140113g493e3233v8d4e0b2e031d2ddf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 14 Aug 2008 11:23:53 +0300 References: <850df0c40808140113g493e3233v8d4e0b2e031d2ddf@mail.gmail.com> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv1 Identification payload 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-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 INVALID-ID-INFORMATION is very specific. It implies that the peer does not accept this *type* of identification payload. Sending it for an ID that is just not authorized (most commonly: user not defined) is (a)lying and (b)can lead to user enumeration attacks. I think the safe choice is AUTHENTICATION_FAILED (24) On Aug 14, 2008, at 11:13 AM, balaji raghavan wrote: > Hi, > > I have one question regarding IKEv1. How is an IKE peer expected to > respond to a peer identification failure ? > i.e more specifically If it chooses to send a notification what is the > notify message type should it send ? > > RFC 2408 sections 4.3,4.4,4.6 state the following in case of errors in > ID payload exchanges: > > " One possible action is the transmission of a Notify payload as part > of an Informational Exchange. " > > There is section 5.8 in rfc2408 which sheds more light on what to do > if the ID type is unsupported > but can this section be extrapolated to specify behaviour in the case > of an unacceptable ID ? > > ie it " may " send a INVALID-ID-INFORMATION notification to the peer. > or is any other notification also an acceptable reply ( for example > NO-PROPOSAL-CHOSEN ) ? > > ---SNIP------ > RFC2408 5.8: > When an Identification payload is received, the receiving entity > (initiator or responder) MUST do the following: > 1. Determine if the Identification Type is supported. This may be > based on the DOI and Situation. If the Identification > determination fails, the message is discarded and the following > actions are taken: > (a) The event, INVALID ID INFORMATION, MAY be logged in the > appropriate system audit file. > (b) An Informational Exchange with a Notification payload > containing the INVALID-ID-INFORMATION message type MAY be > sent to the transmitting entity. This action is dictated by > a system security policy. > ---SNIP------ > > And finally: > > RFC 4309: Has the following text for identification failures in quick > mode exchanges. > > "Local policy will dictate whether the proposals are acceptable for > the identities > specified. If the client identities are not acceptable to the Quick > Mode responder > (due to policy or other reasons), a Notify payload > with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent." > > Does this apply to identification failures in other exchanges as > well ? > > -Best Regards > Balaji Raghavan > _______________________________________________ > 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 From ipsec-bounces@ietf.org Thu Aug 14 08:08: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 4DD323A6A48; Thu, 14 Aug 2008 08:08:43 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35213A6A48 for ; Thu, 14 Aug 2008 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 7M8JyN0IkI4F for ; Thu, 14 Aug 2008 08:08:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 637DC3A67D7 for ; Thu, 14 Aug 2008 08:08:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7EF8Ygg000989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 18:08:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7EF8XUQ019542; Thu, 14 Aug 2008 18:08:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18596.19057.198942.901238@fireball.kivinen.iki.fi> Date: Thu, 14 Aug 2008 18:08:33 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 14 min Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > I like the QCD proposal -- it's simple, and doesn't seem to change the > security properties of IKE (unlike the SIR proposal; more below). I have not yet read the drafts, but checked the description on the wiki and from there, I think QCD is much better, it is actually quite close to the birthday certificates, but not using public key crypto. It could also be possible to combine both QCD and birthday certificates if needed. > On the web page, you asked for comments about "constrained devices" > like cell phones. For a cell phone that can implement IKEv2, keeping > 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA > and ESP/AH SAs is anyway much more). Yes. IKE SA state is in order of kilobytes or tens of kilobytes (if large window of 32 is used, IKE SA MUST keep last 32 IKE packets all the time, thus only that reply window takes 10-20 kB of memory...). I do not really consider that memory usage an issue here at all (i.e sounds artifical to even mention it). In the same sense you would need to mention that SIR requires n bytes of memory to keep the cookie while doing the unauthenticated check :-) On the other hand, I am not sure if either one of these are really that useful, as in normal case the boot up sequence of the bob is anyways going to be so long, that it has most likely already triggered the liveness checks if there was active traffic going on between the hosts. Also I think that in case of we receive hints that suggest other end is not reachable, one thing good implementations can do is to reduce the number of retries. I.e. there is really no point of trying 2 minutes for liveness check if you are getting ICMP host/port unreachable or INVALID_IKE_SPI notification back for all of your dozen requests. You could interpret that hint so that you can simply lower the retransmission times from dozen to 5 or so, over 30 seconds instead of few minutes. If the other end is still there, it should be getting one of the liveness checks anyways and reply to it. If you do not hear anything back from the other end (i.e. no hints), then there is most likely something wrong inside the path to remote host, thus there is no point of reducing timers. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 08:13:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D25E3A6D40; Thu, 14 Aug 2008 08:13:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FEF3A6C5E for ; Thu, 14 Aug 2008 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 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 I+I0xr8ImV+o for ; Thu, 14 Aug 2008 08:13:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 24DD73A68C7 for ; Thu, 14 Aug 2008 08:13:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7EFDcu27408; Thu, 14 Aug 2008 17:13:38 +0200 (CEST) Received: from [10.61.254.5] (ams-stealth-fdetienn-5.cisco.com [10.61.254.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7EFDXA17551; Thu, 14 Aug 2008 17:13:38 +0200 (CEST) From: Frederic Detienne To: yingzhe.wu@zteusa.com Organization: Cisco Date: Thu, 14 Aug 2008 17:13:34 +0200 Message-Id: <1218726814.7492.91.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ipsec@ietf.org Subject: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com 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 Yingzhe, As discussed in Dublin, here are my comments about the l3vpn-ipsec-gre draft. 1- GRE rehearsal vs. your proposal ---------------------------------- Section 2 contains a short reminder on GRE that may or may not be necessary (I personally think it does not hurt). However, the choice of splitting the GRE key into two parts does NOT belong to the reminder since this is _your_ choice: -8<--- GRE Key field contains a four octect number used to identify a particular flow. However, how the GRE Key is allocated and communicated to the other end of the tunnel is left unspecified. When used with IPsec for GRE tunnel establishment, this four octect Key field is partitioned into two parts, with the most significant two octects containing the source GRE half key and the least significant two octects containing the destination GRE helf key. -8<--- I.e. the last sentence is NOT a reminder but rather an interpretation of the key that you are making for facilitating your proposal. Again, nothing wrong with that interpretation but this last sentence should be moved to a separate paragraph _after_ the explanation of the flags. It would make it clearer what is your proposal vs. what is historical. 2- Scope of the protocol ------------------------ For your practical case, there is no absolute necessity to differentiate on tunnel key -- there is usually only one GRE tunnel from a client to a given server and the key is not really needed for choosing what to encrypt or what to leave in the clear. A GRE key based traffic selector is really needed so that - traffic from a given remote peer gets decrypted and injected into the "proper" tunnel and no other - traffic to a specific remote peer gets encrypted then encapsulated toward its intended recipient with the proper SA This can be achieved by either attaching an SADB to each individual tunnel interface (i.e. attaching to the interface descriptor) OR by using selectors they way you are proposing. Either way is secure. I suggest a section gets added that explains that those selectors are useful but not necessary to securing GRE. I.e., your proposal is "sufficient but not necessary" for the security of GRE/IPsec. 3- Security considerations -------------------------- Your proposal is only secure if the IPsec gateways can assert that the traffic selector (in this case, including the GRE tunnel key) is somehow permitted for the corresponding IKE identity. To be more specific, there needs to be an authorization phase, implicit or explicit to link the IKE ID to the proxy-ID ("Is user X allowed to negotiate GRE key Y?"). This statement should be part of the security considerations or part of the "Protocol scope" as described above. This statement (authorization mandatory) is what makes your protocol "sufficient" for the security of GRE/IPsec. 4- Traffic Selector payloads ---------------------------- In GRE, the key is not negotiated. If this is the intent, this protocol (IKE) is not the right place. Since the GRE key is fully specified on both ends of the GRE tunnels before IKE begins, the TSi/TSr should contain the two respective half-keys -- i.e. TSr should not contain "any" but rather the second half-key repeated twice. best regards, fred _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 08:20:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5107E3A6D5A; Thu, 14 Aug 2008 08:20:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EF73A6D21 for ; Thu, 14 Aug 2008 08:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 f8G7D71jX2fB for ; Thu, 14 Aug 2008 08:20:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 9BF1F3A6AEA for ; Thu, 14 Aug 2008 08:20:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7EFKaks013711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 18:20:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7EFKZCA006800; Thu, 14 Aug 2008 18:20:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18596.19779.406278.175310@fireball.kivinen.iki.fi> Date: Thu, 14 Aug 2008 18:20:35 +0300 From: Tero Kivinen To: Julien Laganier In-Reply-To: <200808121257.32234.julien.laganier.IETF@googlemail.com> References: <18573.51130.528112.634560@fireball.kivinen.iki.fi> <200808060905.39540.julien.laganier.IETF@googlemail.com> <18593.20544.706013.155833@fireball.kivinen.iki.fi> <200808121257.32234.julien.laganier.IETF@googlemail.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org, pasi.eronen@nokia.com Subject: Re: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Julien Laganier writes: > The server SHOULD accept the link-local address the client proposed > (which implies the server chooses for itself a link-local address that > differs from that of the client). In case the server cannot accept the > link-local address the client proposed, the server MUST fail the whole > IPv6 configuration. Looks ok for me. Note, that failing IPv6 configuration DOES not cause IKE SA creation to fail, but can cause the initial IPsec SA creation to fail, if that wanted to use IPv6 addresses. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 09:02:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AC43A6CE2; Thu, 14 Aug 2008 09:02:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF5428C1B1 for ; Thu, 14 Aug 2008 09:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 wTXYbcgj+c1Y for ; Thu, 14 Aug 2008 09:02:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5AC3128C1E9 for ; Thu, 14 Aug 2008 09:02:02 -0700 (PDT) Received: from [165.227.249.206] (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 m7EG1aYi042082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Aug 2008 09:01:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 14 Aug 2008 09:02:00 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Session resumption vs. failover X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. The ipsecme WG charter talks about session resumption, but also says that "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". There were questions at the Dublin meeting and on this list about what this means. One expected use case for the session resumption mechanism is to allow remote access systems such as laptops to go into hibernation or standby mode and later reconnect to the same gateway when they awaken. The remote system may have changed locations and/or IP addresses. The use of a "session resumption" in this scenario will eliminate the need for possibly manual user authentication. Another scenario is the remote user's network being powered down and then back up later, such as to save energy or due to an extended network outage that does not affect the gateway. Gateway clusters might share resumption information between themselves, but the method they use and the information they share are explicitly out of scope for the WG. If such gateways do share sufficient information (such as a ticket encrypting key) to do failover in a secure fashion, they can use the chartered resumption mechanism to do so; however, the WG work will not make any effort to help this other than to make the ticket extensible. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 11:43: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 4945E3A693F; Thu, 14 Aug 2008 11:43:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87013A693F for ; Thu, 14 Aug 2008 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvkB9K9ru7fx for ; Thu, 14 Aug 2008 11:43:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 988843A68BF for ; Thu, 14 Aug 2008 11:43:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7D510294002; Thu, 14 Aug 2008 21:42:46 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id ADA79294001 for ; Thu, 14 Aug 2008 21:42:45 +0300 (IDT) Received: from [172.16.10.18] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7EIgijI019528 for ; Thu, 14 Aug 2008 21:42:45 +0300 (IDT) Message-ID: <48A47CA4.2090109@checkpoint.com> Date: Thu, 14 Aug 2008 21:42:44 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] ipsecme WG document on IKEv2 IPv6 configuration 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="===============2071202589==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============2071202589== Content-Type: multipart/alternative; boundary="------------050803020408080909050007" This is a multi-part message in MIME format. --------------050803020408080909050007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, you will recall we have a chartered work item regarding IPv6 configuration. Pasi Eronen, Julien Laganier and Cheryl Madson have agreed to edit the document, starting from Pasi's existing draft, http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-ipv6-config-04.txt. I am expecting a -00 draft within the next few weeks. Thanks Pasi, Julien and Cheryl. Regards, Yaron --------------050803020408080909050007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,


you will recall we have a chartered work item regarding IPv6 configuration. Pasi Eronen, Julien Laganier and Cheryl Madson have agreed to edit the document, starting from Pasi's existing draft, http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-ipv6-config-04.txt. I am expecting a -00 draft within the next few weeks.


Thanks Pasi, Julien and Cheryl.


Regards,

    Yaron

--------------050803020408080909050007-- --===============2071202589== 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 --===============2071202589==-- From ipsec-bounces@ietf.org Thu Aug 14 12:55: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 11C5B3A69C1; Thu, 14 Aug 2008 12:55:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CB23A69C1 for ; Thu, 14 Aug 2008 12:55:34 -0700 (PDT) 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 bRnFEW7UJJhw for ; Thu, 14 Aug 2008 12:55:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id DEA9B3A6878 for ; Thu, 14 Aug 2008 12:55:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7EJtWD21637; Thu, 14 Aug 2008 21:55:32 +0200 (CEST) Received: from [10.61.254.5] (ams-stealth-fdetienn-5.cisco.com [10.61.254.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7EJtPA27264; Thu, 14 Aug 2008 21:55:25 +0200 (CEST) From: Frederic Detienne To: Tero Kivinen In-Reply-To: <18596.19057.198942.901238@fireball.kivinen.iki.fi> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> Organization: Cisco Date: Thu, 14 Aug 2008 21:55:27 +0200 Message-Id: <1218743727.7492.167.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ipsec@ietf.org, ynir@checkpoint.com, Pasi.Eronen@nokia.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com 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 Thu, 2008-08-14 at 18:08 +0300, Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > > I like the QCD proposal -- it's simple, and doesn't seem to change the > > security properties of IKE (unlike the SIR proposal; more below). > > I have not yet read the drafts, but checked the description on the > wiki and from there, I think QCD is much better, it is actually quite > close to the birthday certificates, but not using public key crypto. > It could also be possible to combine both QCD and birthday > certificates if needed. We are trying to get an apple-to-apple comparison between QCD and SIR. Is it possible to get some real comparison or do we have to stick to impressions forever ? On a side note, Yoav, Pratima and I think that Birth Certificates don't work well in practice. They may be sort of secure but they are power hungry. Both QCD and SIR are meant to be implemented on real gateways, with real memory and real CPU's. > > On the web page, you asked for comments about "constrained devices" > > like cell phones. For a cell phone that can implement IKEv2, keeping > > 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA > > and ESP/AH SAs is anyway much more). > > Yes. IKE SA state is in order of kilobytes or tens of kilobytes (if > large window of 32 is used, IKE SA MUST keep last 32 IKE packets all > the time, thus only that reply window takes 10-20 kB of memory...). I > do not really consider that memory usage an issue here at all (i.e > sounds artifical to even mention it). I see. "nobody needs more than 640kb or RAM", uh :) funny. Guess what: there is still a market for embedded OSes that consume very little memory and those OSes still beat free (as in free beer) operating systems on that single point. This being said, the "constraint device" notion is a concept to summarize a number of notion. The message is "why use resources you do not need". We could call this "green protocols" too... or "resource savvy protocols". etc. Anything that you can understand is welcome. Please help rephrasing. If you had read the drafts, you would also know that this is not the main point of SIR vs. QCD. There is a fitness for purpose issue; SIR has a chapter dedicated to this. QCD is still incomplete on that front. We would like to know what problem other implementers are willing to address in the protocol... this is a good thing to start with before saying that on thing is better than an other. > In the same sense you would need > to mention that SIR requires n bytes of memory to keep the cookie > while doing the unauthenticated check :-) Very good point! Just wrong. In stateless recovery --------------------- The cookie is computed with the same key as IKE uses for its anti-spoofing test. SIR does not require _any_ storage that IKE does not already require. I am ready to stand the argumentation but we certainly do not need O(n) storage (n=# of SA's). In ticket based recovery ------------------------ SIR uses a cookie approach but apparently too secure for FUD. This method does not use more memory than Resumption. > On the other hand, I am not sure if either one of these are really > that useful, as in normal case the boot up sequence of the bob is > anyways going to be so long, that it has most likely already triggered > the liveness checks if there was active traffic going on between the > hosts. er.. darn you caught me... let me guess... oh yeah! Because the failover/cluster case is really what real users out there are interested in ? maybe ? Again: protocols have a purpose. > Also I think that in case of we receive hints that suggest other end > is not reachable, one thing good implementations can do is to reduce > the number of retries. I.e. there is really no point of trying 2 > minutes for liveness check if you are getting ICMP host/port > unreachable or INVALID_IKE_SPI notification back for all of your dozen > requests. You could interpret that hint so that you can simply lower > the retransmission times from dozen to 5 or so, over 30 seconds > instead of few minutes. If the other end is still there, it should be > getting one of the liveness checks anyways and reply to it. How is this fundamentally different from what SIR is saying ? SIR does that kind of dance, only much faster and introduces an payload so that it can collect hints of an attack as well and _log_ what is going on. I do appreciate you are calling this a "good implementation", though. Thank you. fred > If you do not hear anything back from the other end (i.e. no hints), > then there is most likely something wrong inside the path to remote > host, thus there is no point of reducing timers. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 14 17:33:18 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 28C8C3A67F8; Thu, 14 Aug 2008 17:33:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A673A67F6 for ; Thu, 14 Aug 2008 17:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 mFbRnbpiBmOd for ; Thu, 14 Aug 2008 17:33:16 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 199B83A67B0 for ; Thu, 14 Aug 2008 17:33:16 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7F0XAF5011062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2008 19:33:11 -0500 From: "Yingzhe Wu" To: References: <1218726814.7492.91.camel@fdetienn-laptop> In-Reply-To: <1218726814.7492.91.camel@fdetienn-laptop> Date: Thu, 14 Aug 2008 17:32:51 -0700 Message-ID: <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj+IF6fEbTKftMgSWKhocPbq7OfGQAPV0uw Content-Language: en-us Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Frederic, Thank you for your comments. Please see reply inline. -----Original Message----- From: Frederic Detienne [mailto:fd@cisco.com] Sent: Thursday, August 14, 2008 8:14 AM To: yingzhe.wu@zteusa.com Cc: ipsec@ietf.org Subject: draft-wu-l3vpn-ipsec-gre-00 -- some comments Hi Yingzhe, As discussed in Dublin, here are my comments about the l3vpn-ipsec-gre draft. 1- GRE rehearsal vs. your proposal ---------------------------------- Section 2 contains a short reminder on GRE that may or may not be necessary (I personally think it does not hurt). However, the choice of splitting the GRE key into two parts does NOT belong to the reminder since this is _your_ choice: -8<--- GRE Key field contains a four octect number used to identify a particular flow. However, how the GRE Key is allocated and communicated to the other end of the tunnel is left unspecified. When used with IPsec for GRE tunnel establishment, this four octect Key field is partitioned into two parts, with the most significant two octects containing the source GRE half key and the least significant two octects containing the destination GRE helf key. -8<--- I.e. the last sentence is NOT a reminder but rather an interpretation of the key that you are making for facilitating your proposal. Again, nothing wrong with that interpretation but this last sentence should be moved to a separate paragraph _after_ the explanation of the flags. It would make it clearer what is your proposal vs. what is historical. YZ> Yes, I agree. 2- Scope of the protocol ------------------------ For your practical case, there is no absolute necessity to differentiate on tunnel key -- there is usually only one GRE tunnel from a client to a given server and the key is not really needed for choosing what to encrypt or what to leave in the clear. YZ> If the GRE tunnel is not keyed (as identified by 'K' bit), then the conventional method of IPsec protection is used, i.e, based on protocol field only. When used in multiple VPNs between a pair of gateways case, there will be Key field present in GRE tunnels and the key field can be used as IPsec selector. A GRE key based traffic selector is really needed so that - traffic from a given remote peer gets decrypted and injected into the "proper" tunnel and no other - traffic to a specific remote peer gets encrypted then encapsulated toward its intended recipient with the proper SA YZ> True. This can be achieved by either attaching an SADB to each individual tunnel interface (i.e. attaching to the interface descriptor) OR by using selectors they way you are proposing. Either way is secure. YZ> Not quite sure I understand this. Are you comparing with native IPsec implementation that binds SA to socket? Even so, when the tunnel interface is first associated with SA, IPsec selector match needs to happen and this is based on GRE key. I suggest a section gets added that explains that those selectors are useful but not necessary to securing GRE. I.e., your proposal is "sufficient but not necessary" for the security of GRE/IPsec. 3- Security considerations -------------------------- Your proposal is only secure if the IPsec gateways can assert that the traffic selector (in this case, including the GRE tunnel key) is somehow permitted for the corresponding IKE identity. To be more specific, there needs to be an authorization phase, implicit or explicit to link the IKE ID to the proxy-ID ("Is user X allowed to negotiate GRE key Y?"). This statement should be part of the security considerations or part of the "Protocol scope" as described above. This statement (authorization mandatory) is what makes your protocol "sufficient" for the security of GRE/IPsec. YZ> We currently don't have the scenario that IKE endpoints and GRE endpoints separated. So there is really no proxy ID. Based on that, do you agree simply provisioning the GRE key in SPD with source/destination addresses same as IKE addresses sufficient for SA authorization? 4- Traffic Selector payloads ---------------------------- In GRE, the key is not negotiated. If this is the intent, this protocol (IKE) is not the right place. Since the GRE key is fully specified on both ends of the GRE tunnels before IKE begins, the TSi/TSr should contain the two respective half-keys -- i.e. TSr should not contain "any" but rather the second half-key repeated twice. YZ> GRE key negotiation is currently out of scope, and we intend to do just the traffic selection. best regards, fred _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 15 00:49: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 D2C5A3A6CC6; Fri, 15 Aug 2008 00:49:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4002F3A6C1F for ; Fri, 15 Aug 2008 00:49:10 -0700 (PDT) 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 2YBYQJGCgDiK for ; Fri, 15 Aug 2008 00:49:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A4E143A6828 for ; Fri, 15 Aug 2008 00:49:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7F7nCa24297; Fri, 15 Aug 2008 09:49:12 +0200 (CEST) Received: from [10.61.254.5] (ams-stealth-fdetienn-5.cisco.com [10.61.254.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7F7nBA25087; Fri, 15 Aug 2008 09:49:11 +0200 (CEST) From: Frederic Detienne To: Yingzhe Wu In-Reply-To: <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> Organization: Cisco Date: Fri, 15 Aug 2008 09:49:14 +0200 Message-Id: <1218786554.7492.249.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com 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 Thu, 2008-08-14 at 17:32 -0700, Yingzhe Wu wrote: > Hi Frederic, > > Thank you for your comments. Please see reply inline. > > > -----Original Message----- > From: Frederic Detienne [mailto:fd@cisco.com] > Sent: Thursday, August 14, 2008 8:14 AM > To: yingzhe.wu@zteusa.com > Cc: ipsec@ietf.org > Subject: draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Yingzhe, > > As discussed in Dublin, here are my comments about the l3vpn-ipsec-gre > draft. > > 1- GRE rehearsal vs. your proposal > ---------------------------------- > Section 2 contains a short reminder on GRE that may or may not be > necessary (I personally think it does not hurt). However, the choice of > splitting the GRE key into two parts does NOT belong to the reminder > since this is _your_ choice: > > -8<--- > GRE Key field contains a four octect number used to identify a > particular flow. However, how the GRE Key is allocated and > communicated to the other end of the tunnel is left unspecified. > When used with IPsec for GRE tunnel establishment, this four octect > Key field is partitioned into two parts, with the most significant > two octects containing the source GRE half key and the least > significant two octects containing the destination GRE helf key. > -8<--- > > I.e. the last sentence is NOT a reminder but rather an interpretation of > the key that you are making for facilitating your proposal. > > Again, nothing wrong with that interpretation but this last sentence > should be moved to a separate paragraph _after_ the explanation of the > flags. It would make it clearer what is your proposal vs. what is > historical. > > YZ> Yes, I agree. > > 2- Scope of the protocol > ------------------------ > For your practical case, there is no absolute necessity to differentiate > on tunnel key -- there is usually only one GRE tunnel from a client to a > given server and the key is not really needed for choosing what to > encrypt or what to leave in the clear. > > YZ> If the GRE tunnel is not keyed (as identified by 'K' bit), then the > conventional method of IPsec protection is used, i.e, based on protocol > field only. When used in multiple VPNs between a pair of gateways case, > there will be Key field present in GRE tunnels and the key field can be used > as IPsec selector. > > A GRE key based traffic selector is really needed so that > - traffic from a given remote peer gets decrypted and injected into the > "proper" tunnel and no other > - traffic to a specific remote peer gets encrypted then encapsulated > toward its intended recipient with the proper SA > > YZ> True. > > This can be achieved by either attaching an SADB to each individual > tunnel interface (i.e. attaching to the interface descriptor) OR by > using selectors they way you are proposing. Either way is secure. > > YZ> Not quite sure I understand this. Are you comparing with native IPsec > implementation that binds SA to socket? Even so, when the tunnel interface > is first associated with SA, IPsec selector match needs to happen and this > is based on GRE key. That association could be based on the IKE_ID alone, not waiting for the traffic selector. In that case, the GRE selector in your proposal is not necessary. I still see value in your proposal as not all implementations can afford binding SA's to interface descriptors. > I suggest a section gets added that explains that those selectors are > useful but not necessary to securing GRE. I.e., your proposal is > "sufficient but not necessary" for the security of GRE/IPsec. > > 3- Security considerations > -------------------------- > Your proposal is only secure if the IPsec gateways can assert that the > traffic selector (in this case, including the GRE tunnel key) is somehow > permitted for the corresponding IKE identity. > > To be more specific, there needs to be an authorization phase, implicit > or explicit to link the IKE ID to the proxy-ID ("Is user X allowed to > negotiate GRE key Y?"). > > This statement should be part of the security considerations or part of > the "Protocol scope" as described above. > > This statement (authorization mandatory) is what makes your protocol > "sufficient" for the security of GRE/IPsec. > > YZ> We currently don't have the scenario that IKE endpoints and GRE > endpoints separated. So there is really no proxy ID. Based on that, do you > agree simply provisioning the GRE key in SPD with source/destination > addresses same as IKE addresses sufficient for SA authorization? Oh sorry; I still think of traffic selectors as a form of identity like they were in IKEv1. Let me rephrase in terms of traffic selectors. What I meant is that for the security scheme to be complete, there must be a validation of the negotiated traffic selectors vs. the IKE_SA identity. Otherwise, this would allow any user allowed to create an IKE_SA on LMA to negotiate any GRE key and hence access either Enterprise-A or Enterprise-B which we intended to differentiate in the first place. So just comparing the addresses is not sufficient in the general case. There may be degenerate cases where sys admins rely on the ip addresses only (e.g. because they administer both ends of the tunnel) for authorization. By simply adding a validation statement (a "SHOULD authorize" + explanation/recommendation) will make your specification a lot broader, clearer and more secure, without changing the underlying proposal. > 4- Traffic Selector payloads > ---------------------------- > > In GRE, the key is not negotiated. If this is the intent, this protocol > (IKE) is not the right place. > > Since the GRE key is fully specified on both ends of the GRE tunnels > before IKE begins, the TSi/TSr should contain the two respective > half-keys -- i.e. TSr should not contain "any" but rather the second > half-key repeated twice. > > YZ> GRE key negotiation is currently out of scope, and we intend to do just > the traffic selection. ok thanks. So can you explain why the TSr key contains 0 instead of the second half-key when sent by the initiator ? It is not a trick questions -- just for me to understand your rationale. If that makes no difference for you, I would rather have TSr contain the second half-key to make the intent of the protocol clear. thanks and regards, fred > best regards, > > fred _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 15 01:40: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 92A1D3A6D0A; Fri, 15 Aug 2008 01:40:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797A128C19B for ; Fri, 15 Aug 2008 01:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 dgsLsjCOvrRZ for ; Fri, 15 Aug 2008 01:40:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id B02CF3A6D02 for ; Fri, 15 Aug 2008 01:40:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7F8eOUG001795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 11:40:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7F8eMZN029961; Fri, 15 Aug 2008 11:40:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18597.16630.682587.674433@fireball.kivinen.iki.fi> Date: Fri, 15 Aug 2008 11:40:22 +0300 From: Tero Kivinen To: fd@cisco.com In-Reply-To: <1218743727.7492.167.camel@fdetienn-laptop> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 24 min X-Total-Time: 51 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, ynir@checkpoint.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Frederic Detienne writes: > On a side note, Yoav, Pratima and I think that Birth Certificates don't > work well in practice. They may be sort of secure but they are power > hungry. Both QCD and SIR are meant to be implemented on real gateways, > with real memory and real CPU's. What kind of reasons you have for them not working in real environments? For the Bob, they are cheaper than both SIR and QCD from the computational point of view, as you need to generate only one certificate for each reboot, and regardless how many IKE SAs you had up, you do not need to do any additional computations. For the Alice it requires checking one signature when they start suspecting that the other end is not up and running (i.e. when they are not receiving anything from the other end and they get INVALID SPI exchange back). Note, that signature verification in RSA is quite fast, usually in order of milliseconds, which is faster than what is the normal round trip time. On the very slow devices there is quite often hardware to assist doing RSA and Diffie-Hellman calculations anyways, as those calculations are needed anyways for IKEv2. The signature verification for RSA keys is about 10 times faster than Diffie-Hellman required for recreating the IKE SA. > > > On the web page, you asked for comments about "constrained devices" > > > like cell phones. For a cell phone that can implement IKEv2, keeping > > > 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA > > > and ESP/AH SAs is anyway much more). > > > > Yes. IKE SA state is in order of kilobytes or tens of kilobytes (if > > large window of 32 is used, IKE SA MUST keep last 32 IKE packets all > > the time, thus only that reply window takes 10-20 kB of memory...). I > > do not really consider that memory usage an issue here at all (i.e > > sounds artifical to even mention it). > > I see. "nobody needs more than 640kb or RAM", uh :) funny. Nope. More like that there is no point of saving 0.1% of memory by adding more code that consumes more memory than that... As the memory is needed only on Alice, and she normally has just ONE IKE SA, the total memory saving is around 16-32 bytes of memory in total. > Guess what: there is still a market for embedded OSes that consume very > little memory and those OSes still beat free (as in free beer) operating > systems on that single point. I know, but we also do implementations on those platforms too, and I know that currently those devices (phones for example) have quite a lot of memory still (in orders of hundreds of kilobytes), thus adding 32 bytes of memory in total, does not really matter there. Implementing any of the proposals are going to use much more code memory (and that is actually quite often more limited than RAM) than that anyways. > > In the same sense you would need > > to mention that SIR requires n bytes of memory to keep the cookie > > while doing the unauthenticated check :-) > > Very good point! Just wrong. > > In stateless recovery > --------------------- > > The cookie is computed with the same key as IKE uses for its > anti-spoofing test. SIR does not require _any_ storage that IKE does not > already require. I am ready to stand the argumentation but we certainly > do not need O(n) storage (n=# of SA's). As n is 1 in Alice anyways, that does not really matter, and when you generate Cookie and send it to the Bob, you need to keep that in memory so you can verify it is same when Bob returns it back in the reply, thus you need to keep it in memory during the exchange. Note, that it is much faster (and more efficient) to just generate random cookie, and store it in the memory, than use some cryptographic algorithm to generate it, especially as Alice still has state (IKE SA), thus there is no need to be stateless. > In ticket based recovery > ------------------------ > SIR uses a cookie approach but apparently too secure for FUD. This > method does not use more memory than Resumption. > > > On the other hand, I am not sure if either one of these are really > > that useful, as in normal case the boot up sequence of the bob is > > anyways going to be so long, that it has most likely already triggered > > the liveness checks if there was active traffic going on between the > > hosts. > > er.. darn you caught me... let me guess... oh yeah! Because the > failover/cluster case is really what real users out there are interested > in ? maybe ? We are not talking about failrover or cluster, we are talking about secure crash discovery. In any case there are ways to do cluster / failover methods which do not require any coordination with the client. > > Also I think that in case of we receive hints that suggest other end > > is not reachable, one thing good implementations can do is to reduce > > the number of retries. I.e. there is really no point of trying 2 > > minutes for liveness check if you are getting ICMP host/port > > unreachable or INVALID_IKE_SPI notification back for all of your dozen > > requests. You could interpret that hint so that you can simply lower > > the retransmission times from dozen to 5 or so, over 30 seconds > > instead of few minutes. If the other end is still there, it should be > > getting one of the liveness checks anyways and reply to it. > > How is this fundamentally different from what SIR is saying ? SIR does > that kind of dance, only much faster and introduces an payload so that > it can collect hints of an attack as well and _log_ what is going on. Yes, but the other method is already there, and can already be used with ANY standard complient IKEv2 implementation, without requiring any extra protocol work. It security properties are about the same as in SIR, and its security is not that much worse than in SIR. So if we want to do something that is more secure than what there is already now, then I would like to make that then really secure. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 15 06:42: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 A0F903A6D8C; Fri, 15 Aug 2008 06:42:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D41C3A68A0 for ; Fri, 15 Aug 2008 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFkVJKFodddD for ; Fri, 15 Aug 2008 06:42:01 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 92F1A3A6D8C for ; Fri, 15 Aug 2008 06:42:01 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 15 Aug 2008 06:39:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.32,215,1217833200"; d="scan'208";a="429492296" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga001.jf.intel.com with ESMTP; 15 Aug 2008 06:41:08 -0700 Received: from orsmsx414.amr.corp.intel.com ([10.22.226.41]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Aug 2008 06:41:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 06:40:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Session resumption vs. failover thread-index: Acj+JyvCHbf7EaysQoGr2CMRlJGqmAAtOpZg References: From: "Sood, Kapil" To: "Paul Hoffman" , "IPsecme WG" X-OriginalArrivalTime: 15 Aug 2008 13:41:45.0095 (UTC) FILETIME=[A85C7170:01C8FEDC] Subject: Re: [IPsec] Session resumption vs. failover 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 Paul, I concur...The "Session Resumption" use-case for clients going in/out of hibernate and standby is a perfectly valid, and is one we'd be interested in contributing. Best Regards, Kapil. -------- Kapil Sood Security Architect Intel CTG-Comms Labs 971.506.1700 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Thursday, August 14, 2008 9:02 AM To: IPsecme WG Subject: [IPsec] Session resumption vs. failover Greetings again. The ipsecme WG charter talks about session resumption, but also says that "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". There were questions at the Dublin meeting and on this list about what this means. One expected use case for the session resumption mechanism is to allow remote access systems such as laptops to go into hibernation or standby mode and later reconnect to the same gateway when they awaken. The remote system may have changed locations and/or IP addresses. The use of a "session resumption" in this scenario will eliminate the need for possibly manual user authentication. Another scenario is the remote user's network being powered down and then back up later, such as to save energy or due to an extended network outage that does not affect the gateway. Gateway clusters might share resumption information between themselves, but the method they use and the information they share are explicitly out of scope for the WG. If such gateways do share sufficient information (such as a ticket encrypting key) to do failover in a secure fashion, they can use the chartered resumption mechanism to do so; however, the WG work will not make any effort to help this other than to make the ticket extensible. --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 Sat Aug 16 15:27:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B373A6BCC; Sat, 16 Aug 2008 15:27:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E049C3A6BCC for ; Sat, 16 Aug 2008 15:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_05=-1.11] 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 fdf3MPW4b+Xj for ; Sat, 16 Aug 2008 15:27:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B75823A68D5 for ; Sat, 16 Aug 2008 15:26:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 71AB8294002; Sun, 17 Aug 2008 01:26:44 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 91135294001; Sun, 17 Aug 2008 01:26:43 +0300 (IDT) Received: from [172.31.21.76] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7GMQhjI014028; Sun, 17 Aug 2008 01:26:43 +0300 (IDT) Message-Id: From: Yoav Nir To: Tero Kivinen In-Reply-To: <18596.19057.198942.901238@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 17 Aug 2008 01:26:42 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 Aug 14, 2008, at 6:08 PM, Tero Kivinen wrote: > > On the other hand, I am not sure if either one of these are really > that useful, as in normal case the boot up sequence of the bob is > anyways going to be so long, that it has most likely already triggered > the liveness checks if there was active traffic going on between the > hosts. I'm not sure this is the normal case. I spent most of the IETF meeting with the client connected, but the only traffic to the company was, that every 5 minutes or so, the mail client would poll the IMAP server. If the clients do gratuitous liveness checks all the time, they would notice a crash, but if they wait for IMAP to fail, they might miss it. Linux-based servers boot up in less than a minute. "Hardware" appliances are even faster, and the VPN software comes up very quickly. Besides, most VPN software has some kind of button or command- line to erase all the tunnels (setkey -F). That's like an instantaneous reboot of "Bob". Users tend to use this whenever they feel that "something is wrong". > Also I think that in case of we receive hints that suggest other end > is not reachable, one thing good implementations can do is to reduce > the number of retries. I.e. there is really no point of trying 2 > minutes for liveness check if you are getting ICMP host/port > unreachable or INVALID_IKE_SPI notification back for all of your dozen > requests. You could interpret that hint so that you can simply lower > the retransmission times from dozen to 5 or so, over 30 seconds > instead of few minutes. If the other end is still there, it should be > getting one of the liveness checks anyways and reply to it. That's an idea, but you still have 30 seconds of both Bob and Alice ready, but traffic does not go through. > If you do not hear anything back from the other end (i.e. no hints), > then there is most likely something wrong inside the path to remote > host, thus there is no point of reducing timers. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Aug 17 10:47: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 2451F3A6BED; Sun, 17 Aug 2008 10:47:54 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83383A6BED for ; Sun, 17 Aug 2008 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_05=-1.11] 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 dDSTJBg3+DgH for ; Sun, 17 Aug 2008 10:47:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7A7593A6978 for ; Sun, 17 Aug 2008 10:47:51 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7HHlMBE055889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Aug 2008 10:47:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 17 Aug 2008 10:47:46 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Minutes from the Dublin meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ... are at . It is my fault that it took so long to get them up; Sandy Murphy got them to me over a week ago. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 03:25: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 9691328C0EF; Mon, 18 Aug 2008 03:25:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C53828C100 for ; Mon, 18 Aug 2008 03:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_40=-0.185] 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 Eu3WnBiueHHI for ; Mon, 18 Aug 2008 03:25:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6663A6C7F for ; Mon, 18 Aug 2008 03:25:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7IANg37011676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 13:23:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7IANbd0012623; Mon, 18 Aug 2008 13:23:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18601.19881.321732.937431@fireball.kivinen.iki.fi> Date: Mon, 18 Aug 2008 13:23:37 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 25 min X-Total-Time: 29 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > I'm not sure this is the normal case. I spent most of the IETF meeting > with the client connected, but the only traffic to the company was, > that every 5 minutes or so, the mail client would poll the IMAP > server. If the clients do gratuitous liveness checks all the time, > they would notice a crash, but if they wait for IMAP to fail, they > might miss it. Even if the machine only notices the crash when it does IMAP poll to server, the user most likely will not detect that crash at all, as he is not actively waiting for the email to come in, he will simply see the email notification to be delayed for some time, and as he is not doing anything active there, he will not actually notice that at all. I think your use is quite common, but fast crash discovery is not an issue in that kind of situations. The fast crash discovery and recovery is needed when you do active network operations, and in most of those cases the user will see the problem regardless how fast we recover (i.e. the VOIP call gets dropped, or too many packets get dropped in the video stream). It is bit hard to think about situation where it would be ok to have 10 second network break, where you need to recoved that faster than 30 seconds, but where that 10 second break will not distrupt user too much already. > Linux-based servers boot up in less than a minute. Quite a lot of PC server hardware require 30-60 seconds to go through the bios only (at least the server hardware we have in the office, seems to be much, much slower to boot up than desktop machines). Recovering from the crash in less than a minute is extremely good result for any real server. > "Hardware" > appliances are even faster, and the VPN software comes up very > quickly. Most of the ADSL boxes or WLAN boxes and similar do seem to require 30-60 second boot time before they are ready to server anything. Usually bigger boxes do require even more time. > Besides, most VPN software has some kind of button or command- > line to erase all the tunnels (setkey -F). That's like an > instantaneous reboot of "Bob". Users tend to use this whenever they > feel that "something is wrong". That is not an instanteneous reboot of "Bob", it is instanteneous reboot of "Alice". I.e local end clears all SAs thus when you try to send next packet, there is no need to do any recovery, you just start new negotiation to the "Bob", and "Bob" will clear its own SAs when it receives INITIAL_CONTACT notification. > > Also I think that in case of we receive hints that suggest other end > > is not reachable, one thing good implementations can do is to reduce > > the number of retries. I.e. there is really no point of trying 2 > > minutes for liveness check if you are getting ICMP host/port > > unreachable or INVALID_IKE_SPI notification back for all of your dozen > > requests. You could interpret that hint so that you can simply lower > > the retransmission times from dozen to 5 or so, over 30 seconds > > instead of few minutes. If the other end is still there, it should be > > getting one of the liveness checks anyways and reply to it. > > That's an idea, but you still have 30 seconds of both Bob and Alice > ready, but traffic does not go through. Nope, you have most likely 10-15 seconds of time when they are both capable of processing traffic. This is because the Alice will start recover why Bob is still down, i.e. the retransmission timers overlap with the actual recovery time of the Bob. I.e. when Bob goes down and starts rebootting (lets say that it is very fast reboot, taking less than minute, lets say 45 seconds). The Alice will notice after short while there is no traffic coming back (incoming ESP packets suddenly stop, thus traffic is changed to be one-way), it will decide to do liveness check, and starts IKE exchange to do that. Lets say it takes 10 seconds since Bob went down to start that (our default for one-way liveness check timer). It sends packets to black hole for 35 seconds, as Bob is not yet up (it might already get some ICMP host unreachable back for some of those depending on the network infrastructure). Then when Bob gets up it starts sending INVALID_IKE_SPI and that can then trigger Alice to shorten its default 5 minutes retry timer (for mobike, the retry timer must be longer than 2 minutes, as otherwise you loose connectivity in normal network switch situations too often). Alice could make it so that received INVALID_IKE_SPI notification shortens the retry timer so it is for example 15 seconds after receiving first of those notifications, or 30 seconds after receiving ICMP error. That would cause 15 seconds of time when both Alice and Bob are up and running, but where Alice still tries to recover, before it recovers from start. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 08:44: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 995423A6D29; Mon, 18 Aug 2008 08:44:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC5B3A68E8 for ; Mon, 18 Aug 2008 08:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI3LyL02wozq for ; Mon, 18 Aug 2008 08:44:09 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 5566E3A6D29 for ; Mon, 18 Aug 2008 08:44:09 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7IFiFp0024804 for ; Mon, 18 Aug 2008 11:44:15 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7IFiFN8180332 for ; Mon, 18 Aug 2008 09:44:15 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7IFiFij005479 for ; Mon, 18 Aug 2008 09:44:15 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7IFiF8a005470 for ; Mon, 18 Aug 2008 09:44:15 -0600 MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 08/18/2008 11:38:40 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 08/18/2008 11:38:40 AM, Serialize complete at 08/18/2008 11:38:40 AM, S/MIME Sign failed at 08/18/2008 11:38:41 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M1_05262008|May 26, 2008) at 08/18/2008 09:44:15, Serialize complete at 08/18/2008 09:44:15 To: ipsec@ietf.org X-KeepSent: CA0FEFAA:E6C14075-852574A9:00498682; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Mon, 18 Aug 2008 11:44:14 -0400 Subject: [IPsec] Suggested ikev2bis traffic selector clarification 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="===============1581410325==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1581410325== Content-Type: multipart/alternative; boundary="=_alternative 0055F375852574A9_=" This is a multipart message in MIME format. --=_alternative 0055F375852574A9_= Content-Type: text/plain; charset="US-ASCII" With at least one particular build of racoon2, I'm finding that I'm able to configure it such that it responds to the following traffic selector request: TSi: (ICMP, 2048-2048, 9.1.1.1-9.1.1.1), (0, 0-65535, 9.1.1.1-9.1.1.1) TSr: (ICMP, 2048-2048, 9.2.2.2-9.2.2.2), (0, 0-65535, 9.2.2.2-9.2.2.2) with the following response: TSi: (0, 2048-2048, 9.1.1.1-9.1.1.1) TSr: (0, 2048-2048, 9.2.2.2-9.2.2.2) What is surprising about this response is that it combines protocol 0 (all protocols) with a port specification. RFC 4301 hints that this is not correct; when it describes the SPD, it indicates that "several additional selectors depend on the Next Layer Protocol value", and goes on to define port, type and code values only for TCP, UDP, ICMP, ICMPv6, and MIPv6. Similarly, RFC 4306 hints that this is not correct; it states that "for protocols for which port is undefined, or if all ports are allowed," the start port "MUST be zero" and the end port "MUST be 65535." The only problem is that RFC 4306 doesn't clarify whether protocol 0 is a protocol for which port is undefined. I do believe from my reading of both RFCs 4301 and 4306 that it is reasonable to expect not to see a port specification for a traffic selector with protocol 0, and in fact from RFC 4301 it seems that a compliant implementation could not express such a specification in its SPD, so that an SA using this specification could not be accepted. Furthermore, allowing this specification is a weak security risk; it's not obvious to the casual observer that the tunnel for protocol=0, port=2048 can actually carry ICMP echo requests, but it can. I'd like to suggest that the ikev2bis draft clarify the traffic selector description to indicate that the port range must be 0-65535 for protocol 0, such as the following: o Start Port (2 octets) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined, including protocol 0; or if all ports are allowed, this ^^^^^^^^^^^^^^^^^^^^^^ field MUST be zero. For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, including protocol 0; or if all ports are allowed, this ^^^^^^^^^^^^^^^^^^^^^^ field MUST be 65535. For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field. Is that acceptable? By the way, I'm not trying to heap too much blame on racoon2 here. It was an accidental pathological config in the first place (protocol=ALL, sport=2048, dport=2048) that caused this pathological response to be sent. At the same time, I think it is helpful for implementations to know that this sort of traffic selector specification is invalid by definition and should not be sent or received. Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0055F375852574A9_= Content-Type: text/html; charset="US-ASCII"
With at least one particular build of racoon2, I'm finding that I'm able to configure it such that it responds to the following traffic selector request:

        TSi: (ICMP, 2048-2048, 9.1.1.1-9.1.1.1), (0, 0-65535, 9.1.1.1-9.1.1.1)
        TSr: (ICMP, 2048-2048, 9.2.2.2-9.2.2.2), (0, 0-65535, 9.2.2.2-9.2.2.2)

with the following response:

        TSi: (0, 2048-2048, 9.1.1.1-9.1.1.1)
        TSr: (0, 2048-2048, 9.2.2.2-9.2.2.2)

What is surprising about this response is that it combines protocol 0 (all protocols) with a port specification.  RFC 4301 hints that this is not correct; when it describes the SPD, it indicates that "several additional selectors depend on the Next Layer Protocol value", and goes on to define port, type and code values only for TCP, UDP, ICMP, ICMPv6, and MIPv6.  Similarly, RFC 4306 hints that this is not correct; it states that "for protocols for which port is undefined, or if all ports are allowed," the start port "MUST be zero" and the end port "MUST be 65535."  The only problem is that RFC 4306 doesn't clarify whether protocol 0 is a protocol for which port is undefined.

I do believe from my reading of both RFCs 4301 and 4306 that it is reasonable to expect not to see a port specification for a traffic selector with protocol 0, and in fact from RFC 4301 it seems that a compliant implementation could not express such a specification in its SPD, so that an SA using this specification could not be accepted.  Furthermore, allowing this specification is a weak security risk; it's not obvious to the casual observer that the tunnel for protocol=0, port=2048 can actually carry ICMP echo requests, but it can.  I'd like to suggest that the ikev2bis draft clarify the traffic selector description to indicate that the port range must be 0-65535 for protocol 0, such as the following:

   o  Start Port (2 octets) - Value specifying the smallest port number
     allowed by this Traffic Selector.  For protocols for which port is
     undefined, including protocol 0; or if all ports are allowed, this
                ^^^^^^^^^^^^^^^^^^^^^^
      field MUST be zero.  For the ICMP protocol, the two one-octet
      fields Type and Code are treated as a single 16-bit integer (with
      Type in the most significant eight bits and Code in the least
      significant eight bits) port number for the purposes of filtering
      based on this field.

  o  End Port (2 octets) - Value specifying the largest port number
     allowed by this Traffic Selector.  For protocols for which port is
     undefined, including protocol 0; or if all ports are allowed, this
                ^^^^^^^^^^^^^^^^^^^^^^
      field MUST be 65535.  For the ICMP protocol, the two one-octet
      fields Type and Code are treated as a single 16-bit integer (with
      Type in the most significant eight bits and Code in the least
      significant eight bits) port number for the purposed of filtering
      based on this field.
Is that acceptable?

By the way, I'm not trying to heap too much blame on racoon2 here.  It was an accidental pathological config in the first place (protocol=ALL, sport=2048, dport=2048) that caused this pathological response to be sent.  At the same time, I think it is helpful for implementations to know that this sort of traffic selector specification is invalid by definition and should not be sent or received.

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0055F375852574A9_=-- --===============1581410325== 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 --===============1581410325==-- From ipsec-bounces@ietf.org Mon Aug 18 08:45: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 A81743A6D4B; Mon, 18 Aug 2008 08:45:42 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BF93A6D4B for ; Mon, 18 Aug 2008 08:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_05=-1.11] 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 45u9IrH5P9wP for ; Mon, 18 Aug 2008 08:45:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 01D0F3A6D3B for ; Mon, 18 Aug 2008 08:45:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D83F1294005; Mon, 18 Aug 2008 18:45:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 84016294004; Mon, 18 Aug 2008 18:45:44 +0300 (IDT) Received: from [172.31.21.76] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7IFjhjI008595; Mon, 18 Aug 2008 18:45:43 +0300 (IDT) Message-Id: <6FA4BA87-B3DE-4059-A4FD-37D0E71A2007@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18601.19881.321732.937431@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 18 Aug 2008 18:07:22 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <18601.19881.321732.937431@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 Tero Depending on the IMAP client Alice is using she may or may not notice anything is wrong as long as Bob is down. One client I know pops up a message that connection to IMAP server has failed. But that doesn't matter, because there's nothing to do at that time, and also it doesn't involve the IKE/IPsec software. The IKE software gets the first indication that something is wrong when Bob boots up and sends an INVALID_SPI (or ICMP reject for UDP 4500). By that time Bob is up, so that's when the "several minutes" or "30 seconds" begin. That's considerably worse than the nearly instantaneous reconnect she can get with either QCD, SIR or birth certificates. I'm not sure why it's a good idea to reduce the time span in the presence of INVALID_IKE_SPI notifications. If 30 seconds is long enough to be sure we get a response from the real peer (in addition to an attacker) in the crash detection case, why is it not enough in the liveness check case? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 08:46:00 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 96E733A6D53; Mon, 18 Aug 2008 08:46:00 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300423A6D4F for ; Mon, 18 Aug 2008 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 SWRbPDnYCrm2 for ; Mon, 18 Aug 2008 08:45:55 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8C2A13A6D4A for ; Mon, 18 Aug 2008 08:45:55 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4D296294005; Mon, 18 Aug 2008 18:46:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 54F2D294004; Mon, 18 Aug 2008 18:46:01 +0300 (IDT) Received: from [172.31.21.76] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7IFjhjJ008595; Mon, 18 Aug 2008 18:46:00 +0300 (IDT) Message-Id: <8467A9A1-688E-44B2-986B-DDAC1081D788@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18601.19881.321732.937431@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 18 Aug 2008 18:45:59 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <18601.19881.321732.937431@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 Tero Depending on the IMAP client Alice is using she may or may not notice anything is wrong as long as Bob is down. One client I know pops up a message that connection to IMAP server has failed. But that doesn't matter, because there's nothing to do at that time, and also it doesn't involve the IKE/IPsec software. The IKE software gets the first indication that something is wrong when Bob boots up and sends an INVALID_SPI (or ICMP reject for UDP 4500). By that time Bob is up, so that's when the "several minutes" or "30 seconds" begin. That's considerably worse than the nearly instantaneous reconnect she can get with either QCD, SIR or birth certificates. I'm not sure why it's a good idea to reduce the time span in the presence of INVALID_IKE_SPI notifications. If 30 seconds is long enough to be sure we get a response from the real peer (in addition to an attacker) in the crash detection case, why is it not enough in the liveness check case? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 09:07: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 6C7B03A6A59; Mon, 18 Aug 2008 09:07:54 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617463A6A59 for ; Mon, 18 Aug 2008 09:07:53 -0700 (PDT) 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 X7xK1YXJ6VbN for ; Mon, 18 Aug 2008 09:07:52 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 8D3EC3A6978 for ; Mon, 18 Aug 2008 09:07:52 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7IG7wSf021084 for ; Mon, 18 Aug 2008 16:07:59 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m7IG7wKP013798 for ; Mon, 18 Aug 2008 12:07:58 -0400 (EDT) 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 m7IG0RS7022622; Mon, 18 Aug 2008 12:00:27 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7IG0QOf022621; Mon, 18 Aug 2008 12:00:26 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 18 Aug 2008 12:00:25 -0400 From: Dan McDonald To: Scott C Moonen Message-ID: <20080818160025.GC21406@kebe.east.sun.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org Subject: Re: [IPsec] Suggested ikev2bis traffic selector clarification 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, Aug 18, 2008 at 11:44:14AM -0400, Scott C Moonen wrote: > Similarly, RFC 4306 hints that this is not correct; it states that "for > protocols for which port is undefined, or if all ports are allowed," the > start port "MUST be zero" and the end port "MUST be 65535." The only > problem is that RFC 4306 doesn't clarify whether protocol 0 is a protocol > for which port is undefined. Consider a protocol like DNS which runs over either TCP or UDP while utilizing the same port. That'd be a perfect excuse for using proto=0, port!=0. > o Start Port (2 octets) - Value specifying the smallest port number > allowed by this Traffic Selector. For protocols for which port is > undefined, including protocol 0; or if all ports are allowed, this > ^^^^^^^^^^^^^^^^^^^^^^ > field MUST be zero. For the ICMP protocol, the two one-octet > fields Type and Code are treated as a single 16-bit integer (with > Type in the most significant eight bits and Code in the least > significant eight bits) port number for the purposes of filtering > based on this field. > > o End Port (2 octets) - Value specifying the largest port number > allowed by this Traffic Selector. For protocols for which port is > undefined, including protocol 0; or if all ports are allowed, this > ^^^^^^^^^^^^^^^^^^^^^^ > field MUST be 65535. For the ICMP protocol, the two one-octet > fields Type and Code are treated as a single 16-bit integer (with > Type in the most significant eight bits and Code in the least > significant eight bits) port number for the purposed of filtering > based on this field. > > Is that acceptable? Only if we don't think there will be policies that exploit TCP or UDP over the same port. I suppose the extra cut-and-paste line(s) of configuration (TCP line(s) + UDP line(s) + SCTP line(s)) would be acceptable, but let's at least think a little about it. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 12:02: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 1F69928C131; Mon, 18 Aug 2008 12:02:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DE328C1A8 for ; Mon, 18 Aug 2008 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRCuSHVIa8Gy for ; Mon, 18 Aug 2008 12:02:48 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 2B96228C1D2 for ; Mon, 18 Aug 2008 12:02:08 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7IJ2EjD007538 for ; Mon, 18 Aug 2008 15:02:14 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7IJ27xe183278 for ; Mon, 18 Aug 2008 13:02:08 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7IJ27m3010300 for ; Mon, 18 Aug 2008 13:02:07 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7IJ27s9010289 for ; Mon, 18 Aug 2008 13:02:07 -0600 MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 08/18/2008 02:55:47 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 08/18/2008 02:55:47 PM, Serialize complete at 08/18/2008 02:55:47 PM, S/MIME Sign failed at 08/18/2008 02:55:47 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M1_05262008|May 26, 2008) at 08/18/2008 13:02:07, Serialize complete at 08/18/2008 13:02:07 To: ipsec@ietf.org X-KeepSent: 38E40EF2:22864AB1-852574A9:00672EBF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Mon, 18 Aug 2008 15:02:07 -0400 Subject: [IPsec] poll: use of ADDITIONAL_TS_POSSIBLE 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="===============0167725136==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0167725136== Content-Type: multipart/alternative; boundary="=_alternative 0067FF0B852574A9_=" This is a multipart message in MIME format. --=_alternative 0067FF0B852574A9_= Content-Type: text/plain; charset="US-ASCII" I'm curious to learn how existing IKEv2 implementations are making use of ADDITIONAL_TS_POSSIBLE. I would greatly appreciate any responses to these questions: 1. Does your implementation support the full range of possible IKEv2 traffic selector specifications, including the possibility of a single SA covering a disjoint set of selectors (e.g., TCP port 53 + UDP port 53)? If not, does your implementation choose to send the optional N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it simply choose to narrow the traffic selectors without comment? 2. Does your implementation take any specific advantage of receiving N(ADDITIONAL_TS_POSSIBLE)? For example, if your implementation proposes a TS that covers TCP port 53 and UDP port 53, but receives in response a TS that covers only TCP port 53 plus N(ADDITIONAL_TS_POSSIBLE), does your implementation log detailed diagnostic information for this case, or perhaps even automatically start a negotiation to protect UDP port 53 on a separate SA? Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC 4306, my desire here is to gauge how common or useful it is in practice. Thanks in advance for your response, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0067FF0B852574A9_= Content-Type: text/html; charset="US-ASCII"
I'm curious to learn how existing IKEv2 implementations are making use of ADDITIONAL_TS_POSSIBLE.  I would greatly appreciate any responses to these questions:

1. Does your implementation support the full range of possible IKEv2 traffic selector specifications, including the possibility of a single SA covering a disjoint set of selectors (e.g., TCP port 53 + UDP port 53)?  If not, does your implementation choose to send the optional N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it simply choose to narrow the traffic selectors without comment?

2. Does your implementation take any specific advantage of receiving N(ADDITIONAL_TS_POSSIBLE)?  For example, if your implementation proposes a TS that covers TCP port 53 and UDP port 53, but receives in response a TS that covers only TCP port 53 plus N(ADDITIONAL_TS_POSSIBLE), does your implementation log detailed diagnostic information for this case, or perhaps even automatically start a negotiation to protect UDP port 53 on a separate SA?

Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC 4306, my desire here is to gauge how common or useful it is in practice.

Thanks in advance for your response,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0067FF0B852574A9_=-- --===============0167725136== 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 --===============0167725136==-- From ipsec-bounces@ietf.org Mon Aug 18 23:04: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 6BFCB3A6930; Mon, 18 Aug 2008 23:04:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFABC3A6930 for ; Mon, 18 Aug 2008 23:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 vgItixpiLsKo for ; Mon, 18 Aug 2008 23:04:23 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 988B73A689C for ; Mon, 18 Aug 2008 23:04:23 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7J62L6M001405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2008 01:02:23 -0500 From: "Yingzhe Wu" To: References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> In-Reply-To: <1218786554.7492.249.camel@fdetienn-laptop> Date: Mon, 18 Aug 2008 23:01:48 -0700 Message-ID: <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj+q3QOkgrmAgJQSkOhGbHf5SzetwDBzX2w Content-Language: en-us Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Frederic, > > YZ> Not quite sure I understand this. Are you comparing with native > IPsec > > implementation that binds SA to socket? Even so, when the tunnel > interface > > is first associated with SA, IPsec selector match needs to happen and > this > > is based on GRE key. > > That association could be based on the IKE_ID alone, not waiting for > the > traffic selector. In that case, the GRE selector in your proposal is > not > necessary. That is based on assumption that each GRE tunnel gets its own credential management, IKE_SA etc, the same example once given by Tero. Yes I agree this is one way to achieve it, but specific deployment may not go with that option, due to many reasons. > > Oh sorry; I still think of traffic selectors as a form of identity like > they were in IKEv1. Let me rephrase in terms of traffic selectors. > > What I meant is that for the security scheme to be complete, there must > be a validation of the negotiated traffic selectors vs. the IKE_SA > identity. Otherwise, this would allow any user allowed to create an > IKE_SA on LMA to negotiate any GRE key and hence access either > Enterprise-A or Enterprise-B which we intended to differentiate in the > first place. > > So just comparing the addresses is not sufficient in the general case. > There may be degenerate cases where sys admins rely on the ip addresses > only (e.g. because they administer both ends of the tunnel) for > authorization. > > By simply adding a validation statement (a "SHOULD authorize" + > explanation/recommendation) will make your specification a lot broader, > clearer and more secure, without changing the underlying proposal. > Yes agree, it can be in form of PAD entries. > > > > YZ> GRE key negotiation is currently out of scope, and we intend to > do just > > the traffic selection. > > ok thanks. So can you explain why the TSr key contains 0 instead of the > second half-key when sent by the initiator ? It is not a trick > questions > -- just for me to understand your rationale. > > If that makes no difference for you, I would rather have TSr contain > the > second half-key to make the intent of the protocol clear. > The draft was written before the scope was narrowed down to only the GRE key as IPsec selector, and it hasn't been updated. This needs to be changed and will have only specific value in TSr. Thanks, Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 23:04: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 D99563A69D7; Mon, 18 Aug 2008 23:04:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185303A6930 for ; Mon, 18 Aug 2008 23:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 vlmcWbLwXTmm for ; Mon, 18 Aug 2008 23:04:24 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 2BF623A682A for ; Mon, 18 Aug 2008 23:04:24 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7J604s6001383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2008 01:00:04 -0500 From: "Yingzhe Wu" To: References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> In-Reply-To: <1218786554.7492.249.camel@fdetienn-laptop> Date: Mon, 18 Aug 2008 23:00:09 -0700 Message-ID: <001d01c901c0$d69705a0$83c510e0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj+q3QOkgrmAgJQSkOhGbHf5SzetwDBzX2w Content-Language: en-us Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Frederic, > > YZ> Not quite sure I understand this. Are you comparing with native > IPsec > > implementation that binds SA to socket? Even so, when the tunnel > interface > > is first associated with SA, IPsec selector match needs to happen and > this > > is based on GRE key. > > That association could be based on the IKE_ID alone, not waiting for > the > traffic selector. In that case, the GRE selector in your proposal is > not > necessary. That is based on assumption that each GRE tunnel gets its own credential management, IKE_SA etc, the same example once given by Tero. Yes I agree this is one way to achieve it, but specific deployment may not go with that option, due to many reasons. > > Oh sorry; I still think of traffic selectors as a form of identity like > they were in IKEv1. Let me rephrase in terms of traffic selectors. > > What I meant is that for the security scheme to be complete, there must > be a validation of the negotiated traffic selectors vs. the IKE_SA > identity. Otherwise, this would allow any user allowed to create an > IKE_SA on LMA to negotiate any GRE key and hence access either > Enterprise-A or Enterprise-B which we intended to differentiate in the > first place. > > So just comparing the addresses is not sufficient in the general case. > There may be degenerate cases where sys admins rely on the ip addresses > only (e.g. because they administer both ends of the tunnel) for > authorization. > > By simply adding a validation statement (a "SHOULD authorize" + > explanation/recommendation) will make your specification a lot broader, > clearer and more secure, without changing the underlying proposal. > Yes agree, it can be in form of PAD entries. > > > > YZ> GRE key negotiation is currently out of scope, and we intend to > do just > > the traffic selection. > > ok thanks. So can you explain why the TSr key contains 0 instead of the > second half-key when sent by the initiator ? It is not a trick > questions > -- just for me to understand your rationale. > > If that makes no difference for you, I would rather have TSr contain > the > second half-key to make the intent of the protocol clear. > The draft was written before the scope was narrowed down to only the GRE key as IPsec selector, and it hasn't been updated. This needs to be changed and will have only specific value in TSr. Thanks, Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 18 23:04: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 60FD23A6A16; Mon, 18 Aug 2008 23:04:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FA93A6A0E for ; Mon, 18 Aug 2008 23:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 k0yqdf4v99Eq for ; Mon, 18 Aug 2008 23:04:46 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id CD6543A682A for ; Mon, 18 Aug 2008 23:04:46 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7J64q5E001506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2008 01:04:53 -0500 From: "Yingzhe Wu" To: References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> In-Reply-To: <1218786554.7492.249.camel@fdetienn-laptop> Date: Mon, 18 Aug 2008 23:04:57 -0700 Message-ID: <001f01c901c1$82787ca0$876975e0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj+q3QOkgrmAgJQSkOhGbHf5SzetwDBzX2w Content-Language: en-us Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Frederic, > > YZ> Not quite sure I understand this. Are you comparing with native > IPsec > > implementation that binds SA to socket? Even so, when the tunnel > interface > > is first associated with SA, IPsec selector match needs to happen and > this > > is based on GRE key. > > That association could be based on the IKE_ID alone, not waiting for > the > traffic selector. In that case, the GRE selector in your proposal is > not > necessary. That is based on assumption that each GRE tunnel gets its own credential management, IKE_SA etc, the same example once given by Tero. Yes I agree this is one way to achieve it, but specific deployment may not go with that option, due to many reasons. > > Oh sorry; I still think of traffic selectors as a form of identity like > they were in IKEv1. Let me rephrase in terms of traffic selectors. > > What I meant is that for the security scheme to be complete, there must > be a validation of the negotiated traffic selectors vs. the IKE_SA > identity. Otherwise, this would allow any user allowed to create an > IKE_SA on LMA to negotiate any GRE key and hence access either > Enterprise-A or Enterprise-B which we intended to differentiate in the > first place. > > So just comparing the addresses is not sufficient in the general case. > There may be degenerate cases where sys admins rely on the ip addresses > only (e.g. because they administer both ends of the tunnel) for > authorization. > > By simply adding a validation statement (a "SHOULD authorize" + > explanation/recommendation) will make your specification a lot broader, > clearer and more secure, without changing the underlying proposal. > Yes agree, it can be in form of PAD entries. > > > > YZ> GRE key negotiation is currently out of scope, and we intend to > do just > > the traffic selection. > > ok thanks. So can you explain why the TSr key contains 0 instead of the > second half-key when sent by the initiator ? It is not a trick > questions > -- just for me to understand your rationale. > > If that makes no difference for you, I would rather have TSr contain > the > second half-key to make the intent of the protocol clear. > The draft was written before the scope was narrowed down to only the GRE key as IPsec selector, and it hasn't been updated. This needs to be changed and will have only specific value in TSr. Thanks, Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 01:04:20 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248563A6A16; Tue, 19 Aug 2008 01:04:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265633A6A16 for ; Tue, 19 Aug 2008 01:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBg6VGBFj47u for ; Tue, 19 Aug 2008 01:04:17 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 11C1D3A6A0E for ; Tue, 19 Aug 2008 01:04:17 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KVMCS-0000mt-4u; Tue, 19 Aug 2008 10:04:20 +0200 X-Hashcash: 1:20:080819:ipsec@ietf.org::dsZJhduUEDXXVCUK:00034Oi From: arno@natisbad.org (Arnaud Ebalard) To: IETF IPsec 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: Tue, 19 Aug 2008 10:03:08 +0200 Message-ID: <87d4k577pf.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: [IPsec] I-D Action:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I was asked to also post the info on ipsecme, for those interested by the topic but which are not on mext (already posted there yesterday). > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : PF_KEY Extension as an Interface between > Mobile IPv6 and IPsec/IKE > Author(s) : A. Ebalard, S. Decugis > Filename : draft-ebalard-mext-pfkey-enhanced-migrate-00.txt > Pages : 21 > Date : 2008-08-18 > > This document describes the need for an interface between Mobile IPv6 > and IPsec/IKE and show how the two protocols can interwork. An > extension of the PF_KEY framework is proposed which allows smooth and > solid operation of IKE in a Mobile IPv6 environment. > > This document is heavily based on a previous draft [MIGRATE] written > by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply > reuses the MIGRATE mechanism defined in the expired document, removes > a companion extension (SADB_X_EXT_PACKET) based on implementation > feedback (complexity, limitations, ...) and fills the gap by very > simple changes to MIGRATE mechanism. This results in a more simple > and consistent mechanism, which also proved to be easier to > implement. This document is expected to serve as a continuation of > [MIGRATE] work. For that reason, the name of the extension has been > kept. > > PF_KEY MIGRATE message serves as a carrier for updated address > information for both the in-kernel IPsec structures (SP/SA) and those > maintained by the key managers. This includes in-kernel SP/SA > endpoints, key manager maintained equivalents and addresses used by > IKE_SA (current and to be negotiated). The extension is helpful for > assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for > the bootstrapping of mobile nodes and their movements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ebalard-mext-pfkey-enhanced-migrate-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. If you have comments/questions, do not hesitate. If you are interested by implementation/test details, there is more on the topic here: http://natisbad.org/MIPv6/ Cheers, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 01:31:20 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A3B3A6A6C; Tue, 19 Aug 2008 01:31:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0423A696D for ; Tue, 19 Aug 2008 01:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSDOCvWk+YvB for ; Tue, 19 Aug 2008 01:31:17 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id A5B7C3A6880 for ; Tue, 19 Aug 2008 01:31:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,234,1217808000"; d="scan'208,217";a="26119653" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 19 Aug 2008 08:30:38 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7J8Ubx4000705; Tue, 19 Aug 2008 14:00:37 +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 m7J8UaAJ006651; Tue, 19 Aug 2008 08:30:36 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 14:00:37 +0530 Received: from [64.103.178.248] ([64.103.178.248]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 14:00:36 +0530 Message-ID: <48AA8515.7020505@cisco.com> Date: Tue, 19 Aug 2008 14:02:21 +0530 From: Pratima Sethi User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> <18597.16630.682587.674433@fireball.kivinen.iki.fi> In-Reply-To: <18597.16630.682587.674433@fireball.kivinen.iki.fi> X-OriginalArrivalTime: 19 Aug 2008 08:30:36.0069 (UTC) FILETIME=[DA682550:01C901D5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15239; t=1219134637; x=1219998637; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=psethi@cisco.com; z=From:=20Pratima=20Sethi=20 |Subject:=20Re=3A=20[IPsec]=20Secure=20Crash=20Discovery=20 for=20IKEv2 |Sender:=20; bh=wfpNRYVA0WykcN5iKfvX/yvdVxFNN4mlHOK9jUH6u/c=; b=A+gM+E6nOmeiFWrImaQxs5WI1iVHO0CrFhUiHFX8o7fKC6t69gGT1ns61E thKI7pNumE9JEeUfX8tjbT+Q5B1q3weIGc0v9LIb0/3wrlxsxX9MXKzonkCH NvsP9UK5ho; Authentication-Results: ind-dkim-1; header.From=psethi@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: ipsec@ietf.org, ynir@checkpoint.com, fd@cisco.com, Pasi.Eronen@nokia.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1636142597==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1636142597== Content-Type: multipart/alternative; boundary="------------050905000206090701050503" This is a multi-part message in MIME format. --------------050905000206090701050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > Frederic Detienne writes: > >> On a side note, Yoav, Pratima and I think that Birth Certificates don't >> work well in practice. They may be sort of secure but they are power >> hungry. Both QCD and SIR are meant to be implemented on real gateways, >> with real memory and real CPU's. >> > > What kind of reasons you have for them not working in real > environments? For the Bob, they are cheaper than both SIR and QCD from > the computational point of view, as you need to generate only one > certificate for each reboot, and regardless how many IKE SAs you had > up, you do not need to do any additional computations. > Is there a specification of Birth Certiifcates that you can point us to ? From what I understand ,Bob generates a single certificate when he reboots, and will add that as a birth certificate payload, to the invalid_spi notification. If Bob only generates one certificate independent of the client Alice, Mallet( the MitM) can snoop and learn the birth certificate and replay this to any Alice connected to Bob. How does Alice trust that the information is a fresh valid packet generated by Bob and not a "constructed" packet from an attacker. - prati > For the Alice it requires checking one signature when they start > suspecting that the other end is not up and running (i.e. when they > are not receiving anything from the other end and they get INVALID SPI > exchange back). Note, that signature verification in RSA is quite > fast, usually in order of milliseconds, which is faster than what is > the normal round trip time. > > On the very slow devices there is quite often hardware to assist doing > RSA and Diffie-Hellman calculations anyways, as those calculations are > needed anyways for IKEv2. > > The signature verification for RSA keys is about 10 times faster than > Diffie-Hellman required for recreating the IKE SA. > > >>>> On the web page, you asked for comments about "constrained devices" >>>> like cell phones. For a cell phone that can implement IKEv2, keeping >>>> 16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA >>>> and ESP/AH SAs is anyway much more). >>>> >>> Yes. IKE SA state is in order of kilobytes or tens of kilobytes (if >>> large window of 32 is used, IKE SA MUST keep last 32 IKE packets all >>> the time, thus only that reply window takes 10-20 kB of memory...). I >>> do not really consider that memory usage an issue here at all (i.e >>> sounds artifical to even mention it). >>> >> I see. "nobody needs more than 640kb or RAM", uh :) funny. >> > > Nope. More like that there is no point of saving 0.1% of memory by > adding more code that consumes more memory than that... As the memory > is needed only on Alice, and she normally has just ONE IKE SA, the > total memory saving is around 16-32 bytes of memory in total. > > >> Guess what: there is still a market for embedded OSes that consume very >> little memory and those OSes still beat free (as in free beer) operating >> systems on that single point. >> > > I know, but we also do implementations on those platforms too, and I > know that currently those devices (phones for example) have quite a > lot of memory still (in orders of hundreds of kilobytes), thus adding > 32 bytes of memory in total, does not really matter there. > Implementing any of the proposals are going to use much more code > memory (and that is actually quite often more limited than RAM) than > that anyways. > > >>> In the same sense you would need >>> to mention that SIR requires n bytes of memory to keep the cookie >>> while doing the unauthenticated check :-) >>> >> Very good point! Just wrong. >> >> In stateless recovery >> --------------------- >> >> The cookie is computed with the same key as IKE uses for its >> anti-spoofing test. SIR does not require _any_ storage that IKE does not >> already require. I am ready to stand the argumentation but we certainly >> do not need O(n) storage (n=# of SA's). >> > > As n is 1 in Alice anyways, that does not really matter, and when you > generate Cookie and send it to the Bob, you need to keep that in > memory so you can verify it is same when Bob returns it back in the > reply, thus you need to keep it in memory during the exchange. Note, > that it is much faster (and more efficient) to just generate random > cookie, and store it in the memory, than use some cryptographic > algorithm to generate it, especially as Alice still has state (IKE > SA), thus there is no need to be stateless. > > >> In ticket based recovery >> ------------------------ >> SIR uses a cookie approach but apparently too secure for FUD. This >> method does not use more memory than Resumption. >> >> >>> On the other hand, I am not sure if either one of these are really >>> that useful, as in normal case the boot up sequence of the bob is >>> anyways going to be so long, that it has most likely already triggered >>> the liveness checks if there was active traffic going on between the >>> hosts. >>> >> er.. darn you caught me... let me guess... oh yeah! Because the >> failover/cluster case is really what real users out there are interested >> in ? maybe ? >> > > We are not talking about failrover or cluster, we are talking about > secure crash discovery. In any case there are ways to do cluster / > failover methods which do not require any coordination with the > client. > > >>> Also I think that in case of we receive hints that suggest other end >>> is not reachable, one thing good implementations can do is to reduce >>> the number of retries. I.e. there is really no point of trying 2 >>> minutes for liveness check if you are getting ICMP host/port >>> unreachable or INVALID_IKE_SPI notification back for all of your dozen >>> requests. You could interpret that hint so that you can simply lower >>> the retransmission times from dozen to 5 or so, over 30 seconds >>> instead of few minutes. If the other end is still there, it should be >>> getting one of the liveness checks anyways and reply to it. >>> >> How is this fundamentally different from what SIR is saying ? SIR does >> that kind of dance, only much faster and introduces an payload so that >> it can collect hints of an attack as well and _log_ what is going on. >> > > Yes, but the other method is already there, and can already be used > with ANY standard complient IKEv2 implementation, without requiring > any extra protocol work. It security properties are about the same as > in SIR, and its security is not that much worse than in SIR. So if we > want to do something that is more secure than what there is already > now, then I would like to make that then really secure. > --------------050905000206090701050503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tero Kivinen wrote: 
Frederic Detienne writes:
  
On a side note, Yoav, Pratima and I think that Birth Certificates don't
work well in practice. They may be sort of secure but they are power
hungry. Both QCD and SIR are meant to be implemented on real gateways,
with real memory and real CPU's.
    

What kind of reasons you have for them not working in real
environments? For the Bob, they are cheaper than both SIR and QCD from
the computational point of view, as you need to generate only one
certificate for each reboot, and regardless how many IKE SAs you had
up, you do not need to do any additional computations.
Is there a specification of Birth Certiifcates that you can point us to ?

>From what I understand ,Bob generates a single certificate when he reboots, and will add that as  a birth certificate payload, to the invalid_spi notification. If  Bob only generates one certificate independent of the client Alice, Mallet( the MitM) can snoop and learn the birth certificate and replay this to any Alice connected to Bob. How does Alice trust that the information is a fresh valid packet generated by Bob and not a "constructed" packet from an attacker.

- prati
For the Alice it requires checking one signature when they start
suspecting that the other end is not up and running (i.e. when they
are not receiving anything from the other end and they get INVALID SPI
exchange back). Note, that signature verification in RSA is quite
fast, usually in order of milliseconds, which is faster than what is
the normal round trip time.

On the very slow devices there is quite often hardware to assist doing
RSA and Diffie-Hellman calculations anyways, as those calculations are
needed anyways for IKEv2.

The signature verification for RSA keys is about 10 times faster than
Diffie-Hellman required for recreating the IKE SA. 

  
On the web page, you asked for comments about "constrained devices"
like cell phones. For a cell phone that can implement IKEv2, keeping
16-32 extra bytes per IKE_SA is trivial (the state needed for IKE_SA
and ESP/AH SAs is anyway much more).
        
Yes. IKE SA state is in order of kilobytes or tens of kilobytes (if
large window of 32 is used, IKE SA MUST keep last 32 IKE packets all
the time, thus only that reply window takes 10-20 kB of memory...). I
do not really consider that memory usage an issue here at all (i.e
sounds artifical to even mention it).
      
I see. "nobody needs more than 640kb or RAM", uh :) funny.
    

Nope. More like that there is no point of saving 0.1% of memory by
adding more code that consumes more memory than that... As the memory
is needed only on Alice, and she normally has just ONE IKE SA, the
total memory saving is around 16-32 bytes of memory in total. 

  
Guess what: there is still a market for embedded OSes that consume very
little memory and those OSes still beat free (as in free beer) operating
systems on that single point.
    

I know, but we also do implementations on those platforms too, and I
know that currently those devices (phones for example) have quite a
lot of memory still (in orders of hundreds of kilobytes), thus adding
32 bytes of memory in total, does not really matter there.
Implementing any of the proposals are going to use much more code
memory (and that is actually quite often more limited than RAM) than
that anyways.

  
 In the same sense you would need
to mention that SIR requires n bytes of memory to keep the cookie
while doing the unauthenticated check :-)
      
Very good point! Just wrong.

In stateless recovery
---------------------

The cookie is computed with the same key as IKE uses for its
anti-spoofing test. SIR does not require _any_ storage that IKE does not
already require. I am ready to stand the argumentation but we certainly
do not need O(n) storage (n=# of SA's).
    

As n is 1 in Alice anyways, that does not really matter, and when you
generate Cookie and send it to the Bob, you need to keep that in
memory so you can verify it is same when Bob returns it back in the
reply, thus you need to keep it in memory during the exchange. Note,
that it is much faster (and more efficient) to just generate random
cookie, and store it in the memory, than use some cryptographic
algorithm to generate it, especially as Alice still has state (IKE
SA), thus there is no need to be stateless.

  
In ticket based recovery
------------------------
SIR uses a cookie approach but apparently too secure for FUD. This
method does not use more memory than Resumption.

    
On the other hand, I am not sure if either one of these are really
that useful, as in normal case the boot up sequence of the bob is
anyways going to be so long, that it has most likely already triggered
the liveness checks if there was active traffic going on between the
hosts.
      
er.. darn you caught me... let me guess... oh yeah! Because the
failover/cluster case is really what real users out there are interested
in ? maybe ?
    

We are not talking about failrover or cluster, we are talking about
secure crash discovery. In any case there are ways to do cluster /
failover methods which do not require any coordination with the
client. 

  
Also I think that in case of we receive hints that suggest other end
is not reachable, one thing good implementations can do is to reduce
the number of retries. I.e. there is really no point of trying 2
minutes for liveness check if you are getting ICMP host/port
unreachable or INVALID_IKE_SPI notification back for all of your dozen
requests. You could interpret that hint so that you can simply lower
the retransmission times from dozen to 5 or so, over 30 seconds
instead of few minutes. If the other end is still there, it should be
getting one of the liveness checks anyways and reply to it.
      
How is this fundamentally different from what SIR is saying ? SIR does
that kind of dance, only much faster and introduces an payload so that
it can collect hints of an attack as well and _log_ what is going on.
    

Yes, but the other method is already there, and can already be used
with ANY standard complient IKEv2 implementation, without requiring
any extra protocol work. It security properties are about the same as
in SIR, and its security is not that much worse than in SIR. So if we
want to do something that is more secure than what there is already
now, then I would like to make that then really secure.

--------------050905000206090701050503-- --===============1636142597== 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 --===============1636142597==-- From ipsec-bounces@ietf.org Tue Aug 19 02:19: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 4FA0928C16C; Tue, 19 Aug 2008 02:19:42 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B2C28C16C for ; Tue, 19 Aug 2008 02:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, 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 WOqNJQFQMdKm for ; Tue, 19 Aug 2008 02:19:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 05C5628C133 for ; Tue, 19 Aug 2008 02:19:34 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5B0CE294006; Tue, 19 Aug 2008 12:19:20 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6A4EA294001; Tue, 19 Aug 2008 12:19:19 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7J9JJjI019792; Tue, 19 Aug 2008 12:19:19 +0300 (IDT) Message-Id: <4FD341C1-73DA-4315-A4D6-F428D0A5FE3C@checkpoint.com> From: Yoav Nir To: Pratima Sethi In-Reply-To: <48AA8515.7020505@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 19 Aug 2008 12:19:18 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> <18597.16630.682587.674433@fireball.kivinen.iki.fi> <48AA8515.7020505@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org, fd@cisco.com, Pasi.Eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 Aug 19, 2008, at 11:32 AM, Pratima Sethi wrote: > Tero Kivinen wrote: >> >> Frederic Detienne writes: >> >>> On a side note, Yoav, Pratima and I think that Birth Certificates >>> don't >>> work well in practice. They may be sort of secure but they are power >>> hungry. Both QCD and SIR are meant to be implemented on real >>> gateways, >>> with real memory and real CPU's. >>> >> What kind of reasons you have for them not working in real >> environments? For the Bob, they are cheaper than both SIR and QCD >> from >> the computational point of view, as you need to generate only one >> certificate for each reboot, and regardless how many IKE SAs you had >> up, you do not need to do any additional computations. >> > Is there a specification of Birth Certiifcates that you can point us > to ? > > From what I understand ,Bob generates a single certificate when he > reboots, and will add that as a birth certificate payload, to the > invalid_spi notification. If Bob only generates one certificate > independent of the client Alice, Mallet( the MitM) can snoop and > learn the birth certificate and replay this to any Alice connected > to Bob. How does Alice trust that the information is a fresh valid > packet generated by Bob and not a "constructed" packet from an > attacker. > > - prati There is no real specification of birth certificates, just an idea in email from 7 years ago. Such certificates would not be full X.509 certificates. They should include two fields: a public key, and a birth date (or restart counter), plus of course a signature using private key matching the public key, so it's a self-signed certificate. When bob reboots, it signs a new certificate with the same public key, but a newer date or counter. During the AUTH exchange, Bob sends the certificate (with restart counter at 17) to Alice. Alice verifies nothing, just stores it. When Bob reboots, he creates a certificate with restart counter 18. When Alice sends traffic, Bob attaches the new certificate to the INVALID_SPI or INVALID_IKE_SPI notification. Now Alice validates that (1) the public key is the same, and (2) the restart counter is greater than that stored with the IKE SA, and (3) the signature verifies. That's how Alice knows that Bob really rebooted in between. Nice idea, but I see trouble with key management, and also with signature agility. We probably don't want to add algorithm negotiation, so SHA1+RSA? SHA1+DSA? SHA-256+ECDSA? It also makes everything more complicated. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 03:06:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2960F3A69D1; Tue, 19 Aug 2008 03:06:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A38D3A69D1 for ; Tue, 19 Aug 2008 03:06:05 -0700 (PDT) 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 79ONErmJDNpP for ; Tue, 19 Aug 2008 03:06:04 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 81E7D3A6882 for ; Tue, 19 Aug 2008 03:06:04 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id m7JA5q0U000144 for ; Tue, 19 Aug 2008 19:05:52 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id m7JA5qiK004754 for ipsec@ietf.org; Tue, 19 Aug 2008 19:05:52 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id VAA04752; Tue, 19 Aug 2008 19:05:52 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id m7JA5pMA017024 for ; Tue, 19 Aug 2008 19:05:51 +0900 (JST) Received: by toshiba.co.jp id m7JA5phJ006982; Tue, 19 Aug 2008 19:05:51 +0900 (JST) To: ipsec@ietf.org In-Reply-To: Message from Dan McDonald of "Mon, 18 Aug 2008 12:00:25 -0400." <20080818160025.GC21406@kebe.east.sun.com> Date: Tue, 19 Aug 2008 19:05:51 +0900 Message-Id: <200808191005.m7JA5phJ006982@toshiba.co.jp> From: atsushi.fukumoto@toshiba.co.jp Subject: Re: [IPsec] Suggested ikev2bis traffic selector clarification 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 Dan McDonald wrote: > Consider a protocol like DNS which runs over either TCP or UDP while > utilizing the same port. That'd be a perfect excuse for using proto=0, > port!=0. That will leave a question what to do with ICMP or MH. Also, any future protocol with protocol field. As for the racoon2 behavior in question, it is somewhat intentional feature, as I saw it not prohibited and I decided to let the kernel IPsec routine decide what to do with it, although probably racoon2 should issue a warning message, at least. I can accept prohibiting it. 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 Tue Aug 19 03:21:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C7E3A689F; Tue, 19 Aug 2008 03:21:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027DD3A6893 for ; Tue, 19 Aug 2008 03:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 hxBc9+F1EdfT for ; Tue, 19 Aug 2008 03:21:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D2D023A6919 for ; Tue, 19 Aug 2008 03:21:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7JAHntV004653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 13:17:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7JAHnck008132; Tue, 19 Aug 2008 13:17:49 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18602.40397.652655.331175@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 13:17:49 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <6FA4BA87-B3DE-4059-A4FD-37D0E71A2007@checkpoint.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <18601.19881.321732.937431@fireball.kivinen.iki.fi> <6FA4BA87-B3DE-4059-A4FD-37D0E71A2007@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 19 min X-Total-Time: 21 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > The IKE software gets the first indication that something is wrong > when Bob boots up and sends an INVALID_SPI (or ICMP reject for UDP > 4500). Note, that Bob does not send INVALID_SPI until Alice sends something to Bob. As I told, in our implementation if the traffic is only one way (i.e. Alice sends packet, but Bob does not reply) then the liveness check is started 10 seconds after last packet from Bob is received (after the liveness check successed, then that is accepted as valid case of one-way traffic, i.e. no second liveness check is done before situation changes). Thus Alice is already doing liveness check while Bob is booting, as I explained in my last message. > By that time Bob is up, so that's when the "several minutes" or > "30 seconds" begin. That's considerably worse than the nearly > instantaneous reconnect she can get with either QCD, SIR or birth > certificates. No, the several minutes starts quite quickly after the traffic is changed to one way, i.e. after Alice sends one packet and Bob does not reply to that. > I'm not sure why it's a good idea to reduce the time span in the > presence of INVALID_IKE_SPI notifications. If 30 seconds is long > enough to be sure we get a response from the real peer (in addition to > an attacker) in the crash detection case, why is it not enough in the > liveness check case? In MOBIKE 2 minutes was not enough for waiting for the response from real peer, as you might need to try 3-4 different IP address pairs before you find correct working address (3 if one end has 2 IP-address and other 1, and 4 if both ends have IP-addresses). For each you need to send 3-4 tries, which means you are sure you cannot find working pair only after dozen or so packets, and with exponential backoff that is long time (actually you need to limit the max backoff to get any reasonable recovery, in our cases we only double the timer up to 6 seconds (i.e. packets are sent 0.5, 1, 2, 4, 6, 6 second intervals)). To send 12 packets takes more than minute already even with that, and if you have more than 2 IP-addresses (for example both IPv4 and IPv6 addresses in both ends, plus multiple interfaces on the Alice end (wlan, gprs, fixed ethernet)) you might end up in quite many retransmissions before you find out working IP-address. Good thing with MOBIKE is that you sometimes do get notification from the network (link goes down etc) immediately when the addresses change. Bad thing is that sometimes you need to run DHCP etc to get the address you need to use, so that will even more add delay to recovery. 30 seconds is much faster than the 3-5 minutes you need to wait in normal case to be sure that the other is not reachable. On the other hand there are normal operational cases where there is 30 second - 60 second delays even when nothing is wrong, just because you roamed out of the range of the WLAN network you happened to use. Because of this there is not really point of trying to get sub-second recover times, when other delays are still in the order of tens of seconds or minutes. Because of that I would much rather have the birth certificates or the QCD as they do offer cryptogarphic response that the other end is down, thus they do offer something more than what can be achieved now with liveness checks. SIR on the other hand does not offer that much more compared to normal liveness check, so I do not consider that an good option. But in all cases we need to think where this will be useful, and does it really help that much in common usage scenarios. In normal cases I would consider crashing SGW very uncommon situation, compared to for example roaming happening in the MOBIKE case. I would consider year a minimum uptime for real SGW, thus this secure crash recovery protocol is only needed once per year or so. If your SGW crashes more often than once per year, it is better to use resources to fix the SGW software than to make protocol to recover from those crashes. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 03:22: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 BEF243A685E; Tue, 19 Aug 2008 03:22:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB003A68D7 for ; Tue, 19 Aug 2008 03:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 tA33HZXSAjZB for ; Tue, 19 Aug 2008 03:22:56 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 53B713A6833 for ; Tue, 19 Aug 2008 03:22:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,235,1217808000"; d="scan'208";a="26131519" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 19 Aug 2008 10:16:16 +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 m7JAGGxs010042; Tue, 19 Aug 2008 15:46:16 +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 m7JAGHtQ016539; Tue, 19 Aug 2008 10:16:17 GMT Received: from xfe-blr-412.apac.cisco.com ([64.104.140.152]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 15:46:16 +0530 Received: from [64.103.168.62] ([64.103.168.62]) by xfe-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 15:46:15 +0530 Message-ID: <48AA9DD8.90206@cisco.com> Date: Tue, 19 Aug 2008 15:48:01 +0530 From: Pratima Sethi User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Yoav Nir References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> <18597.16630.682587.674433@fireball.kivinen.iki.fi> <48AA8515.7020505@cisco.com> <4FD341C1-73DA-4315-A4D6-F428D0A5FE3C@checkpoint.com> In-Reply-To: <4FD341C1-73DA-4315-A4D6-F428D0A5FE3C@checkpoint.com> X-OriginalArrivalTime: 19 Aug 2008 10:16:15.0850 (UTC) FILETIME=[9D35F4A0:01C901E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2809; t=1219140976; x=1220004976; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=psethi@cisco.com; z=From:=20Pratima=20Sethi=20 |Subject:=20Re=3A=20[IPsec]=20Secure=20Crash=20Discovery=20 for=20IKEv2 |Sender:=20; bh=PGrJaBKZCFKkmOK9awRGUhiNTiukTG+O+pYhbuw9+8g=; b=jg83T1O3zishoriguiNaKhvQ0XO3Uabu9gdVQd8pon4QST98XhoA7KLtz8 P9Db9bObOrE6+/Dh0dJmUAse6Efe/h6eMjBd0btjz9IRQlTQfYf3fYwOhM2B SAdtc6oAck; Authentication-Results: ind-dkim-2; header.From=psethi@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Cc: ipsec@ietf.org, fd@cisco.com, Pasi.Eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org thanks for the explanation of the exchange. I had forgotten that this required a pre-exchange of the certificate. - prati Yoav Nir wrote: > > On Aug 19, 2008, at 11:32 AM, Pratima Sethi wrote: > >> Tero Kivinen wrote: >>> >>> Frederic Detienne writes: >>> >>>> On a side note, Yoav, Pratima and I think that Birth Certificates >>>> don't >>>> work well in practice. They may be sort of secure but they are power >>>> hungry. Both QCD and SIR are meant to be implemented on real gateways, >>>> with real memory and real CPU's. >>>> >>> What kind of reasons you have for them not working in real >>> environments? For the Bob, they are cheaper than both SIR and QCD from >>> the computational point of view, as you need to generate only one >>> certificate for each reboot, and regardless how many IKE SAs you had >>> up, you do not need to do any additional computations. >>> >> Is there a specification of Birth Certiifcates that you can point us >> to ? >> >> From what I understand ,Bob generates a single certificate when he >> reboots, and will add that as a birth certificate payload, to the >> invalid_spi notification. If Bob only generates one certificate >> independent of the client Alice, Mallet( the MitM) can snoop and >> learn the birth certificate and replay this to any Alice connected to >> Bob. How does Alice trust that the information is a fresh valid >> packet generated by Bob and not a "constructed" packet from an attacker. >> >> - prati > > There is no real specification of birth certificates, just an idea in > email from 7 years ago. > > Such certificates would not be full X.509 certificates. They should > include two fields: a public key, and a birth date (or restart > counter), plus of course a signature using private key matching the > public key, so it's a self-signed certificate. > > When bob reboots, it signs a new certificate with the same public key, > but a newer date or counter. > > During the AUTH exchange, Bob sends the certificate (with restart > counter at 17) to Alice. Alice verifies nothing, just stores it. > When Bob reboots, he creates a certificate with restart counter 18. > When Alice sends traffic, Bob attaches the new certificate to the > INVALID_SPI or INVALID_IKE_SPI notification. > Now Alice validates that (1) the public key is the same, and (2) the > restart counter is greater than that stored with the IKE SA, and (3) > the signature verifies. > > That's how Alice knows that Bob really rebooted in between. > > Nice idea, but I see trouble with key management, and also with > signature agility. We probably don't want to add algorithm > negotiation, so SHA1+RSA? SHA1+DSA? SHA-256+ECDSA? > > It also makes everything more complicated. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 05:03:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1C93A69E4; Tue, 19 Aug 2008 05:03:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97413A68E0 for ; Tue, 19 Aug 2008 05:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 IqRgYJz-w35r for ; Tue, 19 Aug 2008 05:03:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7E13A68BD for ; Tue, 19 Aug 2008 05:03:21 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7JC1dLn007960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 15:01:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7JC1Z7M012532; Tue, 19 Aug 2008 15:01:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18602.46623.554461.467948@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 15:01:35 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 10 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: [IPsec] poll: use of ADDITIONAL_TS_POSSIBLE 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 Scott C Moonen writes: > I'm curious to learn how existing IKEv2 implementations are making use of > ADDITIONAL_TS_POSSIBLE. I would greatly appreciate any responses to these > questions: > > 1. Does your implementation support the full range of possible IKEv2 > traffic selector specifications, including the possibility of a single SA > covering a disjoint set of selectors (e.g., TCP port 53 + UDP port 53)? If > not, does your implementation choose to send the optional > N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it simply choose to > narrow the traffic selectors without comment? We do support full range of possible IKEv2 traffic selectors, but do not use ADDITIONAL_TS_POSSIBLE. There are some limitations of invalid combinatins (i.e. we do not allow traffic selectors where source selector is for UDP only and destination selector is TCP only), but there is possibility to configure for example TCP port 53 and UDP port 53 when both ends are configure properly. > 2. Does your implementation take any specific advantage of receiving > N(ADDITIONAL_TS_POSSIBLE)? No. > For example, if your implementation proposes a > TS that covers TCP port 53 and UDP port 53, but receives in response a TS > that covers only TCP port 53 plus N(ADDITIONAL_TS_POSSIBLE), does your > implementation log detailed diagnostic information for this case, or > perhaps even automatically start a negotiation to protect UDP port 53 on a > separate SA? In our case we simply narrow the traffic selectors silently to range that is acceptable the policy. In that case the initiator will start new negotiation when packet is received that is outside the negotiated traffic selectors, and as we always send the selectors from data packet, the responder will correctly narrow down to that another set. > Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC 4306, > my desire here is to gauge how common or useful it is in practice. As the ADDITIONAL_TS_POSSIBLE is not mandatory the initiator cannot really use it for anything. If it would be mandatory it could after the negotiation where responder narrowed the traffic selectors check if there is ADDITIONAL_TS_POSSIBLE possible and if not, it could mark that policy rule so it will not cause additional triggers anymore. If that ADDITIONAL_TS_POSSIBLE is there then it must keep the trigger rules still there for those ranges which are not covered by the negotiated SA, so packets to those ranges will cause new SAs to be negotiated. But as it is not mandatory, the initiator cannot trust the fact that there is no ADDITIONAL_TS_POSSIBLE, thus it needs to keep the trigger rules there for those ranges which are not covered by negotiated SAs so effectively it simply does not do any special handling for the ADDITIONAL_TS_POSSIBLE. The situation would be completely different if the notification would be NO_ADDITIONAL_TS_POSSIBLE, then by receiving it the initiator would know that it can remove the trigger rules for that specific policy rule, as there is no point of trying to negotiate anything outside the current negotiated SAs for that policy rule. So currently I think ADDITIONAL_TS_POSSIBLE is really not useful in any implementation. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 05:18: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 D45503A68E0; Tue, 19 Aug 2008 05:18:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94D53A68E0 for ; Tue, 19 Aug 2008 05:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 9LEHTY1aiwvN for ; Tue, 19 Aug 2008 05:18:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D0AE13A680D for ; Tue, 19 Aug 2008 05:18:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7JCF4XC011592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 15:15:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7JCF3Tq005227; Tue, 19 Aug 2008 15:15:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18602.47431.660136.328236@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 15:15:03 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 5 min X-Total-Time: 12 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > That is based on assumption that each GRE tunnel gets its own credential > management, IKE_SA etc, the same example once given by Tero. Yes I agree > this is one way to achieve it, but specific deployment may not go with that > option, due to many reasons. Can you list those reasons. Only thing I can think of is to avoid overhead of separate IKE SA (and the negotiation of it), but as we are talking with long term connections (i.e. mostly static configuration as far as I understand), that is not very important. For example in our default settings are so that there is assumed to be same amount of IKE SAs and IPsec SAs (i.e. one IKE SA per IPsec SA). This is normally the case for VPNs access, especially for IKEv2, as the traffic selectors can collect all data to one IPsec SA and each client has separate authentication data anyways. Note, that those IKE SAs can share same authentication data if they want, there is no requirement for the authentication do be different for all IKE SAs. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 05:34: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 C97213A6A7F; Tue, 19 Aug 2008 05:34:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D273A6880 for ; Tue, 19 Aug 2008 05:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.441, 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 ZzyLCUR6VrVt for ; Tue, 19 Aug 2008 05:34:01 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 146D53A69DB for ; Tue, 19 Aug 2008 05:33:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9B296294009; Tue, 19 Aug 2008 15:33:26 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A5778294007; Tue, 19 Aug 2008 15:33:25 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7JCXOjI012281; Tue, 19 Aug 2008 15:33:24 +0300 (IDT) Message-Id: From: Yoav Nir To: Scott C Moonen In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 19 Aug 2008 15:33:23 +0300 References: X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] poll: use of ADDITIONAL_TS_POSSIBLE 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="===============1894818532==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1894818532== Content-Type: multipart/alternative; boundary=Apple-Mail-30-323835189 --Apple-Mail-30-323835189 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Scott On Aug 18, 2008, at 10:02 PM, Scott C Moonen wrote: > > I'm curious to learn how existing IKEv2 implementations are making > use of ADDITIONAL_TS_POSSIBLE. I would greatly appreciate any > responses to these questions: I'm kind of curious about that too. There's the ADDITIONAL_TS_POSSIBLE notification, but lack of it is not a clear indication that this SA covers everything. > 1. Does your implementation support the full range of possible IKEv2 > traffic selector specifications, including the possibility of a > single SA covering a disjoint set of selectors (e.g., TCP port 53 + > UDP port 53)? If not, does your implementation choose to send the > optional N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it > simply choose to narrow the traffic selectors without comment? We just narrow the traffic selectors without comment, based on the (what we assume to be) packet selectors. We don't send this notification > 2. Does your implementation take any specific advantage of receiving > N(ADDITIONAL_TS_POSSIBLE)? For example, if your implementation > proposes a TS that covers TCP port 53 and UDP port 53, but receives > in response a TS that covers only TCP port 53 plus > N(ADDITIONAL_TS_POSSIBLE), does your implementation log detailed > diagnostic information for this case, or perhaps even automatically > start a negotiation to protect UDP port 53 on a separate SA? No. We don't send it, and we ignore it if received. We send the packet selectors in our proposal, so if the peer is working correctly, the packet chosen was TCP 53. If the need ever arises for UDP 53, then and only then we will negotiate an SA for UDP 53. Note that all this is theory, because our UI only lets you configure subnets or ranges, and so our proposals are always for protocol 0 and all ports. It's still true for other subnets - we don't send ADDITIONAL_TS_POSSIBLE if there are other subnets that we haven't negotiated for. > Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC > 4306, my desire here is to gauge how common or useful it is in > practice. IMO, not very useful > Thanks in advance for your response, --Apple-Mail-30-323835189 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Scott

On = Aug 18, 2008, at 10:02 PM, Scott C Moonen wrote:


I'm curious to learn how existing IKEv2 = implementations are making use of ADDITIONAL_TS_POSSIBLE.  I would = greatly appreciate any responses to these questions: =

I'm kind of curious about that too. There's = the ADDITIONAL_TS_POSSIBLE notification, but lack of it is not a clear = indication that this SA covers everything.

1. Does your = implementation support the full range of possible IKEv2 traffic selector = specifications, including the possibility of a single SA covering a = disjoint set of selectors (e.g., TCP port 53 + UDP port 53)?  If = not, does your implementation choose to send the optional = N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it simply choose to = narrow the traffic selectors without comment? =

We just narrow the traffic selectors without = comment, based on the (what we assume to be) packet selectors. We don't = send this notification

2. Does your implementation take any = specific advantage of receiving N(ADDITIONAL_TS_POSSIBLE)?  For = example, if your implementation proposes a TS that covers TCP port 53 = and UDP port 53, but receives in response a TS that covers only TCP port = 53 plus N(ADDITIONAL_TS_POSSIBLE), does your implementation log detailed = diagnostic information for this case, or perhaps even automatically = start a negotiation to protect UDP port 53 on a separate SA? =

No. We don't send it, and we ignore it if = received. We send the packet selectors in our proposal, so if the peer = is working correctly, the packet chosen was TCP 53.  If the need = ever arises for UDP 53, then and only then we will negotiate an SA for = UDP 53.  Note that all this is theory, because our UI only lets you = configure subnets or ranges, and so our proposals are always for = protocol 0 and all ports. It's still true for other subnets - we don't = send ADDITIONAL_TS_POSSIBLE if there are other subnets that we haven't = negotiated for.

Since generation of N(ADDITIONAL_TS_POSSIBLE) is not = required by RFC 4306, my desire here is to gauge how common or useful it = is in practice.

IMO, not very = useful

Thanks in advance for your response, =

= --Apple-Mail-30-323835189-- --===============1894818532== 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 --===============1894818532==-- From ipsec-bounces@ietf.org Tue Aug 19 05:36:18 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 66BBB3A6933; Tue, 19 Aug 2008 05:36:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E38F3A681B for ; Tue, 19 Aug 2008 05:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 YNUJqeJWPZkN for ; Tue, 19 Aug 2008 05:36:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB5E3A6A4F for ; Tue, 19 Aug 2008 05:36:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7JCXaD0004949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 15:33:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7JCXW6J012879; Tue, 19 Aug 2008 15:33:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18602.48540.840788.6761@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 15:33:32 +0300 From: Tero Kivinen To: Pratima Sethi In-Reply-To: <48AA8515.7020505@cisco.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> <18597.16630.682587.674433@fireball.kivinen.iki.fi> <48AA8515.7020505@cisco.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 17 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, fd@cisco.com, ynir@checkpoint.com Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pratima Sethi writes: > Is there a specification of Birth Certiifcates that you can point us > to ? No, that was never written to draft form of its own. It was presented on this list by Bill Sommerfeld long time ago. It has been explained in few drafts quite shortly, for example in the http://tools.ietf.org/html/draft-ietf-ipsec-soi-features-01 section 3.5: ---------------------------------------------------------------------- 3.5 Birth certificates Assume Alice and Bob have an SA established, and that Bob crashes and restarts. Alice will send a packet into an SA that Bob doesn't know about. Birth certificates are a method for letting Alice know that the SA is no longer alive. It is desirable that such a mechanism be inexpensive for Bob. If a mechanism required a lot of computation, for instance, having Bob sign a customized message saying, "This SA didn't decrypt properly. Perhaps it's because it's a reused SA number from before I crashed" or "unknown SPI", then there is an easy DOS attack on Bob's limited computation by sending him bogus messages. If Bob sends totally unauthenticated messages, it is difficult for Alice to act on them, since an active attacker could send her "no such SPI" messages to cause her to close connections. The idea of a birth certificate, originated in the IPsec Working Group by Bill Sommerfeld, is that Bob should have a monotonically increasing number that increases each time Bob restarts. When Bob restarts, he signs a message saying, "this is my incarnation number". When Bob creates an SA, Bob optionally sends his birth certificate. Alice can optionally keep this certificate with her SA. Then, if Alice ever receives an error message from Bob with a birth certificate with a higher incarnation number, she can remove all SAs associated with Bob's previous incarnation. This mechanism is somewhat overlapping with the "initial-contact" mechanism in IKEv2. Discussion in the WG suggested that birth certificates could replace initial-contact, but some people said that both were valuable. ---------------------------------------------------------------------- Or from http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-rationale-00 section 3.1: ---------------------------------------------------------------------- - adding in Bill Sommerfeld's "birth certificate" idea. In this idea Bob keeps a number in nonvolatile memory that increments each time the node restarts. When Bob restarts, he signs a "birth certificate" stating what the value of that counter is. This birth certificate is transmitted as a payload in message 4. Alice keeps this value. If Bob ever receives an ESP packet that doesn't decrypt properly or with an unknown SPI, he responds to that packet with his birth certificate. If the recipient has an SA for Bob with an older birth certificate, this lets them know Bob has restarted and forgotten state for that SA. We decided not to add that to this version of the draft, although we think it is a good idea, until it's been written up in a separate draft and there has been an opportunity for people to understand it and give feedback. ---------------------------------------------------------------------- I think this was the original email message explaining them on the ipsec-list http://www.vpnc.org/ietf-ipsec/00.ipsec/msg01415.html: ---------------------------------------------------------------------- Message-Id: <200008072309.e77N9oS111935@thunk.east.sun.com> In-reply-to: Your message of "Mon, 07 Aug 2000 15:55:21 PDT." <398F3E59.2DBC13D2@cisco.com> From: Bill Sommerfeld To: Scott Fanning cc: Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Date: Mon, 07 Aug 2000 19:09:50 -0400 Reply-to: sommerfeld@East.Sun.COM > Maybe we need a "death certificate" CA :-) Heh. Actually, one of the ideas I'm kicking around: If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA. This pushes the burden of reestablishing state to the end which already thinks it has shared state and has traffic it wants to send. The system which is receiving packets to unknown spi's merely has to respond with a simple message which involves no real-time cryptography (it should, of course, be rate limited). The system receiving the error message can discard it if it doesn't correspond to existing state or if it's "old news" (i.e., you get replay protection); if it's not old news, you can rate-limit how often you attempt to verify the signature. I *think* this is relatively resistant to replay and DoS... - Bill ---------------------------------------------------------------------- > From what I understand ,Bob generates a single certificate when he > reboots, and will add that as a birth certificate payload, to the > invalid_spi notification. If Bob only generates one certificate > independent of the client Alice, Mallet( the MitM) can snoop and learn > the birth certificate and replay this to any Alice connected to Bob. How > does Alice trust that the information is a fresh valid packet generated > by Bob and not a "constructed" packet from an attacker. The Bob also sent that same certificate with the counter (or timestamp) inside of it when it created the SA. The Alice will receive the birth certificate, and first check if the counter is same than before. If it is, then it knows this is old news, and it can simply ignore the notification. If it has larger incarnation number than the one used when creating the SA, then it can validate the signature of the certificate and if that is valid, then it knows that Bob has rebooted since they created the SA, thus Alice can safely remove all IKE and IPsec SAs between her and Bob. As only Bob can create valid signatures, and Bob only does that after reboot Alice can know for sure that Bob has rebooted. The incarnation number can be timestamp or simple running counter, the only property that is required is that it cannot go backwards, and it has bigger number than it had before every time the machine is booted. As certificates do require clock or similar already, that same clock can be used here too. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 05:48: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 6F6B23A6A03; Tue, 19 Aug 2008 05:48:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538603A6AEC for ; Tue, 19 Aug 2008 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 AOXn66IC3hlV for ; Tue, 19 Aug 2008 05:48:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4C43A6AD3 for ; Tue, 19 Aug 2008 05:48:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7JCkbk2006854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 15:46:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7JCkbdm007877; Tue, 19 Aug 2008 15:46:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18602.49325.159236.3543@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 15:46:37 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <4FD341C1-73DA-4315-A4D6-F428D0A5FE3C@checkpoint.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <1696498986EFEC4D9153717DA325CB72014C6295@vaebe104.NOE.Nokia.com> <18596.19057.198942.901238@fireball.kivinen.iki.fi> <1218743727.7492.167.camel@fdetienn-laptop> <18597.16630.682587.674433@fireball.kivinen.iki.fi> <48AA8515.7020505@cisco.com> <4FD341C1-73DA-4315-A4D6-F428D0A5FE3C@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 9 min X-Total-Time: 11 min Cc: ipsec@ietf.org, fd@cisco.com, Pasi.Eronen@nokia.com, Pratima Sethi Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > Nice idea, but I see trouble with key management, and also with > signature agility. We probably don't want to add algorithm > negotiation, so SHA1+RSA? SHA1+DSA? SHA-256+ECDSA? If you are using certificates already, then the best pick would be using the same key (RSA/DSA/ECDSA) as in your authentication key, as other end must be able to process that. Same thing with the hash algorithm, i.e. using the same hash algorithm as what was used for the main certificate in the authentication phase. If you are not using certificates, but raw RSA keys then again using same key and hash function you are using for the authentication would be work. If you are using shared secret then you most likely would need to either use the hash that is already used in the negotiation (but as we do not negotiate hash separate, only as part of integrity alrogithm or pseudo-random function), or we can simply say we SHOULD use SHA-1 hash or stronger. Note, that if the other end cannot verify the birth certificate because of the unsupported hash function, the responder will simply ignore the birth certificates and revert back to old method, i.e. cannot do fast crash recovery. Note, that there is no reason why Bob needs to have only one birth certificate, it can sign same data with multiple hash functions and select which one of them to send (or send them all during the error message). In general case I think we will end up so that implementations use one common algorithm for it (RSA + SHA1 in most cases, I would guess for now), and in they can be configured to use something else if needed (i.e. ECDSA + SHA-256 in certain environments). The selected algorithms are then mandated by the environment... -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 06:02: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 324663A69F4; Tue, 19 Aug 2008 06:02:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD9C28C11F for ; Tue, 19 Aug 2008 06:02:06 -0700 (PDT) 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 hifYYTA5-pRO for ; Tue, 19 Aug 2008 06:02:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A1C4328C133 for ; Tue, 19 Aug 2008 06:02:01 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7JD28B05566; Tue, 19 Aug 2008 15:02:08 +0200 (CEST) Received: from [144.254.5.151] (dhcp-peg3-cl31144-254-5-151.cisco.com [144.254.5.151]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7JD26A22009; Tue, 19 Aug 2008 15:02:06 +0200 (CEST) From: Frederic Detienne To: Yingzhe Wu In-Reply-To: <001d01c901c0$d69705a0$83c510e0$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001d01c901c0$d69705a0$83c510e0$@wu@zteusa.com> Organization: Cisco Date: Tue, 19 Aug 2008 15:02:19 +0200 Message-Id: <1219150939.10564.13.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com 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, 2008-08-18 at 23:00 -0700, Yingzhe Wu wrote: > Hi Frederic, > > > > YZ> Not quite sure I understand this. Are you comparing with native > > IPsec > > > implementation that binds SA to socket? Even so, when the tunnel > > interface > > > is first associated with SA, IPsec selector match needs to happen and > > this > > > is based on GRE key. > > > > That association could be based on the IKE_ID alone, not waiting for > > the > > traffic selector. In that case, the GRE selector in your proposal is > > not > > necessary. > > That is based on assumption that each GRE tunnel gets its own credential > management, IKE_SA etc, the same example once given by Tero. Yes I agree > this is one way to achieve it, but specific deployment may not go with that > option, due to many reasons. This is well understood and agreed with. Again, it is important to scope your document; in the absence of a comment, it makes the GRE key selector look "necessary and sufficient" for security, which is not always the case (sometimes yes, sometimes not). But hey :) looking at your subsequent comments below, I think we are in sync anyway so there is no reason to split hairs. thanks and regards, fred > > > > Oh sorry; I still think of traffic selectors as a form of identity like > > they were in IKEv1. Let me rephrase in terms of traffic selectors. > > > > What I meant is that for the security scheme to be complete, there must > > be a validation of the negotiated traffic selectors vs. the IKE_SA > > identity. Otherwise, this would allow any user allowed to create an > > IKE_SA on LMA to negotiate any GRE key and hence access either > > Enterprise-A or Enterprise-B which we intended to differentiate in the > > first place. > > > > So just comparing the addresses is not sufficient in the general case. > > There may be degenerate cases where sys admins rely on the ip addresses > > only (e.g. because they administer both ends of the tunnel) for > > authorization. > > > > By simply adding a validation statement (a "SHOULD authorize" + > > explanation/recommendation) will make your specification a lot broader, > > clearer and more secure, without changing the underlying proposal. > > > Yes agree, it can be in form of PAD entries. > > > > > > > YZ> GRE key negotiation is currently out of scope, and we intend to > > do just > > > the traffic selection. > > > > ok thanks. So can you explain why the TSr key contains 0 instead of the > > second half-key when sent by the initiator ? It is not a trick > > questions > > -- just for me to understand your rationale. > > > > If that makes no difference for you, I would rather have TSr contain > > the > > second half-key to make the intent of the protocol clear. > > > The draft was written before the scope was narrowed down to only the GRE key > as IPsec selector, and it hasn't been updated. This needs to be changed and > will have only specific value in TSr. > > Thanks, > Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 10:43: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 6FE4228C1D5; Tue, 19 Aug 2008 10:43:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F68328C1D3 for ; Tue, 19 Aug 2008 10:43:23 -0700 (PDT) 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 r-E+-WVk2iKu for ; Tue, 19 Aug 2008 10:43:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 9456B3A682A for ; Tue, 19 Aug 2008 10:43:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7JHgZV00508; Tue, 19 Aug 2008 19:42:35 +0200 (CEST) Received: from [10.61.254.5] (ams-stealth-fdetienn-5.cisco.com [10.61.254.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m7JHgYA19262; Tue, 19 Aug 2008 19:42:34 +0200 (CEST) From: Frederic Detienne To: Tero Kivinen In-Reply-To: <18602.47431.660136.328236@fireball.kivinen.iki.fi> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> Organization: Cisco Date: Tue, 19 Aug 2008 19:42:34 +0200 Message-Id: <1219167754.7018.8.camel@fdetienn-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Yingzhe Wu , ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fd@cisco.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, 2008-08-19 at 15:15 +0300, Tero Kivinen wrote: > Yingzhe Wu writes: > > That is based on assumption that each GRE tunnel gets its own credential > > management, IKE_SA etc, the same example once given by Tero. Yes I agree > > this is one way to achieve it, but specific deployment may not go with that > > option, due to many reasons. > > Can you list those reasons. Only thing I can think of is to avoid > overhead of separate IKE SA (and the negotiation of it), but as we are > talking with long term connections (i.e. mostly static configuration > as far as I understand), that is not very important. For example in > our default settings are so that there is assumed to be same amount of > IKE SAs and IPsec SAs (i.e. one IKE SA per IPsec SA). > > This is normally the case for VPNs access, especially for IKEv2, as > the traffic selectors can collect all data to one IPsec SA and each > client has separate authentication data anyways. > > Note, that those IKE SAs can share same authentication data if they > want, there is no requirement for the authentication do be different > for all IKE SAs. All other things being equal, can you explain how each IKE_SA, using the same identification data gets assigned to a distinct tunnel ? fred _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 19 16:28: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 817733A684B; Tue, 19 Aug 2008 16:28:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911563A684B for ; Tue, 19 Aug 2008 16:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 h3NmUxwUUgyb for ; Tue, 19 Aug 2008 16:28:23 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id ACFB43A6839 for ; Tue, 19 Aug 2008 16:28:19 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7JNShkD020721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2008 18:28:43 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> In-Reply-To: <18602.47431.660136.328236@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2008 16:28:26 -0700 Message-ID: <004301c90253$4871abc0$d9550340$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckB9ayI5bKlNaa9RPirg3J3YTwgFwATzMAQ Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, August 19, 2008 5:15 AM > To: Yingzhe Wu > Cc: fd@cisco.com; ipsec@ietf.org > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Yingzhe Wu writes: > > That is based on assumption that each GRE tunnel gets its own > credential > > management, IKE_SA etc, the same example once given by Tero. Yes I > agree > > this is one way to achieve it, but specific deployment may not go > with that > > option, due to many reasons. > > Can you list those reasons. Only thing I can think of is to avoid > overhead of separate IKE SA (and the negotiation of it), but as we are > talking with long term connections (i.e. mostly static configuration > as far as I understand), that is not very important. For example in > our default settings are so that there is assumed to be same amount of > IKE SAs and IPsec SAs (i.e. one IKE SA per IPsec SA). > Yes, overhead of individual IKE_SA is quite important one, in terms of memory and processing power. But also the administrative cost for adding/removing/maintaining individual security context and credential due to change of customer configuration, such as adding/removing VPN connections. Also, the connections may not be static or long term, they could be mobile as in remote access compulsory VPN case. Additionally, one customer may have several GRE tunnels, requiring each GRE tunnel having its own credential doesn't make much sense. > This is normally the case for VPNs access, especially for IKEv2, as > the traffic selectors can collect all data to one IPsec SA and each > client has separate authentication data anyways. > You are correct for client based VPN access, each client has separate credential anyway and single SA may suffice (but not necessarily true for MIPv6), but our cases are mainly targeted for network based VPNs. > Note, that those IKE SAs can share same authentication data if they > want, there is no requirement for the authentication do be different > for all IKE SAs. > -- If authentication data is the same for all IKE_SA, then I don't understand the benefits of employing multiple IKE_SA? BR/ Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 20 01:57: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 44DB33A67A3; Wed, 20 Aug 2008 01:57:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8783A69EF for ; Wed, 20 Aug 2008 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 uoNVH9vBPsk6 for ; Wed, 20 Aug 2008 01:57:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D1A3B3A67A3 for ; Wed, 20 Aug 2008 01:57:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7K8tauO015528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 11:55:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7K8tXE6004725; Wed, 20 Aug 2008 11:55:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18603.56325.231179.504243@fireball.kivinen.iki.fi> Date: Wed, 20 Aug 2008 11:55:33 +0300 From: Tero Kivinen To: fd@cisco.com In-Reply-To: <1219167754.7018.8.camel@fdetienn-laptop> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <1219167754.7018.8.camel@fdetienn-laptop> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 6 min Cc: Yingzhe Wu , ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Frederic Detienne writes: > All other things being equal, can you explain how each IKE_SA, using the > same identification data gets assigned to a distinct tunnel ? Just like you normally do, i.e. assign different interfaces to different SPDs/PADs so they get different identities. As far as I have understood the packets going to each GRE tunnel comes from different interfaces and this information is already now manually configured to the system. With IPsec you simply add interface selectors so that you can select the IKE SA to use based on the interface where the packet came in. As far as I have understood the GRE tunnels are originating and terminating the security gateway (or otherwise transport mode could not be used), thus the security gateway must have some way to distinguish them either based on interfaces where they came in, or based on the IP-address or some other selector. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 20 04:48: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 239473A6952; Wed, 20 Aug 2008 04:48:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F5B3A6952 for ; Wed, 20 Aug 2008 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 7KP8S9ZlAF7o for ; Wed, 20 Aug 2008 04:48:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD623A67D6 for ; Wed, 20 Aug 2008 04:48:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7KBfAZD026465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 14:41:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7KBf8fs008324; Wed, 20 Aug 2008 14:41:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18604.724.57192.305854@fireball.kivinen.iki.fi> Date: Wed, 20 Aug 2008 14:41:08 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <004301c90253$4871abc0$d9550340$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 21 min X-Total-Time: 139 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > Yes, overhead of individual IKE_SA is quite important one, in terms of > memory and processing power. I already commented about that. > But also the administrative cost for > adding/removing/maintaining individual security context and credential due > to change of customer configuration, such as adding/removing VPN > connections. The different IKE SAs do not need to have individual security contextes, unless you really want them to be cryptographically separated. When you are sharing the same IKE SA they are never really cryptographically separated, thus there no need to do the same thing with multiple IKE SAs. Adminstrative cost is only there if you want to have it there, i.e. if you take benefit of having multiple IKE SAs and make each of them having separate security context and credentials. So this is not reason not to use multiple IKE SAs, this is benefit you can use if you use multiple IKE SAs, but you do not need to take the cost unless you want to take it. > Also, the connections may not be static or long term, they could be mobile > as in remote access compulsory VPN case. But you somehow still need to know from the connection to which GRE key that is bound, and as far as I have understood that mapping must be configured to both security gateways anyways so both ends knows where to route packets forward after decapsulating GRE tunnel. So regardless whether the connections are static as far as I can see the configuration itself is quite static. Whether the connections are long term does not really matter as even with mobile or remote access cases the connections are most likely for hours not for seconds thus the IKE SA creation overhead is distributed over that time. Also in mobile or remote access case it might be even more important to really identify the remote access users instead of just mapping that to GRE key, using real identity like email address makes policy enforcement easier to understand than mapping it first to GRE key. > Additionally, one customer may have several GRE tunnels, requiring each GRE > tunnel having its own credential doesn't make much sense. They do not need to have separate credentials, only separate identity sharing same credentials. I would assume that inside one customer you can also use IP-addresses or similar to distinguish different tunnels, so there might not be need for separate GRE tunnels. > If authentication data is the same for all IKE_SA, then I don't understand > the benefits of employing multiple IKE_SA? Benefits are that it is already existing mechanims that does not require any changes to the protocol, and each IKE SA still can have separate ID which can be used to select the policy to be used. Also expanding from that setup to setup where each IKE SAs will have separate authentication data is trivial and does not require any protocol just changing the policy configuration. I am always very concerned when we are making extensions to the protocol where the same thing can be done with some already existing method. If the benefits from the extensions are big enough then we should do it, but we should always first consider do we really need this change or is it ok to just use the existing methods. In the GRE key case the only reason I have seen why not to use the existing multiple IKE SA method has been the overhead of having extra IKE SA. I am not sure if that overhead is so large that we need to expand IKEv2 protocol to allow GRE keys as selectors. On the other hand GRE keys as selectors have some quite fundamental properties to the IPsec architecture and those needs to be considered too (i.e. the actual protocol change to the IKEv2 is much smaller than the change to the IPsec architecture). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 20 07:04: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 03BA428C0E0; Wed, 20 Aug 2008 07:04:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDDD3A6BEC for ; Wed, 20 Aug 2008 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcwTPrewKIUg for ; Wed, 20 Aug 2008 07:04:10 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7836328C0E0 for ; Wed, 20 Aug 2008 07:04:08 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2508F294002; Wed, 20 Aug 2008 17:03:36 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 22F01294001; Wed, 20 Aug 2008 17:03:35 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7KE3YjI008094; Wed, 20 Aug 2008 17:03:34 +0300 (IDT) Message-ID: <48AC22D8.1050903@checkpoint.com> Date: Wed, 20 Aug 2008 16:57:44 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> In-Reply-To: <18604.724.57192.305854@fireball.kivinen.iki.fi> Cc: Yingzhe Wu , ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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="===============1149765121==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1149765121== Content-Type: multipart/alternative; boundary="------------020302000409000704040306" This is a multi-part message in MIME format. --------------020302000409000704040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tero, regardless of the technical merits of the specific proposal, I think we should oppose protocol extensions that complicate the development of new IPsec implementations, while adding little benefit. On the other hand, we should support extensions that enable IKE/IPsec to be used in new environments, where they can provide significant security benefits, and eliminate the need for custom solutions ("secure GRE", "secure BGP" etc.). There are many gray areas. But I think the GRE case is mostly of the latter type. Thanks, Yaron Tero Kivinen wrote: > Yingzhe Wu writes: > >> Yes, overhead of individual IKE_SA is quite important one, in terms of >> memory and processing power. >> > > I already commented about that. > > >> But also the administrative cost for >> adding/removing/maintaining individual security context and credential due >> to change of customer configuration, such as adding/removing VPN >> connections. >> > > The different IKE SAs do not need to have individual security > contextes, unless you really want them to be cryptographically > separated. When you are sharing the same IKE SA they are never really > cryptographically separated, thus there no need to do the same thing > with multiple IKE SAs. Adminstrative cost is only there if you want to > have it there, i.e. if you take benefit of having multiple IKE SAs and > make each of them having separate security context and credentials. > > So this is not reason not to use multiple IKE SAs, this is benefit you > can use if you use multiple IKE SAs, but you do not need to take the > cost unless you want to take it. > > >> Also, the connections may not be static or long term, they could be mobile >> as in remote access compulsory VPN case. >> > > But you somehow still need to know from the connection to which GRE > key that is bound, and as far as I have understood that mapping must > be configured to both security gateways anyways so both ends knows > where to route packets forward after decapsulating GRE tunnel. So > regardless whether the connections are static as far as I can see the > configuration itself is quite static. Whether the connections are long > term does not really matter as even with mobile or remote access cases > the connections are most likely for hours not for seconds thus the IKE > SA creation overhead is distributed over that time. > > Also in mobile or remote access case it might be even more important > to really identify the remote access users instead of just mapping > that to GRE key, using real identity like email address makes policy > enforcement easier to understand than mapping it first to GRE key. > > >> Additionally, one customer may have several GRE tunnels, requiring each GRE >> tunnel having its own credential doesn't make much sense. >> > > They do not need to have separate credentials, only separate identity > sharing same credentials. I would assume that inside one customer you > can also use IP-addresses or similar to distinguish different > tunnels, so there might not be need for separate GRE tunnels. > > >> If authentication data is the same for all IKE_SA, then I don't understand >> the benefits of employing multiple IKE_SA? >> > > Benefits are that it is already existing mechanims that does not > require any changes to the protocol, and each IKE SA still can have > separate ID which can be used to select the policy to be used. Also > expanding from that setup to setup where each IKE SAs will have > separate authentication data is trivial and does not require any > protocol just changing the policy configuration. > > I am always very concerned when we are making extensions to the > protocol where the same thing can be done with some already existing > method. If the benefits from the extensions are big enough then we > should do it, but we should always first consider do we really need > this change or is it ok to just use the existing methods. In the GRE > key case the only reason I have seen why not to use the existing > multiple IKE SA method has been the overhead of having extra IKE SA. I > am not sure if that overhead is so large that we need to expand IKEv2 > protocol to allow GRE keys as selectors. On the other hand GRE keys as > selectors have some quite fundamental properties to the IPsec > architecture and those needs to be considered too (i.e. the actual > protocol change to the IKEv2 is much smaller than the change to the > IPsec architecture). > --------------020302000409000704040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tero,

regardless of the technical merits of the specific proposal, I think we should oppose protocol extensions that complicate the development of new IPsec implementations, while adding little benefit.

On the other hand, we should support extensions that enable IKE/IPsec to be used in new environments, where they can provide significant security benefits, and eliminate the need for custom solutions ("secure GRE", "secure BGP" etc.).

There are many gray areas. But I think the GRE case is mostly of the latter type.

Thanks,
    Yaron

Tero Kivinen wrote: 
Yingzhe Wu writes:
  
Yes, overhead of individual IKE_SA is quite important one, in terms of
memory and processing power.
    

I already commented about that.

  
But also the administrative cost for
adding/removing/maintaining individual security context and credential due
to change of customer configuration, such as adding/removing VPN
connections.
    

The different IKE SAs do not need to have individual security
contextes, unless you really want them to be cryptographically
separated. When you are sharing the same IKE SA they are never really
cryptographically separated, thus there no need to do the same thing
with multiple IKE SAs. Adminstrative cost is only there if you want to
have it there, i.e. if you take benefit of having multiple IKE SAs and
make each of them having separate security context and credentials.

So this is not reason not to use multiple IKE SAs, this is benefit you
can use if you use multiple IKE SAs, but you do not need to take the
cost unless you want to take it.

  
Also, the connections may not be static or long term, they could be mobile
as in remote access compulsory VPN case.
    

But you somehow still need to know from the connection to which GRE
key that is bound, and as far as I have understood that mapping must
be configured to both security gateways anyways so both ends knows
where to route packets forward after decapsulating GRE tunnel. So
regardless whether the connections are static as far as I can see the
configuration itself is quite static. Whether the connections are long
term does not really matter as even with mobile or remote access cases
the connections are most likely for hours not for seconds thus the IKE
SA creation overhead is distributed over that time.

Also in mobile or remote access case it might be even more important
to really identify the remote access users instead of just mapping
that to GRE key, using real identity like email address makes policy
enforcement easier to understand than mapping it first to GRE key.

  
Additionally, one customer may have several GRE tunnels, requiring each GRE
tunnel having its own credential doesn't make much sense.
    

They do not need to have separate credentials, only separate identity
sharing same credentials. I would assume that inside one customer you
can also use IP-addresses or similar to distinguish different
tunnels, so there might not be need for separate GRE tunnels.

  
If authentication data is the same for all IKE_SA, then I don't understand
the benefits of employing multiple IKE_SA?
    

Benefits are that it is already existing mechanims that does not
require any changes to the protocol, and each IKE SA still can have
separate ID which can be used to select the policy to be used. Also
expanding from that setup to setup where each IKE SAs will have
separate authentication data is trivial and does not require any
protocol just changing the policy configuration.

I am always very concerned when we are making extensions to the
protocol where the same thing can be done with some already existing
method. If the benefits from the extensions are big enough then we
should do it, but we should always first consider do we really need
this change or is it ok to just use the existing methods. In the GRE
key case the only reason I have seen why not to use the existing
multiple IKE SA method has been the overhead of having extra IKE SA. I
am not sure if that overhead is so large that we need to expand IKEv2
protocol to allow GRE keys as selectors. On the other hand GRE keys as
selectors have some quite fundamental properties to the IPsec
architecture and those needs to be considered too (i.e. the actual
protocol change to the IKEv2 is much smaller than the change to the
IPsec architecture).
--------------020302000409000704040306-- --===============1149765121== 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 --===============1149765121==-- From ipsec-bounces@ietf.org Wed Aug 20 12:04: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 151DC3A68AF; Wed, 20 Aug 2008 12:04:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFB43A6894 for ; Wed, 20 Aug 2008 12:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR9b2ny3-p6j for ; Wed, 20 Aug 2008 12:04:39 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EBB853A682B for ; Wed, 20 Aug 2008 12:04:38 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2A160294002; Wed, 20 Aug 2008 22:03:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 957FE294001 for ; Wed, 20 Aug 2008 22:01:41 +0300 (IDT) Received: from [172.16.10.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7KJ1ejI017713 for ; Wed, 20 Aug 2008 22:01:41 +0300 (IDT) Message-ID: <48AC6A14.6000905@checkpoint.com> Date: Wed, 20 Aug 2008 22:01:40 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] ipsecme WG document on IKE redirect 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="===============0822307566==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0822307566== Content-Type: multipart/alternative; boundary="------------020105030608070306030701" This is a multi-part message in MIME format. --------------020105030608070306030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Vijay and Killian, two of the current authors of draft-devarapalli-ipsec-ikev2-redirect, have agreed to progress it as a WG document. Pasi will continue as a committed reviewer :-) Thanks Killian, Vijay and Pasi! Yaron --------------020105030608070306030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,


Vijay and Killian, two of the current authors of draft-devarapalli-ipsec-ikev2-redirect, have agreed to progress it as a WG document. Pasi will continue as a committed reviewer :-)


Thanks Killian, Vijay and Pasi!


    Yaron

--------------020105030608070306030701-- --===============0822307566== 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 --===============0822307566==-- From ipsec-bounces@ietf.org Thu Aug 21 02:03: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 52B263A6955; Thu, 21 Aug 2008 02:03:02 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853423A6955 for ; Thu, 21 Aug 2008 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_82=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 BaFwVAnqiicF for ; Thu, 21 Aug 2008 02:02:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 73D353A6820 for ; Thu, 21 Aug 2008 02:02:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7L90GBI002173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 12:00:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7L90EfD025970; Thu, 21 Aug 2008 12:00:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18605.11934.365458.291102@fireball.kivinen.iki.fi> Date: Thu, 21 Aug 2008 12:00:14 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <48AC22D8.1050903@checkpoint.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: Yingzhe Wu , ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yaron Sheffer writes: > There are many gray areas. But I think the GRE case is mostly of the > latter type. Could be that GRE case is in that type, but I am not yet convinced about that. Thats why I have been trying to understand why the multiple IKE SA solution is not acceptable for GRE case. If there is nothing more than resource usage for the IKE SA, then that is quite weak reason. Also the only reason I have seen why different GRE key values need to be in different IPsec SA tunnels at all, seemed to be that some customers might have different requirements for the IPsec algorithms. That is also quite weak reason. Hmm.. actually we do not need one IKE SA for each separate customer,we only need separate IKE SA for each different set of security algorithms, or we can use same method we do for QoS, i.e. we do not negotiate the different GRE keys, the sending site will simply select IPsec SA with acceptable IPsec algorithms based on his own local policy, i.e. there is no need to agree on the use of GRE key values at all. The draft also need to clearly explain the effects of having GRE key as selector, i.e. that now some traffic inside the GRE encapsulation can bypass normal security checks (drop rules) and also bypass the exit tunnel checks on the other end. The security considerations section needs to explain those. Currently those have not been discussed too much, and that is ok, as I think we need first to concenctrate on the need of the extension, before we go too deeply to the actual protocol and design work. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 22 16:23:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C583A6B20; Fri, 22 Aug 2008 16:23:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BE43A6B20 for ; Fri, 22 Aug 2008 16:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 w6KOgQkQS-XM for ; Fri, 22 Aug 2008 16:23:48 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 75FBF3A6AFC for ; Fri, 22 Aug 2008 16:23:48 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7MNO5dC011971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2008 18:24:06 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> In-Reply-To: <18604.724.57192.305854@fireball.kivinen.iki.fi> Date: Fri, 22 Aug 2008 16:23:49 -0700 Message-ID: <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckCuk1AXi++fiNxQb6YEzPJS61nKwBWT2oA Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > The different IKE SAs do not need to have individual security > contextes, unless you really want them to be cryptographically > separated. When you are sharing the same IKE SA they are never really > cryptographically separated, thus there no need to do the same thing > with multiple IKE SAs. Adminstrative cost is only there if you want to > have it there, i.e. if you take benefit of having multiple IKE SAs and > make each of them having separate security context and credentials. > > So this is not reason not to use multiple IKE SAs, this is benefit you > can use if you use multiple IKE SAs, but you do not need to take the > cost unless you want to take it. > OK, so you do not have to configure separate credential, but there is still administrative cost of separate identities, separate policies. Can I use any identity for these GRE tunnels? any type of credential associated with these identities? > But you somehow still need to know from the connection to which GRE > key that is bound, and as far as I have understood that mapping must > be configured to both security gateways anyways so both ends knows > where to route packets forward after decapsulating GRE tunnel. So > regardless whether the connections are static as far as I can see the > configuration itself is quite static. Whether the connections are long > term does not really matter as even with mobile or remote access cases > the connections are most likely for hours not for seconds thus the IKE > SA creation overhead is distributed over that time. > If you use separate credential for each IKE_SA, it becomes a problem in mobile situation. > Also in mobile or remote access case it might be even more important > to really identify the remote access users instead of just mapping > that to GRE key, using real identity like email address makes policy > enforcement easier to understand than mapping it first to GRE key. > That is client VPN case, which we don't have to argue about. > > Additionally, one customer may have several GRE tunnels, requiring > each GRE > > tunnel having its own credential doesn't make much sense. > > They do not need to have separate credentials, only separate identity > sharing same credentials. I would assume that inside one customer you > can also use IP-addresses or similar to distinguish different > tunnels, so there might not be need for separate GRE tunnels. > These solution are all similar in nature, whether they are multiple identities, multiple IP addresses, or multiple credentials. They are not really long term solution and they are not scalable. And also they are implementation specific and do not support BITS. The best way to do it, IMO, is to use the traffic selector. BR/ Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 22 16:29: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 4B6403A6AD6; Fri, 22 Aug 2008 16:29:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5533A6AD6 for ; Fri, 22 Aug 2008 16:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 573sbgz7J9Li for ; Fri, 22 Aug 2008 16:29:06 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 2EE3B3A6948 for ; Fri, 22 Aug 2008 16:29:06 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7MNTXdB012150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2008 18:29:33 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" , "'Yaron Sheffer'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> In-Reply-To: <18605.11934.365458.291102@fireball.kivinen.iki.fi> Date: Fri, 22 Aug 2008 16:29:16 -0700 Message-ID: <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckDbL7YBr8OzUmySfaK7RUeHPzF9ABPyQew Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, August 21, 2008 2:00 AM > To: Yaron Sheffer > Cc: Yingzhe Wu; ipsec@ietf.org; fd@cisco.com > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Yaron Sheffer writes: > > There are many gray areas. But I think the GRE case is mostly of the > > latter type. > > Could be that GRE case is in that type, but I am not yet convinced > about that. Thats why I have been trying to understand why the > multiple IKE SA solution is not acceptable for GRE case. If there is > nothing more than resource usage for the IKE SA, then that is quite > weak reason. There are issues of separate context (identities, policies, if not credentials) and implementation specific. Not all security gateways will implement that. > > Also the only reason I have seen why different GRE key values need to > be in different IPsec SA tunnels at all, seemed to be that some > customers might have different requirements for the IPsec algorithms. > That is also quite weak reason. > There are requirements from PPVPN, not just different IPsec algorithms, but IPsec separation on VPN or route level. > Hmm.. actually we do not need one IKE SA for each separate customer,we > only need separate IKE SA for each different set of security > algorithms, or we can use same method we do for QoS, i.e. we do not > negotiate the different GRE keys, the sending site will simply select > IPsec SA with acceptable IPsec algorithms based on his own local > policy, i.e. there is no need to agree on the use of GRE key values at > all. There is no such requirement. > > The draft also need to clearly explain the effects of having GRE key > as selector, i.e. that now some traffic inside the GRE encapsulation > can bypass normal security checks (drop rules) and also bypass the > exit tunnel checks on the other end. The security considerations > section needs to explain those. Currently those have not been > discussed too much, and that is ok, as I think we need first to > concenctrate on the need of the extension, before we go too deeply to > the actual protocol and design work. This I agree. BR/ Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 04:02:18 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 8275B3A689E; Mon, 25 Aug 2008 04:02:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DA43A689E for ; Mon, 25 Aug 2008 04:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+dqy3E9Pn4U for ; Mon, 25 Aug 2008 04:02:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 09D053A6851 for ; Mon, 25 Aug 2008 04:02:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7PB1uV4000134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 14:01:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7PB1s0k023426; Mon, 25 Aug 2008 14:01:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18610.37154.828874.211382@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2008 14:01:54 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > OK, so you do not have to configure separate credential, but there is still > administrative cost of separate identities, separate policies. Can I use any > identity for these GRE tunnels? any type of credential associated with these > identities? Yes. One good choise would be to use ID_KEY_ID, which is simply an opaque octet stream. That could be either the GRE key directly, or the customer id code or something else depending on the environment. > These solution are all similar in nature, whether they are multiple > identities, multiple IP addresses, or multiple credentials. They are not > really long term solution and they are not scalable. I do not see any real difference between scalability between GRE key as traffic selector and mapping GRE key/IP-numbers/interfaces to ID. How is the GRE key as traffic selector going to be any different from? You still need a policy somewhere in the system that maps the IP-numbers/interfaces to GRE keys. In my case that mapping would be done in the IPsec module, in your case that would be somewhere before. > And also they are implementation specific and do not support BITS. BITS implementation are not really meant for security gateways (and you are talking here about the security gateway routing packets from multiple interfaces through one or multiple ipsec pipe), but even for BITS implementation you can use IP-addresses and most likely also interface selectors to select the suitable pipe where to feed the data without GRE keys. > The best way to do it, IMO, is to use the traffic selector. The main reason for using traffic selectors seems to be so that you can push the policy decision out from the IPsec (i.e. someone before IPsec decides the policy to be used and writes that policy to GRE key of the packet). But if you are pushing the policy decision out from the IPsec then there does not need to be tunnel exit checks, thus there is no need to negotiate the traffic selectors at all. I.e. if the receiving end of the IPsec packet will not check whether the sending send used same policy, then you can simply just send packets through any tunnel and receiving end will receive them and assume sender site used correct policy. In that case you do not need to negotiate traffic selectors at all, you can simply leave it all as local matter on the sending site, just like we do with QoS in the RFC4301. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 04:27:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533A428C3DD; Mon, 25 Aug 2008 04:27:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E9C28C3DB for ; Mon, 25 Aug 2008 04:27:43 -0700 (PDT) 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, J_CHICKENPOX_82=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 RhFbGtmcRFt2 for ; Mon, 25 Aug 2008 04:27:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id ACD1B28C382 for ; Mon, 25 Aug 2008 04:27:40 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7PBRMLv021542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 14:27:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7PBRMY3026018; Mon, 25 Aug 2008 14:27:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18610.38682.150024.202623@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2008 14:27:22 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 23 min X-Total-Time: 24 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > There are issues of separate context (identities, policies, if not > credentials) and implementation specific. Not all security gateways will > implement that. Not all security gateways will ever implement GRE key traffic selectors. Actually my guess is that even if we go forward and specify GRE key selectors there is going to be only very few implementations who are ever going to implement them. For those implementations who consider that providing solution is important for them, they will implement whethever is needed. > > Also the only reason I have seen why different GRE key values need to > > be in different IPsec SA tunnels at all, seemed to be that some > > customers might have different requirements for the IPsec algorithms. > > That is also quite weak reason. > > > There are requirements from PPVPN, not just different IPsec algorithms, but > IPsec separation on VPN or route level. Ok, so some customers thing some other customers IP-packets might taint their IP-packets even when they are usign GRE keys to separate them, but if they use same credentials and but use different encryption key, that magic tainting does not happen? I can see some customers requiring using separate credentials when creating their tunnels, as that would offer real separation from traffic from others. If the IPsec SAs are using same IKE SA to create them, then using multiple IPsec SAs does not provide any real difference in separation. Note, that even when you are using one IPsec SA to send traffic, you still can have those GRE keys in the packet, and those can/will be used to route packets properly, and they do offer separation from one customers traffic to another. > > Hmm.. actually we do not need one IKE SA for each separate customer,we > > only need separate IKE SA for each different set of security > > algorithms, or we can use same method we do for QoS, i.e. we do not > > negotiate the different GRE keys, the sending site will simply select > > IPsec SA with acceptable IPsec algorithms based on his own local > > policy, i.e. there is no need to agree on the use of GRE key values at > > all. > There is no such requirement. What requirement? I am lost here. I didn't list any requirement there, I simply explained that we do not need any GRE keys as traffic selectors at all, as we can use similar method than for QoS. The QoS situation in IPsec is so that sender and receiver create multiple IPsec SAs between them and all of them have exactly same traffic selectors. Then the sending site will locally associate different QoS parameters to those IPsec SAs, but that selection is communicated to the other end at all. The sending site will then simply send traffic through those multiple IPsec SA tunnels following his own policy. As the responder cannot verify the policy anyways there is no need for responder even try, which means it simply assumes sender site did follow the policy. In the GRE key situation the thing is same. As the GRE key checking on the responder site does not really offer anything, there is no reason for responder to do that, thus it can simply trust that sender did follow acceptable policy (and if sender had already sent packet out using too weak encryption the damage is already done when the packet is received by the other end). So what they can do is that sender site will create multiple IPsec SAs, then it will decide that IPsec SA 1 is going to be used for traffic using GRE key 1231, so all traffic having GRE key 1231 is going to be routed to IPsec SA 1. For traffic using GRE key 343 and requiring different IPsec algorithms, the sender site will create another IPsec SA (with normal traffic selectors) and it will internally route GRE key 343 to tat IPsec SA 2. The responder end can then get the packets from the tunnels and look at the GRE key and route them forward. There is no need to negotiate that IPsec SA 1 is using GRE key 1231, it is enough both ends follow their own policies when they select IPsec SA what they are using. Their GRE based policy might be something like: This GRE key xxx must use 3DES, this GRE key yyy must go on separate IPsec SA, all other GRE keys can share IPsec SA and use AES. I think that is the best solution to this problem. The traffic selector negotiation is really only needed for the exit tunnel checks on the recipent end. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 12:41: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 049BD3A6944; Mon, 25 Aug 2008 12:41:29 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CE53A6944 for ; Mon, 25 Aug 2008 12:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 OpfYUh9arv19 for ; Mon, 25 Aug 2008 12:41:26 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 582633A68B3 for ; Mon, 25 Aug 2008 12:41:26 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7PJcKUq003053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2008 14:38:21 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> <18610.37154.828874.211382@fireball.kivinen.iki.fi> In-Reply-To: <18610.37154.828874.211382@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2008 12:38:03 -0700 Message-ID: <00ae01c906ea$17fd4d00$47f7e700$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGohVi175nEkrsRauzFj7nQ2/g8AAOnRHQ Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > I do not see any real difference between scalability between GRE key > as traffic selector and mapping GRE key/IP-numbers/interfaces to ID. > How is the GRE key as traffic selector going to be any different from? > You still need a policy somewhere in the system that maps the > IP-numbers/interfaces to GRE keys. In my case that mapping would be > done in the IPsec module, in your case that would be somewhere before. > Scalabilities in a sense when you adding/removing customer (or VPN, or connection, or context). You only need to do GRE key for traffic selector case, vs configuring additional IP address, configuring additional security context/policy/identities. It seems we are circling here, perhaps we should keep all text in earlier email exchange intact :) > > BITS implementation are not really meant for security gateways (and > you are talking here about the security gateway routing packets from > multiple interfaces through one or multiple ipsec pipe), but even for > BITS implementation you can use IP-addresses and most likely also > interface selectors to select the suitable pipe where to feed the data > without GRE keys. > Since we are talking about using GRE key as traffic selector, it is no longer limited to host implementation. So it applies to gateway, therefore both BITS and BITW are affected. And I don't think multiple IP address is not a good way moving forward supporting multiple customers/VPNS/connections. > The main reason for using traffic selectors seems to be so that you > can push the policy decision out from the IPsec (i.e. someone before > IPsec decides the policy to be used and writes that policy to GRE key > of the packet). But if you are pushing the policy decision out from > the IPsec then there does not need to be tunnel exit checks, thus > there is no need to negotiate the traffic selectors at all. I.e. if > the receiving end of the IPsec packet will not check whether the > sending send used same policy, then you can simply just send packets > through any tunnel and receiving end will receive them and assume > sender site used correct policy. > The selection of GRE tunnels is not tied to IPsec or any policy decision. Let's say there are already GRE tunnels, and IPsec is applied according to different situations (for example, intra-provider case vs inter-provider case). Tunnel exit check certainly helps here as a way of access control, to make sure the correct GRE tunnel (as identified by key) is coming from the correct peer with the correct security association applied, otherwise there exists a problem of GRE tunnel spoofing. Thanks, Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 12:53: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 54A243A69C1; Mon, 25 Aug 2008 12:53:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E403A69AD for ; Mon, 25 Aug 2008 12:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HOST_EQ_STATIC=1.172, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 VkMgvesYJAul for ; Mon, 25 Aug 2008 12:53:27 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 6B5023A69C1 for ; Mon, 25 Aug 2008 12:53:26 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7PJrAX8004087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2008 14:53:13 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> In-Reply-To: <18610.38682.150024.202623@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2008 12:52:51 -0700 Message-ID: <00b901c906ec$2ba10070$82e30150$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtA Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > Not all security gateways will ever implement GRE key traffic > selectors. Actually my guess is that even if we go forward and specify > GRE key selectors there is going to be only very few implementations > who are ever going to implement them. For those implementations who > consider that providing solution is important for them, they will > implement whethever is needed. > While I think there are many existing Ipsec implementation not even supporting "port" selector, and perhaps not even supporting "protocol" selector, the use of these products is totally up to customer. I am not in a position to say why vendors manufacture these products, but as long as there are customer asking for a feature, we are certainly motivated to implement it, especially it doesn't cost much, and I believe it serves a lot. Your comments are well received, but I'd like to hear what other people have to say and I think there are few people on this list think there are values in the GRE case. > Ok, so some customers thing some other customers IP-packets might > taint their IP-packets even when they are usign GRE keys to separate > them, but if they use same credentials and but use different > encryption key, that magic tainting does not happen? > > I can see some customers requiring using separate credentials when > creating their tunnels, as that would offer real separation from > traffic from others. If the IPsec SAs are using same IKE SA to create > them, then using multiple IPsec SAs does not provide any real > difference in separation. > Yes it does. Each IPsec keying material is derived by fresh nonces, so cracking one IPsec does not affect other IPsec. And if needed, DH exchange can be employed during IPsec creation such that even if IKE_SA is cracked later (which is much harder to do if not impossible), it does not affect IPsec, as there is PFS in it. It seems we are repeating here as well. > Note, that even when you are using one IPsec SA to send traffic, you > still can have those GRE keys in the packet, and those can/will be used > to route packets properly, and they do offer separation from one > customers traffic to another. > Well, this is not what customer is asking here... > > > Hmm.. actually we do not need one IKE SA for each separate > customer,we > > > only need separate IKE SA for each different set of security > > > algorithms, or we can use same method we do for QoS, i.e. we do not > > > negotiate the different GRE keys, the sending site will simply > select > > > IPsec SA with acceptable IPsec algorithms based on his own local > > > policy, i.e. there is no need to agree on the use of GRE key values > at > > > all. > > There is no such requirement. > > What requirement? I am lost here. I didn't list any requirement there, > I simply explained that we do not need any GRE keys as traffic > selectors at all, as we can use similar method than for QoS. > A requirement that providing IKE_SA based on different algorithms, and also the assumption that GRE key assignment is based on crypto algorithm (which I think is odd). Otherwise the solution you proposed below does work. > The QoS situation in IPsec is so that sender and receiver create > multiple IPsec SAs between them and all of them have exactly same > traffic selectors. Then the sending site will locally associate > different QoS parameters to those IPsec SAs, but that selection is > communicated to the other end at all. > > The sending site will then simply send traffic through those multiple > IPsec SA tunnels following his own policy. As the responder cannot > verify the policy anyways there is no need for responder even try, > which means it simply assumes sender site did follow the policy. > > In the GRE key situation the thing is same. As the GRE key checking on > the responder site does not really offer anything, there is no reason > for responder to do that, thus it can simply trust that sender did > follow acceptable policy (and if sender had already sent packet out > using too weak encryption the damage is already done when the packet > is received by the other end). > > So what they can do is that sender site will create multiple IPsec > SAs, then it will decide that IPsec SA 1 is going to be used for > traffic using GRE key 1231, so all traffic having GRE key 1231 is > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > requiring different IPsec algorithms, the sender site will create > another IPsec SA (with normal traffic selectors) and it will > internally route GRE key 343 to tat IPsec SA 2. The responder end can > then get the packets from the tunnels and look at the GRE key and > route them forward. There is no need to negotiate that IPsec SA 1 is > using GRE key 1231, it is enough both ends follow their own policies > when they select IPsec SA what they are using. > > Their GRE based policy might be something like: This GRE key xxx must > use 3DES, this GRE key yyy must go on separate IPsec SA, all other GRE > keys can share IPsec SA and use AES. > > I think that is the best solution to this problem. > > The traffic selector negotiation is really only needed for the exit > tunnel checks on the recipent end. > -- > kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 12:54: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 438F43A68B3; Mon, 25 Aug 2008 12:54:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2B23A6767 for ; Mon, 25 Aug 2008 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HOST_EQ_STATIC=1.172, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 TyN0xzDCPlK8 for ; Mon, 25 Aug 2008 12:54:21 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 884C73A69B6 for ; Mon, 25 Aug 2008 12:54:21 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7PJpSIf003982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2008 14:51:31 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> In-Reply-To: <18610.38682.150024.202623@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2008 12:51:11 -0700 Message-ID: <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtA Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > Not all security gateways will ever implement GRE key traffic > selectors. Actually my guess is that even if we go forward and specify > GRE key selectors there is going to be only very few implementations > who are ever going to implement them. For those implementations who > consider that providing solution is important for them, they will > implement whethever is needed. > While I think there are many existing Ipsec implementation not even supporting "port" selector, and perhaps not even supporting "protocol" selector, the use of these products is totally up to customer. I am not in a position to say why vendors manufacture these products, but as long as there are customer asking for a feature, we are certainly motivated to implement it, especially it doesn't cost much, and I believe it serves a lot. Your comments are well received, but I'd like to hear what other people have to say and I think there are few people on this list think there are values in the GRE case. > Ok, so some customers thing some other customers IP-packets might > taint their IP-packets even when they are usign GRE keys to separate > them, but if they use same credentials and but use different > encryption key, that magic tainting does not happen? > > I can see some customers requiring using separate credentials when > creating their tunnels, as that would offer real separation from > traffic from others. If the IPsec SAs are using same IKE SA to create > them, then using multiple IPsec SAs does not provide any real > difference in separation. > Yes it does. Each IPsec keying material is derived by fresh nonces, so cracking one IPsec does not affect other IPsec. And if needed, DH exchange can be employed during IPsec creation such that even if IKE_SA is cracked later (which is much harder to do if not impossible), it does not affect IPsec, as there is PFS in it. It seems we are repeating here as well. > Note, that even when you are using one IPsec SA to send traffic, you > still can have those GRE keys in the packet, and those can/will be used > to route packets properly, and they do offer separation from one > customers traffic to another. > Well, this is not what customer is asking here... > > > Hmm.. actually we do not need one IKE SA for each separate > customer,we > > > only need separate IKE SA for each different set of security > > > algorithms, or we can use same method we do for QoS, i.e. we do not > > > negotiate the different GRE keys, the sending site will simply > select > > > IPsec SA with acceptable IPsec algorithms based on his own local > > > policy, i.e. there is no need to agree on the use of GRE key values > at > > > all. > > There is no such requirement. > > What requirement? I am lost here. I didn't list any requirement there, > I simply explained that we do not need any GRE keys as traffic > selectors at all, as we can use similar method than for QoS. > A requirement that providing IKE_SA based on different algorithms, and also the assumption that GRE key assignment is based on crypto algorithm (which I think is odd). Otherwise the solution you proposed below does work. > The QoS situation in IPsec is so that sender and receiver create > multiple IPsec SAs between them and all of them have exactly same > traffic selectors. Then the sending site will locally associate > different QoS parameters to those IPsec SAs, but that selection is > communicated to the other end at all. > > The sending site will then simply send traffic through those multiple > IPsec SA tunnels following his own policy. As the responder cannot > verify the policy anyways there is no need for responder even try, > which means it simply assumes sender site did follow the policy. > > In the GRE key situation the thing is same. As the GRE key checking on > the responder site does not really offer anything, there is no reason > for responder to do that, thus it can simply trust that sender did > follow acceptable policy (and if sender had already sent packet out > using too weak encryption the damage is already done when the packet > is received by the other end). > > So what they can do is that sender site will create multiple IPsec > SAs, then it will decide that IPsec SA 1 is going to be used for > traffic using GRE key 1231, so all traffic having GRE key 1231 is > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > requiring different IPsec algorithms, the sender site will create > another IPsec SA (with normal traffic selectors) and it will > internally route GRE key 343 to tat IPsec SA 2. The responder end can > then get the packets from the tunnels and look at the GRE key and > route them forward. There is no need to negotiate that IPsec SA 1 is > using GRE key 1231, it is enough both ends follow their own policies > when they select IPsec SA what they are using. > > Their GRE based policy might be something like: This GRE key xxx must > use 3DES, this GRE key yyy must go on separate IPsec SA, all other GRE > keys can share IPsec SA and use AES. > > I think that is the best solution to this problem. > > The traffic selector negotiation is really only needed for the exit > tunnel checks on the recipent end. > -- > kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 14:43: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 61E3328C0CE; Mon, 25 Aug 2008 14:43:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC83928C0CE for ; Mon, 25 Aug 2008 14:43:33 -0700 (PDT) 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, J_CHICKENPOX_93=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 23WY9mIjJnqW for ; Mon, 25 Aug 2008 14:43:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AEBFE3A6944 for ; Mon, 25 Aug 2008 14:43:32 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7PLhULv080698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Aug 2008 14:43:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 25 Aug 2008 14:43:27 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Fwd: RFC 5282 on Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol 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: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >Subject: RFC 5282 on Using Authenticated Encryption Algorithms with the > Encrypted Payload of the Internet Key Exchange version 2 > (IKEv2) Protocol >From: rfc-editor@rfc-editor.org >Date: Thu, 21 Aug 2008 11:45:28 -0700 (PDT) >Cc: rfc-editor@rfc-editor.org >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.9 >List-Id: "IETF announcement list. No discussions." >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 5282 > > Title: Using Authenticated Encryption Algorithms with > the Encrypted Payload of the Internet > Key Exchange version 2 (IKEv2) Protocol > Author: D. Black, D. McGrew > Status: Standards Track > Date: August 2008 > Mailbox: black_david@emc.com, > mcgrew@cisco.com > Pages: 19 > Characters: 42137 > Updates: RFC4306 > > I-D Tag: draft-black-ipsec-ikev2-aead-modes-01.txt > > URL: http://www.rfc-editor.org/rfc/rfc5282.txt > >An authenticated encryption algorithm combines encryption and >integrity into a single operation; such algorithms may also be >referred to as combined modes of an encryption cipher or as combined >mode algorithms. This document describes the use of authenticated >encryption algorithms with the Encrypted Payload of the Internet Key >Exchange version 2 (IKEv2) protocol. > >The use of two specific authenticated encryption algorithms with the >IKEv2 Encrypted Payload is also described; these two algorithms are >the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES >GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional >documents may describe the use of other authenticated encryption >algorithms with the IKEv2 Encrypted Payload. [STANDARDS TRACK] > >This is now a Proposed Standard Protocol. > >STANDARDS TRACK: This document specifies an Internet standards track >protocol for the Internet community,and requests discussion and suggestions >for improvements. Please refer to the current edition of the Internet >Official Protocol Standards (STD 1) for the standardization state and >status of this protocol. Distribution of this memo is unlimited. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 25 15:33: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 A413A3A681C; Mon, 25 Aug 2008 15:33:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD623A681C for ; Mon, 25 Aug 2008 15:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=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 uw2igoxr+bXH for ; Mon, 25 Aug 2008 15:33:51 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 1A1C73A67C1 for ; Mon, 25 Aug 2008 15:33:51 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7PMXkg16255; Mon, 25 Aug 2008 22:33:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 17:33:30 -0500 Message-ID: <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> In-Reply-To: <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments thread-index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31A= References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> From: "Ricky Charlet" To: "Yingzhe Wu" Cc: ipsec@ietf.org, fd@cisco.com, Tero Kivinen Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Howdy, The end goal of your application is that you want traffic separation onto different SAs in an environment where IPsec is *not* doing the access control. You are specifying a mechanism for IPsec to take note of the GRE key field and apply differentiated policy based upon that field... But it was the GRE system which enforced the 'access control' and decided which packets belonged in which tunnels. My one critizism would by that you have not fully specified the requirements for an ineroperable implenetation here. The access control that really is running in your system, in the GRE side of the house, is hidden from this document. That should not be out of scope if you want to interoperate and make the same access-control guarentees across differnet vendors. One question I have is... Do you really see the need?... Multiple GRE tunnels to the *same* destination with some type of non-ipsec access control stearing packets into the different tunnels which receive different IPsec privacy treatment. It seems esoteric. -- Ricky Charlet rcharlet@nortel.com USA 408-754-1733 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Yingzhe Wu > Sent: Monday, August 25, 2008 12:51 PM > To: 'Tero Kivinen' > Cc: ipsec@ietf.org; fd@cisco.com > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Tero, > > > Not all security gateways will ever implement GRE key traffic > > selectors. Actually my guess is that even if we go forward > and specify > > GRE key selectors there is going to be only very few implementations > > who are ever going to implement them. For those implementations who > > consider that providing solution is important for them, they will > > implement whethever is needed. > > > While I think there are many existing Ipsec implementation not even > supporting "port" selector, and perhaps not even supporting "protocol" > selector, the use of these products is totally up to customer. > I am not in a position to say why vendors manufacture these > products, but as > long as there are customer asking for a feature, we are > certainly motivated > to implement it, especially it doesn't cost much, and I > believe it serves a > lot. Your comments are well received, but I'd like to hear > what other people > have to say and I think there are few people on this list > think there are > values in the GRE case. > > > Ok, so some customers thing some other customers IP-packets might > > taint their IP-packets even when they are usign GRE keys to separate > > them, but if they use same credentials and but use different > > encryption key, that magic tainting does not happen? > > > > I can see some customers requiring using separate credentials when > > creating their tunnels, as that would offer real separation from > > traffic from others. If the IPsec SAs are using same IKE SA > to create > > them, then using multiple IPsec SAs does not provide any real > > difference in separation. > > > Yes it does. Each IPsec keying material is derived by fresh nonces, so > cracking one IPsec does not affect other IPsec. And if > needed, DH exchange > can be employed during IPsec creation such that even if > IKE_SA is cracked > later (which is much harder to do if not impossible), it does > not affect > IPsec, as there is PFS in it. It seems we are repeating here as well. > > > Note, that even when you are using one IPsec SA to send traffic, you > > still can have those GRE keys in the packet, and those > can/will be used > > to route packets properly, and they do offer separation from one > > customers traffic to another. > > > Well, this is not what customer is asking here... > > > > > Hmm.. actually we do not need one IKE SA for each separate > > customer,we > > > > only need separate IKE SA for each different set of security > > > > algorithms, or we can use same method we do for QoS, > i.e. we do not > > > > negotiate the different GRE keys, the sending site will simply > > select > > > > IPsec SA with acceptable IPsec algorithms based on his own local > > > > policy, i.e. there is no need to agree on the use of > GRE key values > > at > > > > all. > > > There is no such requirement. > > > > What requirement? I am lost here. I didn't list any > requirement there, > > I simply explained that we do not need any GRE keys as traffic > > selectors at all, as we can use similar method than for QoS. > > > A requirement that providing IKE_SA based on different > algorithms, and also > the assumption that GRE key assignment is based on crypto > algorithm (which I > think is odd). Otherwise the solution you proposed below does work. > > > The QoS situation in IPsec is so that sender and receiver create > > multiple IPsec SAs between them and all of them have exactly same > > traffic selectors. Then the sending site will locally associate > > different QoS parameters to those IPsec SAs, but that selection is > > communicated to the other end at all. > > > > The sending site will then simply send traffic through > those multiple > > IPsec SA tunnels following his own policy. As the responder cannot > > verify the policy anyways there is no need for responder even try, > > which means it simply assumes sender site did follow the policy. > > > > In the GRE key situation the thing is same. As the GRE key > checking on > > the responder site does not really offer anything, there is > no reason > > for responder to do that, thus it can simply trust that sender did > > follow acceptable policy (and if sender had already sent packet out > > using too weak encryption the damage is already done when the packet > > is received by the other end). > > > > So what they can do is that sender site will create multiple IPsec > > SAs, then it will decide that IPsec SA 1 is going to be used for > > traffic using GRE key 1231, so all traffic having GRE key 1231 is > > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > > requiring different IPsec algorithms, the sender site will create > > another IPsec SA (with normal traffic selectors) and it will > > internally route GRE key 343 to tat IPsec SA 2. The > responder end can > > then get the packets from the tunnels and look at the GRE key and > > route them forward. There is no need to negotiate that IPsec SA 1 is > > using GRE key 1231, it is enough both ends follow their own policies > > when they select IPsec SA what they are using. > > > > Their GRE based policy might be something like: This GRE > key xxx must > > use 3DES, this GRE key yyy must go on separate IPsec SA, > all other GRE > > keys can share IPsec SA and use AES. > > > > I think that is the best solution to this problem. > > > > The traffic selector negotiation is really only needed for the exit > > tunnel checks on the recipent end. > > -- > > kivinen@safenet-inc.com > > _______________________________________________ > 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 Aug 25 20:41: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 A03DB3A6858; Mon, 25 Aug 2008 20:41:55 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A7C3A67B5 for ; Mon, 25 Aug 2008 20:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 eNPcFPUEpuRj for ; Mon, 25 Aug 2008 20:41:52 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 823143A6816 for ; Mon, 25 Aug 2008 20:41:52 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7Q3gDHE022960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2008 22:42:14 -0500 From: "Yingzhe Wu" To: "'Ricky Charlet'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> In-Reply-To: <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> Date: Mon, 25 Aug 2008 20:41:46 -0700 Message-ID: <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31AADNk7wA== Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Ricky, You got it reversed :) I want to have IPsec does the access control for GRE, in terms of protocol and port. GRE does its own thing: context separation and encapsulation of traffic for carrying it over IP, has nothing to do with access control. I am not sure I understand your question. There are requirements and the solution should be the scope proposed by Pasi: o A standards-track extension to IKEv2 to support using the "Key" field of Generic Routing Encapsulation (GRE) packets, specified in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP port number or ICMP type/code fields). This allows different GRE traffic flows to be mapped to different IPsec SAs. Any further extensions related to the use of IPsec with GRE are beyond the scope of this work item. This is now different from the original draft in the subject field, so may be this is the confusion. BR/ Yingzhe > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@nortel.com] > Sent: Monday, August 25, 2008 3:34 PM > To: Yingzhe Wu > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Howdy, > > The end goal of your application is that you want traffic > separation onto different SAs in an environment where IPsec is *not* > doing the access control. You are specifying a mechanism for IPsec to > take note of the GRE key field and apply differentiated policy based > upon that field... But it was the GRE system which enforced the 'access > control' and decided which packets belonged in which tunnels. > > My one critizism would by that you have not fully specified the > requirements for an ineroperable implenetation here. The access control > that really is running in your system, in the GRE side of the house, is > hidden from this document. That should not be out of scope if you want > to interoperate and make the same access-control guarentees across > differnet vendors. > > One question I have is... Do you really see the need?... > Multiple GRE tunnels to the *same* destination with some type of > non-ipsec access control stearing packets into the different tunnels > which receive different IPsec privacy treatment. It seems esoteric. > > -- > Ricky Charlet > rcharlet@nortel.com > USA 408-754-1733 > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Yingzhe Wu > > Sent: Monday, August 25, 2008 12:51 PM > > To: 'Tero Kivinen' > > Cc: ipsec@ietf.org; fd@cisco.com > > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > Hi Tero, > > > > > Not all security gateways will ever implement GRE key traffic > > > selectors. Actually my guess is that even if we go forward > > and specify > > > GRE key selectors there is going to be only very few > implementations > > > who are ever going to implement them. For those implementations who > > > consider that providing solution is important for them, they will > > > implement whethever is needed. > > > > > While I think there are many existing Ipsec implementation not even > > supporting "port" selector, and perhaps not even supporting > "protocol" > > selector, the use of these products is totally up to customer. > > I am not in a position to say why vendors manufacture these > > products, but as > > long as there are customer asking for a feature, we are > > certainly motivated > > to implement it, especially it doesn't cost much, and I > > believe it serves a > > lot. Your comments are well received, but I'd like to hear > > what other people > > have to say and I think there are few people on this list > > think there are > > values in the GRE case. > > > > > Ok, so some customers thing some other customers IP-packets might > > > taint their IP-packets even when they are usign GRE keys to > separate > > > them, but if they use same credentials and but use different > > > encryption key, that magic tainting does not happen? > > > > > > I can see some customers requiring using separate credentials when > > > creating their tunnels, as that would offer real separation from > > > traffic from others. If the IPsec SAs are using same IKE SA > > to create > > > them, then using multiple IPsec SAs does not provide any real > > > difference in separation. > > > > > Yes it does. Each IPsec keying material is derived by fresh nonces, > so > > cracking one IPsec does not affect other IPsec. And if > > needed, DH exchange > > can be employed during IPsec creation such that even if > > IKE_SA is cracked > > later (which is much harder to do if not impossible), it does > > not affect > > IPsec, as there is PFS in it. It seems we are repeating here as well. > > > > > Note, that even when you are using one IPsec SA to send traffic, > you > > > still can have those GRE keys in the packet, and those > > can/will be used > > > to route packets properly, and they do offer separation from one > > > customers traffic to another. > > > > > Well, this is not what customer is asking here... > > > > > > > Hmm.. actually we do not need one IKE SA for each separate > > > customer,we > > > > > only need separate IKE SA for each different set of security > > > > > algorithms, or we can use same method we do for QoS, > > i.e. we do not > > > > > negotiate the different GRE keys, the sending site will simply > > > select > > > > > IPsec SA with acceptable IPsec algorithms based on his own > local > > > > > policy, i.e. there is no need to agree on the use of > > GRE key values > > > at > > > > > all. > > > > There is no such requirement. > > > > > > What requirement? I am lost here. I didn't list any > > requirement there, > > > I simply explained that we do not need any GRE keys as traffic > > > selectors at all, as we can use similar method than for QoS. > > > > > A requirement that providing IKE_SA based on different > > algorithms, and also > > the assumption that GRE key assignment is based on crypto > > algorithm (which I > > think is odd). Otherwise the solution you proposed below does work. > > > > > The QoS situation in IPsec is so that sender and receiver create > > > multiple IPsec SAs between them and all of them have exactly same > > > traffic selectors. Then the sending site will locally associate > > > different QoS parameters to those IPsec SAs, but that selection is > > > communicated to the other end at all. > > > > > > The sending site will then simply send traffic through > > those multiple > > > IPsec SA tunnels following his own policy. As the responder cannot > > > verify the policy anyways there is no need for responder even try, > > > which means it simply assumes sender site did follow the policy. > > > > > > In the GRE key situation the thing is same. As the GRE key > > checking on > > > the responder site does not really offer anything, there is > > no reason > > > for responder to do that, thus it can simply trust that sender did > > > follow acceptable policy (and if sender had already sent packet out > > > using too weak encryption the damage is already done when the > packet > > > is received by the other end). > > > > > > So what they can do is that sender site will create multiple IPsec > > > SAs, then it will decide that IPsec SA 1 is going to be used for > > > traffic using GRE key 1231, so all traffic having GRE key 1231 is > > > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > > > requiring different IPsec algorithms, the sender site will create > > > another IPsec SA (with normal traffic selectors) and it will > > > internally route GRE key 343 to tat IPsec SA 2. The > > responder end can > > > then get the packets from the tunnels and look at the GRE key and > > > route them forward. There is no need to negotiate that IPsec SA 1 > is > > > using GRE key 1231, it is enough both ends follow their own > policies > > > when they select IPsec SA what they are using. > > > > > > Their GRE based policy might be something like: This GRE > > key xxx must > > > use 3DES, this GRE key yyy must go on separate IPsec SA, > > all other GRE > > > keys can share IPsec SA and use AES. > > > > > > I think that is the best solution to this problem. > > > > > > The traffic selector negotiation is really only needed for the exit > > > tunnel checks on the recipent end. > > > -- > > > kivinen@safenet-inc.com > > > > _______________________________________________ > > 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 Aug 26 02:09:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7342A3A6A5F; Tue, 26 Aug 2008 02:09:58 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455A53A6A6F for ; Tue, 26 Aug 2008 02:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.195 X-Spam-Level: *** X-Spam-Status: No, score=3.195 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_203=0.994, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8] 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 puda450p9QIj for ; Tue, 26 Aug 2008 02:09:56 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id 31D343A6A5F for ; Tue, 26 Aug 2008 02:09:55 -0700 (PDT) Received: from [172.16.8.70] (naveen_bn.globaledgesoft.com [172.16.8.70]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id E61E617B423 for ; Tue, 26 Aug 2008 14:40:32 +0530 (IST) Message-ID: <48B3C7F2.6080903@globaledgesoft.com> Date: Tue, 26 Aug 2008 14:38:02 +0530 From: "naveen.bn" User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: ipsec_mail Subject: [IPsec] help X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I am new to ipsec. I am facing problems in using ipsec. The SPD looks spdadd 172.16.8.70[2427] 172.16.8.34[5555] any -P out ipsec esp/transport//require ah/transport//require; and the SADB looks 172.16.8.70 172.16.8.34 esp mode=transport spi=65828(0x00010124) reqid=0(0x00000000) E: 3des-cbc f9209046 d0abdb5b 450ddc4f 361caa26 3f17c660 10109467 A: hmac-md5 bfd1abb8 545a1cab 4f923a03 121e4b39 seq=0x00000000 replay=32 flags=0x00000000 state=mature created: Aug 26 14:34:04 2008 current: Aug 26 14:34:23 2008 diff: 19(s) hard: 360(s) soft: 300(s) last: hard: 360(s) soft: 300(s) current: 0(bytes) hard: 100000(bytes) soft: 100000(bytes) allocated: 0 hard: 64 soft: 64 sadb_seq=2 pid=8134 refcnt=0 172.16.8.70 172.16.8.34 esp mode=transport spi=3573(0x00000df5) reqid=0(0x00000000) E: 3des-cbc 8741d9d3 6b6277d5 463df9df 7e3d728b 2a4dd7d1 a07757b0 A: hmac-md5 c1602e90 c0b08e28 07644cce bf96f56c seq=0x00000000 replay=32 flags=0x00000000 state=mature created: Aug 26 14:34:04 2008 current: Aug 26 14:34:23 2008 diff: 19(s) hard: 420(s) soft: 360(s) last: hard: 420(s) soft: 360(s) current: 0(bytes) hard: 100000(bytes) soft: 100000(bytes) allocated: 0 hard: 64 soft: 64 sadb_seq=0 pid=8134 refcnt=0 but i did not see any packet that is going out using ipsec. Kindly guide me to solve this problem. with regards naveen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 02:27: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 62D623A6A92; Tue, 26 Aug 2008 02:27:19 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60E03A6A74 for ; Tue, 26 Aug 2008 02:27:17 -0700 (PDT) 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 TNgO4IEQXFGD for ; Tue, 26 Aug 2008 02:27:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id DF51D3A6A5F for ; Tue, 26 Aug 2008 02:27:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7Q9QuN6002803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:26:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7Q9Qu2L020756; Tue, 26 Aug 2008 12:26:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18611.52320.33486.701810@fireball.kivinen.iki.fi> Date: Tue, 26 Aug 2008 12:26:56 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <00ae01c906ea$17fd4d00$47f7e700$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> <18610.37154.828874.211382@fireball.kivinen.iki.fi> <00ae01c906ea$17fd4d00$47f7e700$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 33 min X-Total-Time: 36 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > > I do not see any real difference between scalability between GRE key > > as traffic selector and mapping GRE key/IP-numbers/interfaces to ID. > > How is the GRE key as traffic selector going to be any different from? > > You still need a policy somewhere in the system that maps the > > IP-numbers/interfaces to GRE keys. In my case that mapping would be > > done in the IPsec module, in your case that would be somewhere before. > > > Scalabilities in a sense when you adding/removing customer (or VPN, or > connection, or context). You only need to do GRE key for traffic selector > case, vs configuring additional IP address, configuring additional security > context/policy/identities. I do not see any difference there. You still need to configure the new GRE key for that new customer to the IPsec policy so it is allowed to be used as traffic selector, and that change needs to be done in both ends. There is no difference between using GRE key as traffic selector vs using interface or IP-number as traffic selector. > > BITS implementation are not really meant for security gateways (and > > you are talking here about the security gateway routing packets from > > multiple interfaces through one or multiple ipsec pipe), but even for > > BITS implementation you can use IP-addresses and most likely also > > interface selectors to select the suitable pipe where to feed the data > > without GRE keys. > > > Since we are talking about using GRE key as traffic selector, it is no > longer limited to host implementation. So it applies to gateway, therefore > both BITS and BITW are affected. And I don't think multiple IP address is > not a good way moving forward supporting multiple > customers/VPNS/connections. You seem to have misunderstood my text completely. I didn't suggest using multiple IP adresses as a solution here, I just mentioned that even in BITS implementation there are selectors which can be used to select the correct tunnel. I.e. either packets are coming from multiple different interfaces thus interface selectors can be used to distinguish to which IPsec tunnel packet needs to be forwarded or if they come in using only one interface then they must have some kind of IP-addresses which are not overlapping thus they also can be used as selectors. > > The main reason for using traffic selectors seems to be so that you > > can push the policy decision out from the IPsec (i.e. someone before > > IPsec decides the policy to be used and writes that policy to GRE key > > of the packet). But if you are pushing the policy decision out from > > the IPsec then there does not need to be tunnel exit checks, thus > > there is no need to negotiate the traffic selectors at all. I.e. if > > the receiving end of the IPsec packet will not check whether the > > sending send used same policy, then you can simply just send packets > > through any tunnel and receiving end will receive them and assume > > sender site used correct policy. > > > The selection of GRE tunnels is not tied to IPsec or any policy decision. Good. So you agree there is no need to do GRE key traffic selectors, as they are not tied to the IPsec policy? Only reason to negotiate traffic selectors is to make sure that responder can also do policy checks for the traffic, and if responder SGW does not need to verify that all packets follow the negotiated policy there is no need to do traffic selector negotiation. > Let's say there are already GRE tunnels, and IPsec is applied according to > different situations (for example, intra-provider case vs inter-provider > case). Tunnel exit check certainly helps here as a way of access control, to > make sure the correct GRE tunnel (as identified by key) is coming from the > correct peer with the correct security association applied, otherwise there > exists a problem of GRE tunnel spoofing. So now you are again saying that the GRE tunnels and IPsec policies are tied together? Which one it is? Note, that checking that one authenticated peer only uses GRE keys he is authenticated to use, can be done without traffic selectors (i.e. for example by just using normal firewall rules). The checking whether the one peer followed the algorithm requirements and data separation can also be done without GRE key traffic selectors, but that gets so much complicated that if it is really required then GRE key traffic selectors are needed. Again the GRE tunnel spoofing can only be done if the attacker gets access to the authenticated SGW on the system, thus in that case he can already do whathever he wants for traffic going through that node. Only thing you might want to protect is that he cannot then attack traffic not going through that node, and that can be done by firewall rules (most likely the GRE module already has that kind of checks, where it makes sure that only certain GRE endpoints can use certain GRE keys). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 02:38: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 57AD73A6991; Tue, 26 Aug 2008 02:38:09 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9185C3A6804 for ; Tue, 26 Aug 2008 02:38:07 -0700 (PDT) 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 QdqNST+4Ncac for ; Tue, 26 Aug 2008 02:38:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 86AF63A69BB for ; Tue, 26 Aug 2008 02:38:05 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7Q9c3Tt015420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:38:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7Q9c3kn020104; Tue, 26 Aug 2008 12:38:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18611.52987.871362.126574@fireball.kivinen.iki.fi> Date: Tue, 26 Aug 2008 12:38:03 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <00b901c906ec$2ba10070$82e30150$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b901c906ec$2ba10070$82e30150$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > Yes it does. Each IPsec keying material is derived by fresh nonces, so > cracking one IPsec does not affect other IPsec. And if needed, DH exchange > can be employed during IPsec creation such that even if IKE_SA is cracked > later (which is much harder to do if not impossible), it does not affect > IPsec, as there is PFS in it. It seems we are repeating here as well. Easy solution to here is: Do not use weak encryption. All the encryption algorihtms used should be balanced and strong, thus cracking IPsec keying material for IPsec SA should not be possible, and if they can crack it on real time for one SA, they can do it for multiple SAs simultaneously by just scaling their hardware linearly (i.e. to crack 2 SAs just get two machines to do it). > > > There is no such requirement. > > What requirement? ... > A requirement that providing IKE_SA based on different algorithms, and also > the assumption that GRE key assignment is based on crypto algorithm (which I > think is odd). One more time to just verify I understood correctly: So there is no requirement to have differet GRE key tunnels to have different crypto algorithms (either in IKE SA or in IPsec SA)? I think someone listed that as a requirement, but might have misunderstood that then. So your requirement for multiple IPsec SAs is only that you want to have fresh crypt keys for each or some GRE key tunnels, so they cannot be attacked simultaneously? > Otherwise the solution you proposed below does work. I think my solution works also for that case where you just want to have separate keying material. If so, can you explain why it does not work here? > > The QoS situation in IPsec is so that sender and receiver create > > multiple IPsec SAs between them and all of them have exactly same > > traffic selectors. Then the sending site will locally associate > > different QoS parameters to those IPsec SAs, but that selection is > > communicated to the other end at all. > > > > The sending site will then simply send traffic through those multiple > > IPsec SA tunnels following his own policy. As the responder cannot > > verify the policy anyways there is no need for responder even try, > > which means it simply assumes sender site did follow the policy. > > > > In the GRE key situation the thing is same. As the GRE key checking on > > the responder site does not really offer anything, there is no reason > > for responder to do that, thus it can simply trust that sender did > > follow acceptable policy (and if sender had already sent packet out > > using too weak encryption the damage is already done when the packet > > is received by the other end). > > > > So what they can do is that sender site will create multiple IPsec > > SAs, then it will decide that IPsec SA 1 is going to be used for > > traffic using GRE key 1231, so all traffic having GRE key 1231 is > > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > > requiring different IPsec algorithms, the sender site will create > > another IPsec SA (with normal traffic selectors) and it will > > internally route GRE key 343 to tat IPsec SA 2. The responder end can > > then get the packets from the tunnels and look at the GRE key and > > route them forward. There is no need to negotiate that IPsec SA 1 is > > using GRE key 1231, it is enough both ends follow their own policies > > when they select IPsec SA what they are using. > > > > Their GRE based policy might be something like: This GRE key xxx must > > use 3DES, this GRE key yyy must go on separate IPsec SA, all other GRE > > keys can share IPsec SA and use AES. > > > > I think that is the best solution to this problem. > > > > The traffic selector negotiation is really only needed for the exit > > tunnel checks on the recipent end. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 02:45:34 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 3B40B3A6ABA; Tue, 26 Aug 2008 02:45:34 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4D33A6A74 for ; Tue, 26 Aug 2008 02:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vlwAnoG5i0Go for ; Tue, 26 Aug 2008 02:45:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id A4B6A3A6AAF for ; Tue, 26 Aug 2008 02:45:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7Q9jH7w000829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:45:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7Q9jGTV023370; Tue, 26 Aug 2008 12:45:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18611.53420.252788.221577@fireball.kivinen.iki.fi> Date: Tue, 26 Aug 2008 12:45:16 +0300 From: Tero Kivinen To: "Ricky Charlet" In-Reply-To: <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 2 min X-Total-Time: 3 min Cc: Yingzhe Wu , ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Ricky Charlet writes: > The end goal of your application is that you want traffic > separation onto different SAs in an environment where IPsec is *not* > doing the access control. But traffic selector negotiation is ONLY needed when you are doing access control in IPsec at the responder side. I.e. only reason to do traffic selectors is to negotiate what kind of exit tunnel checks the responder needs to do. If IPsec is not doing access control, there is no point of doing traffic selector negotiations for GRE keys. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 06:15: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 28D9A28C390; Tue, 26 Aug 2008 06:15:19 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC7028C3CF for ; Tue, 26 Aug 2008 06:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 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 b9-GZDCPDMgy for ; Tue, 26 Aug 2008 06:15:16 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id 7A4B528C390 for ; Tue, 26 Aug 2008 06:15:16 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so373310gvc.15 for ; Tue, 26 Aug 2008 06:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=xU5fagCLPuUBXIpVw1m0NF4LO0Vi5sOp15pErioON7A=; b=cnDdTrZEhOuYGcB02aTkbxdoN5MELQ2sXfQhYAiYg8sarS5YzAFGJ+YKl/vwKD7IcL vjGyQCcj/hXQKTbwXw2lrpvod6dAgFq6YMvc9EzeeAhTy74wmWC9LHcVkN1VXzRxW+b1 RNfn27HvRES7ouGu/fX/Cs6nrdt8kQNz9xF3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=LtjrFtuStNZIwDQjP3naj2KdIXnRtqYeMVWExAqYsxaVVi4P+ExH/JH4WmO7oZAu74 NukwyVZeB05veq/nfg+ueCsRiyNJkySzCTmhpf02At55bRb7jJjLsS2gOxZLbXn5Qp1I tgK0WBp2QBiMMxN67pv0aOBkWt9ryccRlUi4o= Received: by 10.102.228.10 with SMTP id a10mr3737086muh.109.1219756500859; Tue, 26 Aug 2008 06:15:00 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u9sm33005757muf.9.2008.08.26.06.14.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Aug 2008 06:14:59 -0700 (PDT) To: ipsec@ietf.org Date: Tue, 26 Aug 2008 15:14:59 +0200 User-Agent: KMail/1.9.9 References: <1218726814.7492.91.camel@fdetienn-laptop> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> In-Reply-To: <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808261515.00239.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Yingzhe Wu , fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Monday 25 August 2008, Yingzhe Wu wrote: > Hi Tero, > > > Not all security gateways will ever implement GRE key traffic > > selectors. Actually my guess is that even if we go forward and > > specify GRE key selectors there is going to be only very few > > implementations who are ever going to implement them. For those > > implementations who consider that providing solution is important > > for them, they will implement whethever is needed. > > While I think there are many existing Ipsec implementation not even > supporting "port" selector, and perhaps not even supporting > "protocol" selector, the use of these products is totally up to > customer. I am not in a position to say why vendors manufacture these > products, but as long as there are customer asking for a feature, we > are certainly motivated to implement it, especially it doesn't cost > much, and I believe it serves a lot. Your comments are well received, > but I'd like to hear what other people have to say and I think there > are few people on this list think there are values in the GRE case. FWIW, I agree with all the points Tero made so far on this thread, and I'd like to point out that in the early SECDIR review of this draft he and I did, similar points were made. I'm still not convinced that GRE key traffic selectors are needed, and I think we haven't seen yet clear requirements that would motivate extending the IPsec architecture to handle those. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 10:40: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 1DB5D3A6AD8; Tue, 26 Aug 2008 10:40:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E2F3A6AD8 for ; Tue, 26 Aug 2008 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_82=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 j5NqgwFu5KjD for ; Tue, 26 Aug 2008 10:40:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 557B83A6892 for ; Tue, 26 Aug 2008 10:40:22 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7QHeJD02246; Tue, 26 Aug 2008 17:40:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 12:40:16 -0500 Message-ID: <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> In-Reply-To: <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments thread-index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31AADNk7wAAdEDug References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> From: "Ricky Charlet" To: "Yingzhe Wu" Cc: ipsec@ietf.org, fd@cisco.com, Tero Kivinen Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe, By "context separation", I take you to mean that GRE decides which inner packets go into which tunnels. In realistic terms, that is the true access control mechanism (still left unspecified by the draft) of your system. IPsec is mearly looking at the outer header and providing different treatment to different tunnels. When IPsec, in transport mode, is doing its "access control" on the outer header, no one should claim that any real *system level* access control is being provided by IPsec. That may be acceptable to wise network admistrators who specifically wish to trade off IPsec's access control for more flexibilty about what traffic enters their tunnels. But unless you specify what mechanism your GRE system is using for "context separation" (the real system level access control) you will not achieve interoperable implementations. You and Kivinin are in a debate about wether or not the GRE:key field is needed to identify different GRE tunnels. The only context I can see where it might be needed is if you have multiple GRE tunnels to the same destination. Otherwise, simple traffic selectors of proto=gre and destAddr= would suffice to "allow different GRE traffic flows to be mapped to different IPsec SAs". Given this simple solution with todays traffic selctors for what seems like most applications, I was asking you to provide a justification for why network administrators would really need to have ipsec select on the GRE:key field rather than just the ipDest and protocol field. Overall I think we are asking you to develop a better description of the applicaion you envision and spcifically point out why the GRE:key field is a MUST for your application and point out why current traffic selectors are insufficient. -- Ricky Charlet rcharlet@nortel.com USA 408-754-1733 > -----Original Message----- > From: Yingzhe Wu [mailto:yingzhe.wu@zteusa.com] > Sent: Monday, August 25, 2008 8:42 PM > To: Charlet, Ricky (HLYER:0000) > Cc: ipsec@ietf.org; fd@cisco.com; 'Tero Kivinen' > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Ricky, > > You got it reversed :) > I want to have IPsec does the access control for GRE, in > terms of protocol > and port. > GRE does its own thing: context separation and encapsulation > of traffic for > carrying it over IP, has nothing to do with access control. > > I am not sure I understand your question. There are > requirements and the > solution should be the scope proposed by Pasi: > o A standards-track extension to IKEv2 to support using the "Key" > field of Generic Routing Encapsulation (GRE) packets, specified > in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > port number or ICMP type/code fields). This allows different GRE > traffic flows to be mapped to different IPsec SAs. Any further > extensions related to the use of IPsec with GRE are beyond the > scope of this work item. > > This is now different from the original draft in the subject > field, so may > be this is the confusion. > > BR/ > Yingzhe > > > -----Original Message----- > > From: Ricky Charlet [mailto:rcharlet@nortel.com] > > Sent: Monday, August 25, 2008 3:34 PM > > To: Yingzhe Wu > > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > Howdy, > > > > The end goal of your application is that you want traffic > > separation onto different SAs in an environment where IPsec is *not* > > doing the access control. You are specifying a mechanism > for IPsec to > > take note of the GRE key field and apply differentiated policy based > > upon that field... But it was the GRE system which enforced > the 'access > > control' and decided which packets belonged in which tunnels. > > > > My one critizism would by that you have not fully specified the > > requirements for an ineroperable implenetation here. The > access control > > that really is running in your system, in the GRE side of > the house, is > > hidden from this document. That should not be out of scope > if you want > > to interoperate and make the same access-control guarentees across > > differnet vendors. > > > > One question I have is... Do you really see the need?... > > Multiple GRE tunnels to the *same* destination with some type of > > non-ipsec access control stearing packets into the different tunnels > > which receive different IPsec privacy treatment. It seems esoteric. > > > > -- > > Ricky Charlet > > rcharlet@nortel.com > > USA 408-754-1733 > > > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > > On Behalf Of Yingzhe Wu > > > Sent: Monday, August 25, 2008 12:51 PM > > > To: 'Tero Kivinen' > > > Cc: ipsec@ietf.org; fd@cisco.com > > > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > Hi Tero, > > > > > > > Not all security gateways will ever implement GRE key traffic > > > > selectors. Actually my guess is that even if we go forward > > > and specify > > > > GRE key selectors there is going to be only very few > > implementations > > > > who are ever going to implement them. For those > implementations who > > > > consider that providing solution is important for them, > they will > > > > implement whethever is needed. > > > > > > > While I think there are many existing Ipsec > implementation not even > > > supporting "port" selector, and perhaps not even supporting > > "protocol" > > > selector, the use of these products is totally up to customer. > > > I am not in a position to say why vendors manufacture these > > > products, but as > > > long as there are customer asking for a feature, we are > > > certainly motivated > > > to implement it, especially it doesn't cost much, and I > > > believe it serves a > > > lot. Your comments are well received, but I'd like to hear > > > what other people > > > have to say and I think there are few people on this list > > > think there are > > > values in the GRE case. > > > > > > > Ok, so some customers thing some other customers > IP-packets might > > > > taint their IP-packets even when they are usign GRE keys to > > separate > > > > them, but if they use same credentials and but use different > > > > encryption key, that magic tainting does not happen? > > > > > > > > I can see some customers requiring using separate > credentials when > > > > creating their tunnels, as that would offer real separation from > > > > traffic from others. If the IPsec SAs are using same IKE SA > > > to create > > > > them, then using multiple IPsec SAs does not provide any real > > > > difference in separation. > > > > > > > Yes it does. Each IPsec keying material is derived by > fresh nonces, > > so > > > cracking one IPsec does not affect other IPsec. And if > > > needed, DH exchange > > > can be employed during IPsec creation such that even if > > > IKE_SA is cracked > > > later (which is much harder to do if not impossible), it does > > > not affect > > > IPsec, as there is PFS in it. It seems we are repeating > here as well. > > > > > > > Note, that even when you are using one IPsec SA to send traffic, > > you > > > > still can have those GRE keys in the packet, and those > > > can/will be used > > > > to route packets properly, and they do offer separation from one > > > > customers traffic to another. > > > > > > > Well, this is not what customer is asking here... > > > > > > > > > Hmm.. actually we do not need one IKE SA for each separate > > > > customer,we > > > > > > only need separate IKE SA for each different set of security > > > > > > algorithms, or we can use same method we do for QoS, > > > i.e. we do not > > > > > > negotiate the different GRE keys, the sending site > will simply > > > > select > > > > > > IPsec SA with acceptable IPsec algorithms based on his own > > local > > > > > > policy, i.e. there is no need to agree on the use of > > > GRE key values > > > > at > > > > > > all. > > > > > There is no such requirement. > > > > > > > > What requirement? I am lost here. I didn't list any > > > requirement there, > > > > I simply explained that we do not need any GRE keys as traffic > > > > selectors at all, as we can use similar method than for QoS. > > > > > > > A requirement that providing IKE_SA based on different > > > algorithms, and also > > > the assumption that GRE key assignment is based on crypto > > > algorithm (which I > > > think is odd). Otherwise the solution you proposed below > does work. > > > > > > > The QoS situation in IPsec is so that sender and receiver create > > > > multiple IPsec SAs between them and all of them have > exactly same > > > > traffic selectors. Then the sending site will locally associate > > > > different QoS parameters to those IPsec SAs, but that > selection is > > > > communicated to the other end at all. > > > > > > > > The sending site will then simply send traffic through > > > those multiple > > > > IPsec SA tunnels following his own policy. As the > responder cannot > > > > verify the policy anyways there is no need for > responder even try, > > > > which means it simply assumes sender site did follow the policy. > > > > > > > > In the GRE key situation the thing is same. As the GRE key > > > checking on > > > > the responder site does not really offer anything, there is > > > no reason > > > > for responder to do that, thus it can simply trust that > sender did > > > > follow acceptable policy (and if sender had already > sent packet out > > > > using too weak encryption the damage is already done when the > > packet > > > > is received by the other end). > > > > > > > > So what they can do is that sender site will create > multiple IPsec > > > > SAs, then it will decide that IPsec SA 1 is going to be used for > > > > traffic using GRE key 1231, so all traffic having GRE > key 1231 is > > > > going to be routed to IPsec SA 1. For traffic using GRE > key 343 and > > > > requiring different IPsec algorithms, the sender site > will create > > > > another IPsec SA (with normal traffic selectors) and it will > > > > internally route GRE key 343 to tat IPsec SA 2. The > > > responder end can > > > > then get the packets from the tunnels and look at the > GRE key and > > > > route them forward. There is no need to negotiate that > IPsec SA 1 > > is > > > > using GRE key 1231, it is enough both ends follow their own > > policies > > > > when they select IPsec SA what they are using. > > > > > > > > Their GRE based policy might be something like: This GRE > > > key xxx must > > > > use 3DES, this GRE key yyy must go on separate IPsec SA, > > > all other GRE > > > > keys can share IPsec SA and use AES. > > > > > > > > I think that is the best solution to this problem. > > > > > > > > The traffic selector negotiation is really only needed > for the exit > > > > tunnel checks on the recipent end. > > > > -- > > > > kivinen@safenet-inc.com > > > > > > _______________________________________________ > > > 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 Aug 26 10:45:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D743A6A4B; Tue, 26 Aug 2008 10:45:53 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C134428C1F3; Tue, 26 Aug 2008 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080826174506.C134428C1F3@core3.amsl.com> Date: Tue, 26 Aug 2008 10:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al. Filename : draft-ietf-ipsecme-ikev2bis-00.txt Pages : 129 Date : 2008-08-26 This document describes version 2 of the Internet Key Exchange (IKE) protocol. It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-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-ikev2bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-26103135.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 Aug 26 10:46: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 F11D428C1F7; Tue, 26 Aug 2008 10:46:13 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CDC3A6B26 for ; Tue, 26 Aug 2008 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 Rh8YBqDEZonZ for ; Tue, 26 Aug 2008 10:46:11 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DE6B328C1F8 for ; Tue, 26 Aug 2008 10:46:10 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7QHk7E07873; Tue, 26 Aug 2008 17:46:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 12:46:02 -0500 Message-ID: <57852B615814704D91EC988F6EA9DF220A44ECFE@zrc2hxm1.corp.nortel.com> In-Reply-To: <18611.53420.252788.221577@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments thread-index: AckHYH4fFLWEUATBTkKp8ch+7+8gRwAQnMRQ References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <18611.53420.252788.221577@fireball.kivinen.iki.fi> From: "Ricky Charlet" To: "Tero Kivinen" Cc: Yingzhe Wu , ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Hmmmm, "access control" becomes a touchy term when IPsec is in trasnport mode (as per this draft). The access control IPsec is offering here is on the outer headers (the GRE headers). Wether we do ipsec access control on the outer header fields of IP src/des & proto or on GRE:key is the question of this draft. But either way, neither of those 'access control' services provided by IPsec in transport mode took any note of the inner traffic. Therefore I claim that from a systems level perspective, "access-control" here is being provided by GRE (which is choosing which packets get into which tunnels), not by IPsec. -- Ricky Charlet rcharlet@nortel.com USA 408-754-1733 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, August 26, 2008 2:45 AM > To: Charlet, Ricky (HLYER:0000) > Cc: Yingzhe Wu; ipsec@ietf.org; fd@cisco.com > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Ricky Charlet writes: > > The end goal of your application is that you want traffic > > separation onto different SAs in an environment where IPsec is *not* > > doing the access control. > > But traffic selector negotiation is ONLY needed when you are doing > access control in IPsec at the responder side. I.e. only reason to do > traffic selectors is to negotiate what kind of exit tunnel checks the > responder needs to do. If IPsec is not doing access control, there is > no point of doing traffic selector negotiations for GRE keys. > -- > kivinen@safenet-inc.com > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 10:53: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 089183A6BAC; Tue, 26 Aug 2008 10:53:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B8E3A6BA8 for ; Tue, 26 Aug 2008 10:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 o7wOqp0JqqW4 for ; Tue, 26 Aug 2008 10:53:38 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4424D28C1CD for ; Tue, 26 Aug 2008 10:53:37 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QHra2P090990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Aug 2008 10:53:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080826174506.C134428C1F3@core3.amsl.com> References: <20080826174506.C134428C1F3@core3.amsl.com> Date: Tue, 26 Aug 2008 10:53:34 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-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 Hey, the WG has a document! :-) Yaron will set up the WG's tracking system to start tracking issues for this document. Tero already sent in a very long one, Pasi promises one of his own, and there are a few from the past that I have collected. However, WG members should feel free (nay, encouraged!) to submit issues of their own. Gold stars will be awarded for issues that are brought forward with unique and easily-understood Subject: lines. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 11:32: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 39DD128C106; Tue, 26 Aug 2008 11:32:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CC43A6BC4 for ; Tue, 26 Aug 2008 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 yCs5x8FfkT7m for ; Tue, 26 Aug 2008 11:32:33 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 8F5653A6BC3 for ; Tue, 26 Aug 2008 11:32:32 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7QIWiAZ027722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 13:32:45 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> <18610.37154.828874.211382@fireball.kivinen.iki.fi> <00ae01c906ea$17fd4d00$47f7e700$@wu@zteusa.com> <18611.52320.33486.701810@fireball.kivinen.iki.fi> In-Reply-To: <18611.52320.33486.701810@fireball.kivinen.iki.fi> Date: Tue, 26 Aug 2008 11:32:29 -0700 Message-ID: <00a301c907aa$19887da0$4c9978e0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckHXfpVOB4TKhS3QReuF9ABYTSYRgAN41Gg Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > I do not see any difference there. You still need to configure the new > GRE key for that new customer to the IPsec policy so it is allowed to > be used as traffic selector, and that change needs to be done in both > ends. There is no difference between using GRE key as traffic selector > vs using interface or IP-number as traffic selector. > Of course there needs to be some configuration, otherwise nothing is changed and new feature isn't provided. But when it comes to new configuration, I view adding GRE key selector much easier compare to adding new IP address, new context/policy/credential. Besides, in some cases, GRE key can be distributed by BGP in PPVPN case and adding GRE key selector can be automated. > You seem to have misunderstood my text completely. I didn't suggest > using multiple IP adresses as a solution here, I just mentioned that > even in BITS implementation there are selectors which can be used to > select the correct tunnel. I.e. either packets are coming from > multiple different interfaces thus interface selectors can be used to > distinguish to which IPsec tunnel packet needs to be forwarded or if > they come in using only one interface then they must have some kind of > IP-addresses which are not overlapping thus they also can be used as > selectors. > I may have misunderstood. Let me clarify the scenario: There is IP node (single address), in PPVPN case called PE, which uses GRE tunnel for multiplexing and carrying user traffic over IP. Now IPsec is added as BITS, other than using GRE key as traffic selector, how is IPsec going to provide different SA protection for different GRE tunnel? There is no multiple interfaces here as BITS does not have access to IP source code and there may not be overlapping addresses as user plane may not be IP traffic at all. And the same for BITW or SGW in tunnel mode. There is no other information that is accessible by IPsec besides GRE key. > > > The main reason for using traffic selectors seems to be so that you > > > can push the policy decision out from the IPsec (i.e. someone > before > > > IPsec decides the policy to be used and writes that policy to GRE > key > > > of the packet). But if you are pushing the policy decision out from > > > the IPsec then there does not need to be tunnel exit checks, thus > > > there is no need to negotiate the traffic selectors at all. I.e. if > > > the receiving end of the IPsec packet will not check whether the > > > sending send used same policy, then you can simply just send > packets > > > through any tunnel and receiving end will receive them and assume > > > sender site used correct policy. > > > > > The selection of GRE tunnels is not tied to IPsec or any policy > decision. > > Good. So you agree there is no need to do GRE key traffic selectors, > as they are not tied to the IPsec policy? Only reason to negotiate > traffic selectors is to make sure that responder can also do policy > checks for the traffic, and if responder SGW does not need to verify > that all packets follow the negotiated policy there is no need to do > traffic selector negotiation. > I lost you? Please see the scenario I described above to see if we are on the same page? There already exists GRE tunnel, which PE uses for traffic multiplexing and now IPsec is added. There is still a need to do GRE key traffic selector, for policy check or access control, and provides different SA to different GRE tunnel. > > Let's say there are already GRE tunnels, and IPsec is applied > according to > > different situations (for example, intra-provider case vs inter- > provider > > case). Tunnel exit check certainly helps here as a way of access > control, to > > make sure the correct GRE tunnel (as identified by key) is coming > from the > > correct peer with the correct security association applied, otherwise > there > > exists a problem of GRE tunnel spoofing. > > So now you are again saying that the GRE tunnels and IPsec policies > are tied together? Which one it is? > Please see the scenario I described above to see if it clarifies. > Note, that checking that one authenticated peer only uses GRE keys he > is authenticated to use, can be done without traffic selectors (i.e. > for example by just using normal firewall rules). For that reason, there would be no need for other traffic selector: protocol, port etc. Note that RFC4301 says: The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection. The checking whether > the one peer followed the algorithm requirements and data separation > can also be done without GRE key traffic selectors, but that gets so > much complicated that if it is really required then GRE key traffic > selectors are needed. > Yes, GRE key selector is needed here, otherwise one can't be sure the algorithm requirement and data separation. So you agree there is benefits of GRE key and the solution comes not-complicated at all. > Again the GRE tunnel spoofing can only be done if the attacker gets > access to the authenticated SGW on the system, thus in that case he > can already do whathever he wants for traffic going through that node. True, if SGW is compromised, anything could happen. This is not much of debate here. > Only thing you might want to protect is that he cannot then attack > traffic not going through that node, and that can be done by firewall > rules (most likely the GRE module already has that kind of checks, > where it makes sure that only certain GRE endpoints can use certain > GRE keys). Please see firewall discussion above. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 11:41:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78443A6BBC; Tue, 26 Aug 2008 11:41:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB763A69F3 for ; Tue, 26 Aug 2008 11:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 qCpfBySX--Hr for ; Tue, 26 Aug 2008 11:41:04 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 996BC3A6800 for ; Tue, 26 Aug 2008 11:41:04 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7QIf61m028158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 13:41:06 -0500 From: "Yingzhe Wu" To: "'Tero Kivinen'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b901c906ec$2ba10070$82e30150$@wu@zteusa.com> <18611.52987.871362.126574@fireball.kivinen.iki.fi> In-Reply-To: <18611.52987.871362.126574@fireball.kivinen.iki.fi> Date: Tue, 26 Aug 2008 11:40:51 -0700 Message-ID: <00a401c907ab$43ed5880$cbc80980$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckHX3c0odYwUCazTrmb60MR58lPXwASrZTg Content-Language: en-us Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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, > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, August 26, 2008 2:38 AM > To: Yingzhe Wu > Cc: ipsec@ietf.org > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Yingzhe Wu writes: > > Yes it does. Each IPsec keying material is derived by fresh nonces, > so > > cracking one IPsec does not affect other IPsec. And if needed, DH > exchange > > can be employed during IPsec creation such that even if IKE_SA is > cracked > > later (which is much harder to do if not impossible), it does not > affect > > IPsec, as there is PFS in it. It seems we are repeating here as well. > > Easy solution to here is: Do not use weak encryption. > > All the encryption algorihtms used should be balanced and strong, thus > cracking IPsec keying material for IPsec SA should not be possible, > and if they can crack it on real time for one SA, they can do it for > multiple SAs simultaneously by just scaling their hardware linearly > (i.e. to crack 2 SAs just get two machines to do it). > Everything comes as a cost, doesn't it? :) we have argued this before. > > > > There is no such requirement. > > > What requirement? > ... > > A requirement that providing IKE_SA based on different algorithms, > and also > > the assumption that GRE key assignment is based on crypto algorithm > (which I > > think is odd). > > One more time to just verify I understood correctly: So there is no > requirement to have differet GRE key tunnels to have different crypto > algorithms (either in IKE SA or in IPsec SA)? > End user may have minimum security requirements when connecting to PPVPN provider, such as integrity only, or encryption (how strong etc)... >From PPVPN, the requirement is for IPsec separation, and that naturally comes with different crypto algorithms. And we (as vendors) provide equipments to PPVPN. > I think someone listed that as a requirement, but might have > misunderstood that then. > > So your requirement for multiple IPsec SAs is only that you want to > have fresh crypt keys for each or some GRE key tunnels, so they cannot > be attacked simultaneously? > Correct. > > Otherwise the solution you proposed below does work. > > I think my solution works also for that case where you just want to > have separate keying material. If so, can you explain why it does not > work here? > May be no one does key assignment for GRE tunnel based on crypto algorithm? > > > The QoS situation in IPsec is so that sender and receiver create > > > multiple IPsec SAs between them and all of them have exactly same > > > traffic selectors. Then the sending site will locally associate > > > different QoS parameters to those IPsec SAs, but that selection is > > > communicated to the other end at all. > > > > > > The sending site will then simply send traffic through those > multiple > > > IPsec SA tunnels following his own policy. As the responder cannot > > > verify the policy anyways there is no need for responder even try, > > > which means it simply assumes sender site did follow the policy. > > > > > > In the GRE key situation the thing is same. As the GRE key checking > on > > > the responder site does not really offer anything, there is no > reason > > > for responder to do that, thus it can simply trust that sender did > > > follow acceptable policy (and if sender had already sent packet out > > > using too weak encryption the damage is already done when the > packet > > > is received by the other end). > > > > > > So what they can do is that sender site will create multiple IPsec > > > SAs, then it will decide that IPsec SA 1 is going to be used for > > > traffic using GRE key 1231, so all traffic having GRE key 1231 is > > > going to be routed to IPsec SA 1. For traffic using GRE key 343 and > > > requiring different IPsec algorithms, the sender site will create > > > another IPsec SA (with normal traffic selectors) and it will > > > internally route GRE key 343 to tat IPsec SA 2. The responder end > can > > > then get the packets from the tunnels and look at the GRE key and > > > route them forward. There is no need to negotiate that IPsec SA 1 > is > > > using GRE key 1231, it is enough both ends follow their own > policies > > > when they select IPsec SA what they are using. > > > > > > Their GRE based policy might be something like: This GRE key xxx > must > > > use 3DES, this GRE key yyy must go on separate IPsec SA, all other > GRE > > > keys can share IPsec SA and use AES. > > > > > > I think that is the best solution to this problem. > > > > > > The traffic selector negotiation is really only needed for the exit > > > tunnel checks on the recipent end. > -- > kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 26 12:09: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 4589F3A696B; Tue, 26 Aug 2008 12:09:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E293A696B for ; Tue, 26 Aug 2008 12:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 GA5ddfbynSxb for ; Tue, 26 Aug 2008 12:09:37 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 481243A6862 for ; Tue, 26 Aug 2008 12:09:37 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7QJ8GaW029749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 14:08:17 -0500 From: "Yingzhe Wu" To: "'Ricky Charlet'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> In-Reply-To: <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> Date: Tue, 26 Aug 2008 12:08:00 -0700 Message-ID: <00b101c907af$0f8d9ce0$2ea8d6a0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31AADNk7wAAdEDugAANXe3A= Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Ricky, > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@nortel.com] > Sent: Tuesday, August 26, 2008 10:40 AM > To: Yingzhe Wu > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Yingzhe, > > By "context separation", I take you to mean that GRE decides > which inner packets go into which tunnels. Yes In realistic terms, that is > the true access control mechanism (still left unspecified by the draft) > of your system. I don't understand why you call it access control? There are many use of GRE tunnels, such as providing VPN user separation in PPVPN case, softwire, remote access... They were never called access control before. IPsec is mearly looking at the outer header and > providing different treatment to different tunnels. When IPsec, in > transport mode, is doing its "access control" on the outer header, no > one should claim that any real *system level* access control is being > provided by IPsec. True, no one is claiming IPsec is access control other aspects than just GRE tunnel header information. Note it is not limited to transport mode as that draft (in the subject) is outdated. That may be acceptable to wise network admistrators > who specifically wish to trade off IPsec's access control for more > flexibilty about what traffic enters their tunnels. But unless you > specify what mechanism your GRE system is using for "context > separation" > (the real system level access control) you will not achieve > interoperable implementations. > The new draft will be talking about how IPsec handles GRE key, so the scope is limited to IPsec issues only. How GRE tunnel is used, including setup or which traffic goes into which tunnel depending on how PPVPN decides to use it and hence out of scope of IPsec. > > You and Kivinin are in a debate about wether or not the GRE:key > field is needed to identify different GRE tunnels. The only context I > can see where it might be needed is if you have multiple GRE tunnels to > the same destination. Otherwise, simple traffic selectors of proto=gre > and destAddr= would suffice to "allow different GRE traffic > flows to be mapped to different IPsec SAs". Given this simple solution > with todays traffic selctors for what seems like most applications, I > was asking you to provide a justification for why network > administrators > would really need to have ipsec select on the GRE:key field rather than > just the ipDest and protocol field. > There are multiple GRE tunnels between same pair of gateways in PPVPN case and there is a requirement from PPVPN for IPsec separation. With today's traffic selector categories, we are not able to provide that feature. > Overall I think we are asking you to develop a better > description of the applicaion you envision and spcifically point out > why > the GRE:key field is a MUST for your application and point out why > current traffic selectors are insufficient. > > > -- > Ricky Charlet > rcharlet@nortel.com > USA 408-754-1733 > > > -----Original Message----- > > From: Yingzhe Wu [mailto:yingzhe.wu@zteusa.com] > > Sent: Monday, August 25, 2008 8:42 PM > > To: Charlet, Ricky (HLYER:0000) > > Cc: ipsec@ietf.org; fd@cisco.com; 'Tero Kivinen' > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > Hi Ricky, > > > > You got it reversed :) > > I want to have IPsec does the access control for GRE, in > > terms of protocol > > and port. > > GRE does its own thing: context separation and encapsulation > > of traffic for > > carrying it over IP, has nothing to do with access control. > > > > I am not sure I understand your question. There are > > requirements and the > > solution should be the scope proposed by Pasi: > > o A standards-track extension to IKEv2 to support using the "Key" > > field of Generic Routing Encapsulation (GRE) packets, specified > > in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > > port number or ICMP type/code fields). This allows different GRE > > traffic flows to be mapped to different IPsec SAs. Any further > > extensions related to the use of IPsec with GRE are beyond the > > scope of this work item. > > > > This is now different from the original draft in the subject > > field, so may > > be this is the confusion. > > > > BR/ > > Yingzhe > > > > > -----Original Message----- > > > From: Ricky Charlet [mailto:rcharlet@nortel.com] > > > Sent: Monday, August 25, 2008 3:34 PM > > > To: Yingzhe Wu > > > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > Howdy, > > > > > > The end goal of your application is that you want traffic > > > separation onto different SAs in an environment where IPsec is > *not* > > > doing the access control. You are specifying a mechanism > > for IPsec to > > > take note of the GRE key field and apply differentiated policy > based > > > upon that field... But it was the GRE system which enforced > > the 'access > > > control' and decided which packets belonged in which tunnels. > > > > > > My one critizism would by that you have not fully specified the > > > requirements for an ineroperable implenetation here. The > > access control > > > that really is running in your system, in the GRE side of > > the house, is > > > hidden from this document. That should not be out of scope > > if you want > > > to interoperate and make the same access-control guarentees across > > > differnet vendors. > > > > > > One question I have is... Do you really see the need?... > > > Multiple GRE tunnels to the *same* destination with some type of > > > non-ipsec access control stearing packets into the different > tunnels > > > which receive different IPsec privacy treatment. It seems esoteric. > > > > > > -- > > > Ricky Charlet > > > rcharlet@nortel.com > > > USA 408-754-1733 > > > > > > > > > > -----Original Message----- > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > > > On Behalf Of Yingzhe Wu > > > > Sent: Monday, August 25, 2008 12:51 PM > > > > To: 'Tero Kivinen' > > > > Cc: ipsec@ietf.org; fd@cisco.com > > > > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > > > Hi Tero, > > > > > > > > > Not all security gateways will ever implement GRE key traffic > > > > > selectors. Actually my guess is that even if we go forward > > > > and specify > > > > > GRE key selectors there is going to be only very few > > > implementations > > > > > who are ever going to implement them. For those > > implementations who > > > > > consider that providing solution is important for them, > > they will > > > > > implement whethever is needed. > > > > > > > > > While I think there are many existing Ipsec > > implementation not even > > > > supporting "port" selector, and perhaps not even supporting > > > "protocol" > > > > selector, the use of these products is totally up to customer. > > > > I am not in a position to say why vendors manufacture these > > > > products, but as > > > > long as there are customer asking for a feature, we are > > > > certainly motivated > > > > to implement it, especially it doesn't cost much, and I > > > > believe it serves a > > > > lot. Your comments are well received, but I'd like to hear > > > > what other people > > > > have to say and I think there are few people on this list > > > > think there are > > > > values in the GRE case. > > > > > > > > > Ok, so some customers thing some other customers > > IP-packets might > > > > > taint their IP-packets even when they are usign GRE keys to > > > separate > > > > > them, but if they use same credentials and but use different > > > > > encryption key, that magic tainting does not happen? > > > > > > > > > > I can see some customers requiring using separate > > credentials when > > > > > creating their tunnels, as that would offer real separation > from > > > > > traffic from others. If the IPsec SAs are using same IKE SA > > > > to create > > > > > them, then using multiple IPsec SAs does not provide any real > > > > > difference in separation. > > > > > > > > > Yes it does. Each IPsec keying material is derived by > > fresh nonces, > > > so > > > > cracking one IPsec does not affect other IPsec. And if > > > > needed, DH exchange > > > > can be employed during IPsec creation such that even if > > > > IKE_SA is cracked > > > > later (which is much harder to do if not impossible), it does > > > > not affect > > > > IPsec, as there is PFS in it. It seems we are repeating > > here as well. > > > > > > > > > Note, that even when you are using one IPsec SA to send traffic, > > > you > > > > > still can have those GRE keys in the packet, and those > > > > can/will be used > > > > > to route packets properly, and they do offer separation from > one > > > > > customers traffic to another. > > > > > > > > > Well, this is not what customer is asking here... > > > > > > > > > > > Hmm.. actually we do not need one IKE SA for each separate > > > > > customer,we > > > > > > > only need separate IKE SA for each different set of > security > > > > > > > algorithms, or we can use same method we do for QoS, > > > > i.e. we do not > > > > > > > negotiate the different GRE keys, the sending site > > will simply > > > > > select > > > > > > > IPsec SA with acceptable IPsec algorithms based on his own > > > local > > > > > > > policy, i.e. there is no need to agree on the use of > > > > GRE key values > > > > > at > > > > > > > all. > > > > > > There is no such requirement. > > > > > > > > > > What requirement? I am lost here. I didn't list any > > > > requirement there, > > > > > I simply explained that we do not need any GRE keys as traffic > > > > > selectors at all, as we can use similar method than for QoS. > > > > > > > > > A requirement that providing IKE_SA based on different > > > > algorithms, and also > > > > the assumption that GRE key assignment is based on crypto > > > > algorithm (which I > > > > think is odd). Otherwise the solution you proposed below > > does work. > > > > > > > > > The QoS situation in IPsec is so that sender and receiver > create > > > > > multiple IPsec SAs between them and all of them have > > exactly same > > > > > traffic selectors. Then the sending site will locally associate > > > > > different QoS parameters to those IPsec SAs, but that > > selection is > > > > > communicated to the other end at all. > > > > > > > > > > The sending site will then simply send traffic through > > > > those multiple > > > > > IPsec SA tunnels following his own policy. As the > > responder cannot > > > > > verify the policy anyways there is no need for > > responder even try, > > > > > which means it simply assumes sender site did follow the policy. > > > > > > > > > > In the GRE key situation the thing is same. As the GRE key > > > > checking on > > > > > the responder site does not really offer anything, there is > > > > no reason > > > > > for responder to do that, thus it can simply trust that > > sender did > > > > > follow acceptable policy (and if sender had already > > sent packet out > > > > > using too weak encryption the damage is already done when the > > > packet > > > > > is received by the other end). > > > > > > > > > > So what they can do is that sender site will create > > multiple IPsec > > > > > SAs, then it will decide that IPsec SA 1 is going to be used > for > > > > > traffic using GRE key 1231, so all traffic having GRE > > key 1231 is > > > > > going to be routed to IPsec SA 1. For traffic using GRE > > key 343 and > > > > > requiring different IPsec algorithms, the sender site > > will create > > > > > another IPsec SA (with normal traffic selectors) and it will > > > > > internally route GRE key 343 to tat IPsec SA 2. The > > > > responder end can > > > > > then get the packets from the tunnels and look at the > > GRE key and > > > > > route them forward. There is no need to negotiate that > > IPsec SA 1 > > > is > > > > > using GRE key 1231, it is enough both ends follow their own > > > policies > > > > > when they select IPsec SA what they are using. > > > > > > > > > > Their GRE based policy might be something like: This GRE > > > > key xxx must > > > > > use 3DES, this GRE key yyy must go on separate IPsec SA, > > > > all other GRE > > > > > keys can share IPsec SA and use AES. > > > > > > > > > > I think that is the best solution to this problem. > > > > > > > > > > The traffic selector negotiation is really only needed > > for the exit > > > > > tunnel checks on the recipent end. > > > > > -- > > > > > kivinen@safenet-inc.com > > > > > > > > _______________________________________________ > > > > 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 Aug 26 12:12:34 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 61B9E3A6BEC; Tue, 26 Aug 2008 12:12:34 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1553A6800 for ; Tue, 26 Aug 2008 12:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 mBKnWjHotjpP for ; Tue, 26 Aug 2008 12:12:33 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 2AB8B3A6BFE for ; Tue, 26 Aug 2008 12:12:18 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7QJABrY029869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 14:10:12 -0500 From: "Yingzhe Wu" To: "'Ricky Charlet'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> In-Reply-To: <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> Date: Tue, 26 Aug 2008 12:09:55 -0700 Message-ID: <00b201c907af$53ea3920$fbbeab60$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31AADNk7wAAdEDugAANXe3A= Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Ricky, > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@nortel.com] > Sent: Tuesday, August 26, 2008 10:40 AM > To: Yingzhe Wu > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Yingzhe, > > By "context separation", I take you to mean that GRE decides > which inner packets go into which tunnels. Yes In realistic terms, that is > the true access control mechanism (still left unspecified by the draft) > of your system. I don't understand why you call it access control? There are many use of GRE tunnels, such as providing VPN user separation in PPVPN case, softwire, remote access... They were never called access control before. IPsec is mearly looking at the outer header and > providing different treatment to different tunnels. When IPsec, in > transport mode, is doing its "access control" on the outer header, no > one should claim that any real *system level* access control is being > provided by IPsec. True, no one is claiming IPsec is access control other aspects than just GRE tunnel header information. Note it is not limited to transport mode as that draft (in the subject) is outdated. That may be acceptable to wise network admistrators > who specifically wish to trade off IPsec's access control for more > flexibilty about what traffic enters their tunnels. But unless you > specify what mechanism your GRE system is using for "context > separation" > (the real system level access control) you will not achieve > interoperable implementations. > The new draft will be talking about how IPsec handles GRE key, so the scope is limited to IPsec issues only. How GRE tunnel is used, including setup or which traffic goes into which tunnel depending on how PPVPN decides to use it and hence out of scope of IPsec. > > You and Kivinin are in a debate about wether or not the GRE:key > field is needed to identify different GRE tunnels. The only context I > can see where it might be needed is if you have multiple GRE tunnels to > the same destination. Otherwise, simple traffic selectors of proto=gre > and destAddr= would suffice to "allow different GRE traffic > flows to be mapped to different IPsec SAs". Given this simple solution > with todays traffic selctors for what seems like most applications, I > was asking you to provide a justification for why network > administrators > would really need to have ipsec select on the GRE:key field rather than > just the ipDest and protocol field. > There are multiple GRE tunnels between same pair of gateways in PPVPN case and there is a requirement from PPVPN for IPsec separation. With today's traffic selector categories, we are not able to provide that feature. > Overall I think we are asking you to develop a better > description of the applicaion you envision and spcifically point out > why > the GRE:key field is a MUST for your application and point out why > current traffic selectors are insufficient. > > > -- > Ricky Charlet > rcharlet@nortel.com > USA 408-754-1733 > > > -----Original Message----- > > From: Yingzhe Wu [mailto:yingzhe.wu@zteusa.com] > > Sent: Monday, August 25, 2008 8:42 PM > > To: Charlet, Ricky (HLYER:0000) > > Cc: ipsec@ietf.org; fd@cisco.com; 'Tero Kivinen' > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > Hi Ricky, > > > > You got it reversed :) > > I want to have IPsec does the access control for GRE, in > > terms of protocol > > and port. > > GRE does its own thing: context separation and encapsulation > > of traffic for > > carrying it over IP, has nothing to do with access control. > > > > I am not sure I understand your question. There are > > requirements and the > > solution should be the scope proposed by Pasi: > > o A standards-track extension to IKEv2 to support using the "Key" > > field of Generic Routing Encapsulation (GRE) packets, specified > > in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > > port number or ICMP type/code fields). This allows different GRE > > traffic flows to be mapped to different IPsec SAs. Any further > > extensions related to the use of IPsec with GRE are beyond the > > scope of this work item. > > > > This is now different from the original draft in the subject > > field, so may > > be this is the confusion. > > > > BR/ > > Yingzhe > > > > > -----Original Message----- > > > From: Ricky Charlet [mailto:rcharlet@nortel.com] > > > Sent: Monday, August 25, 2008 3:34 PM > > > To: Yingzhe Wu > > > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > Howdy, > > > > > > The end goal of your application is that you want traffic > > > separation onto different SAs in an environment where IPsec is > *not* > > > doing the access control. You are specifying a mechanism > > for IPsec to > > > take note of the GRE key field and apply differentiated policy > based > > > upon that field... But it was the GRE system which enforced > > the 'access > > > control' and decided which packets belonged in which tunnels. > > > > > > My one critizism would by that you have not fully specified the > > > requirements for an ineroperable implenetation here. The > > access control > > > that really is running in your system, in the GRE side of > > the house, is > > > hidden from this document. That should not be out of scope > > if you want > > > to interoperate and make the same access-control guarentees across > > > differnet vendors. > > > > > > One question I have is... Do you really see the need?... > > > Multiple GRE tunnels to the *same* destination with some type of > > > non-ipsec access control stearing packets into the different > tunnels > > > which receive different IPsec privacy treatment. It seems esoteric. > > > > > > -- > > > Ricky Charlet > > > rcharlet@nortel.com > > > USA 408-754-1733 > > > > > > > > > > -----Original Message----- > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > > > On Behalf Of Yingzhe Wu > > > > Sent: Monday, August 25, 2008 12:51 PM > > > > To: 'Tero Kivinen' > > > > Cc: ipsec@ietf.org; fd@cisco.com > > > > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > > > Hi Tero, > > > > > > > > > Not all security gateways will ever implement GRE key traffic > > > > > selectors. Actually my guess is that even if we go forward > > > > and specify > > > > > GRE key selectors there is going to be only very few > > > implementations > > > > > who are ever going to implement them. For those > > implementations who > > > > > consider that providing solution is important for them, > > they will > > > > > implement whethever is needed. > > > > > > > > > While I think there are many existing Ipsec > > implementation not even > > > > supporting "port" selector, and perhaps not even supporting > > > "protocol" > > > > selector, the use of these products is totally up to customer. > > > > I am not in a position to say why vendors manufacture these > > > > products, but as > > > > long as there are customer asking for a feature, we are > > > > certainly motivated > > > > to implement it, especially it doesn't cost much, and I > > > > believe it serves a > > > > lot. Your comments are well received, but I'd like to hear > > > > what other people > > > > have to say and I think there are few people on this list > > > > think there are > > > > values in the GRE case. > > > > > > > > > Ok, so some customers thing some other customers > > IP-packets might > > > > > taint their IP-packets even when they are usign GRE keys to > > > separate > > > > > them, but if they use same credentials and but use different > > > > > encryption key, that magic tainting does not happen? > > > > > > > > > > I can see some customers requiring using separate > > credentials when > > > > > creating their tunnels, as that would offer real separation > from > > > > > traffic from others. If the IPsec SAs are using same IKE SA > > > > to create > > > > > them, then using multiple IPsec SAs does not provide any real > > > > > difference in separation. > > > > > > > > > Yes it does. Each IPsec keying material is derived by > > fresh nonces, > > > so > > > > cracking one IPsec does not affect other IPsec. And if > > > > needed, DH exchange > > > > can be employed during IPsec creation such that even if > > > > IKE_SA is cracked > > > > later (which is much harder to do if not impossible), it does > > > > not affect > > > > IPsec, as there is PFS in it. It seems we are repeating > > here as well. > > > > > > > > > Note, that even when you are using one IPsec SA to send traffic, > > > you > > > > > still can have those GRE keys in the packet, and those > > > > can/will be used > > > > > to route packets properly, and they do offer separation from > one > > > > > customers traffic to another. > > > > > > > > > Well, this is not what customer is asking here... > > > > > > > > > > > Hmm.. actually we do not need one IKE SA for each separate > > > > > customer,we > > > > > > > only need separate IKE SA for each different set of > security > > > > > > > algorithms, or we can use same method we do for QoS, > > > > i.e. we do not > > > > > > > negotiate the different GRE keys, the sending site > > will simply > > > > > select > > > > > > > IPsec SA with acceptable IPsec algorithms based on his own > > > local > > > > > > > policy, i.e. there is no need to agree on the use of > > > > GRE key values > > > > > at > > > > > > > all. > > > > > > There is no such requirement. > > > > > > > > > > What requirement? I am lost here. I didn't list any > > > > requirement there, > > > > > I simply explained that we do not need any GRE keys as traffic > > > > > selectors at all, as we can use similar method than for QoS. > > > > > > > > > A requirement that providing IKE_SA based on different > > > > algorithms, and also > > > > the assumption that GRE key assignment is based on crypto > > > > algorithm (which I > > > > think is odd). Otherwise the solution you proposed below > > does work. > > > > > > > > > The QoS situation in IPsec is so that sender and receiver > create > > > > > multiple IPsec SAs between them and all of them have > > exactly same > > > > > traffic selectors. Then the sending site will locally associate > > > > > different QoS parameters to those IPsec SAs, but that > > selection is > > > > > communicated to the other end at all. > > > > > > > > > > The sending site will then simply send traffic through > > > > those multiple > > > > > IPsec SA tunnels following his own policy. As the > > responder cannot > > > > > verify the policy anyways there is no need for > > responder even try, > > > > > which means it simply assumes sender site did follow the policy. > > > > > > > > > > In the GRE key situation the thing is same. As the GRE key > > > > checking on > > > > > the responder site does not really offer anything, there is > > > > no reason > > > > > for responder to do that, thus it can simply trust that > > sender did > > > > > follow acceptable policy (and if sender had already > > sent packet out > > > > > using too weak encryption the damage is already done when the > > > packet > > > > > is received by the other end). > > > > > > > > > > So what they can do is that sender site will create > > multiple IPsec > > > > > SAs, then it will decide that IPsec SA 1 is going to be used > for > > > > > traffic using GRE key 1231, so all traffic having GRE > > key 1231 is > > > > > going to be routed to IPsec SA 1. For traffic using GRE > > key 343 and > > > > > requiring different IPsec algorithms, the sender site > > will create > > > > > another IPsec SA (with normal traffic selectors) and it will > > > > > internally route GRE key 343 to tat IPsec SA 2. The > > > > responder end can > > > > > then get the packets from the tunnels and look at the > > GRE key and > > > > > route them forward. There is no need to negotiate that > > IPsec SA 1 > > > is > > > > > using GRE key 1231, it is enough both ends follow their own > > > policies > > > > > when they select IPsec SA what they are using. > > > > > > > > > > Their GRE based policy might be something like: This GRE > > > > key xxx must > > > > > use 3DES, this GRE key yyy must go on separate IPsec SA, > > > > all other GRE > > > > > keys can share IPsec SA and use AES. > > > > > > > > > > I think that is the best solution to this problem. > > > > > > > > > > The traffic selector negotiation is really only needed > > for the exit > > > > > tunnel checks on the recipent end. > > > > > -- > > > > > kivinen@safenet-inc.com > > > > > > > > _______________________________________________ > > > > 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 Aug 26 12:13:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452E13A6BE3; Tue, 26 Aug 2008 12:13:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EC13A6BEF for ; Tue, 26 Aug 2008 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HOST_EQ_STATIC=1.172, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_82=0.6, MSGID_MULTIPLE_AT=1.449] 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 WYPlZF5Tmk-7 for ; Tue, 26 Aug 2008 12:13:22 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 067173A6BE3 for ; Tue, 26 Aug 2008 12:13:21 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m7QJDMtw030052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 14:13:22 -0500 From: "Yingzhe Wu" To: "'Ricky Charlet'" References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> In-Reply-To: <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> Date: Tue, 26 Aug 2008 12:13:05 -0700 Message-ID: <00b301c907af$c53f21d0$4fbd6570$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckGpZz9IbhHjyp9R+asCwFR4U7g+wAO7GtAAAWd31AADNk7wAAdEDugAANXe3A= Content-Language: en-us Cc: ipsec@ietf.org, fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Ricky, > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@nortel.com] > Sent: Tuesday, August 26, 2008 10:40 AM > To: Yingzhe Wu > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > Hi Yingzhe, > > By "context separation", I take you to mean that GRE decides > which inner packets go into which tunnels. Yes In realistic terms, that is > the true access control mechanism (still left unspecified by the draft) > of your system. I don't understand why you call it access control? There are many use of GRE tunnels, such as providing VPN user separation in PPVPN case, softwire, remote access... They were never called access control before. IPsec is mearly looking at the outer header and > providing different treatment to different tunnels. When IPsec, in > transport mode, is doing its "access control" on the outer header, no > one should claim that any real *system level* access control is being > provided by IPsec. True, no one is claiming IPsec is access control other aspects than just GRE tunnel header information. Note it is not limited to transport mode as that draft (in the subject) is outdated. That may be acceptable to wise network admistrators > who specifically wish to trade off IPsec's access control for more > flexibilty about what traffic enters their tunnels. But unless you > specify what mechanism your GRE system is using for "context > separation" > (the real system level access control) you will not achieve > interoperable implementations. > The new draft will be talking about how IPsec handles GRE key, so the scope is limited to IPsec issues only. How GRE tunnel is used, including setup or which traffic goes into which tunnel depending on how PPVPN decides to use it and hence out of scope of IPsec. > > You and Kivinin are in a debate about wether or not the GRE:key > field is needed to identify different GRE tunnels. The only context I > can see where it might be needed is if you have multiple GRE tunnels to > the same destination. Otherwise, simple traffic selectors of proto=gre > and destAddr= would suffice to "allow different GRE traffic > flows to be mapped to different IPsec SAs". Given this simple solution > with todays traffic selctors for what seems like most applications, I > was asking you to provide a justification for why network > administrators > would really need to have ipsec select on the GRE:key field rather than > just the ipDest and protocol field. > There are multiple GRE tunnels between same pair of gateways in PPVPN case and there is a requirement from PPVPN for IPsec separation. With today's traffic selector categories, we are not able to provide that feature. > Overall I think we are asking you to develop a better > description of the applicaion you envision and spcifically point out > why > the GRE:key field is a MUST for your application and point out why > current traffic selectors are insufficient. > > > -- > Ricky Charlet > rcharlet@nortel.com > USA 408-754-1733 > > > -----Original Message----- > > From: Yingzhe Wu [mailto:yingzhe.wu@zteusa.com] > > Sent: Monday, August 25, 2008 8:42 PM > > To: Charlet, Ricky (HLYER:0000) > > Cc: ipsec@ietf.org; fd@cisco.com; 'Tero Kivinen' > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > Hi Ricky, > > > > You got it reversed :) > > I want to have IPsec does the access control for GRE, in > > terms of protocol > > and port. > > GRE does its own thing: context separation and encapsulation > > of traffic for > > carrying it over IP, has nothing to do with access control. > > > > I am not sure I understand your question. There are > > requirements and the > > solution should be the scope proposed by Pasi: > > o A standards-track extension to IKEv2 to support using the "Key" > > field of Generic Routing Encapsulation (GRE) packets, specified > > in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > > port number or ICMP type/code fields). This allows different GRE > > traffic flows to be mapped to different IPsec SAs. Any further > > extensions related to the use of IPsec with GRE are beyond the > > scope of this work item. > > > > This is now different from the original draft in the subject > > field, so may > > be this is the confusion. > > > > BR/ > > Yingzhe > > > > > -----Original Message----- > > > From: Ricky Charlet [mailto:rcharlet@nortel.com] > > > Sent: Monday, August 25, 2008 3:34 PM > > > To: Yingzhe Wu > > > Cc: ipsec@ietf.org; fd@cisco.com; Tero Kivinen > > > Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > Howdy, > > > > > > The end goal of your application is that you want traffic > > > separation onto different SAs in an environment where IPsec is > *not* > > > doing the access control. You are specifying a mechanism > > for IPsec to > > > take note of the GRE key field and apply differentiated policy > based > > > upon that field... But it was the GRE system which enforced > > the 'access > > > control' and decided which packets belonged in which tunnels. > > > > > > My one critizism would by that you have not fully specified the > > > requirements for an ineroperable implenetation here. The > > access control > > > that really is running in your system, in the GRE side of > > the house, is > > > hidden from this document. That should not be out of scope > > if you want > > > to interoperate and make the same access-control guarentees across > > > differnet vendors. > > > > > > One question I have is... Do you really see the need?... > > > Multiple GRE tunnels to the *same* destination with some type of > > > non-ipsec access control stearing packets into the different > tunnels > > > which receive different IPsec privacy treatment. It seems esoteric. > > > > > > -- > > > Ricky Charlet > > > rcharlet@nortel.com > > > USA 408-754-1733 > > > > > > > > > > -----Original Message----- > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > > > On Behalf Of Yingzhe Wu > > > > Sent: Monday, August 25, 2008 12:51 PM > > > > To: 'Tero Kivinen' > > > > Cc: ipsec@ietf.org; fd@cisco.com > > > > Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments > > > > > > > > Hi Tero, > > > > > > > > > Not all security gateways will ever implement GRE key traffic > > > > > selectors. Actually my guess is that even if we go forward > > > > and specify > > > > > GRE key selectors there is going to be only very few > > > implementations > > > > > who are ever going to implement them. For those > > implementations who > > > > > consider that providing solution is important for them, > > they will > > > > > implement whethever is needed. > > > > > > > > > While I think there are many existing Ipsec > > implementation not even > > > > supporting "port" selector, and perhaps not even supporting > > > "protocol" > > > > selector, the use of these products is totally up to customer. > > > > I am not in a position to say why vendors manufacture these > > > > products, but as > > > > long as there are customer asking for a feature, we are > > > > certainly motivated > > > > to implement it, especially it doesn't cost much, and I > > > > believe it serves a > > > > lot. Your comments are well received, but I'd like to hear > > > > what other people > > > > have to say and I think there are few people on this list > > > > think there are > > > > values in the GRE case. > > > > > > > > > Ok, so some customers thing some other customers > > IP-packets might > > > > > taint their IP-packets even when they are usign GRE keys to > > > separate > > > > > them, but if they use same credentials and but use different > > > > > encryption key, that magic tainting does not happen? > > > > > > > > > > I can see some customers requiring using separate > > credentials when > > > > > creating their tunnels, as that would offer real separation > from > > > > > traffic from others. If the IPsec SAs are using same IKE SA > > > > to create > > > > > them, then using multiple IPsec SAs does not provide any real > > > > > difference in separation. > > > > > > > > > Yes it does. Each IPsec keying material is derived by > > fresh nonces, > > > so > > > > cracking one IPsec does not affect other IPsec. And if > > > > needed, DH exchange > > > > can be employed during IPsec creation such that even if > > > > IKE_SA is cracked > > > > later (which is much harder to do if not impossible), it does > > > > not affect > > > > IPsec, as there is PFS in it. It seems we are repeating > > here as well. > > > > > > > > > Note, that even when you are using one IPsec SA to send traffic, > > > you > > > > > still can have those GRE keys in the packet, and those > > > > can/will be used > > > > > to route packets properly, and they do offer separation from > one > > > > > customers traffic to another. > > > > > > > > > Well, this is not what customer is asking here... > > > > > > > > > > > Hmm.. actually we do not need one IKE SA for each separate > > > > > customer,we > > > > > > > only need separate IKE SA for each different set of > security > > > > > > > algorithms, or we can use same method we do for QoS, > > > > i.e. we do not > > > > > > > negotiate the different GRE keys, the sending site > > will simply > > > > > select > > > > > > > IPsec SA with acceptable IPsec algorithms based on his own > > > local > > > > > > > policy, i.e. there is no need to agree on the use of > > > > GRE key values > > > > > at > > > > > > > all. > > > > > > There is no such requirement. > > > > > > > > > > What requirement? I am lost here. I didn't list any > > > > requirement there, > > > > > I simply explained that we do not need any GRE keys as traffic > > > > > selectors at all, as we can use similar method than for QoS. > > > > > > > > > A requirement that providing IKE_SA based on different > > > > algorithms, and also > > > > the assumption that GRE key assignment is based on crypto > > > > algorithm (which I > > > > think is odd). Otherwise the solution you proposed below > > does work. > > > > > > > > > The QoS situation in IPsec is so that sender and receiver > create > > > > > multiple IPsec SAs between them and all of them have > > exactly same > > > > > traffic selectors. Then the sending site will locally associate > > > > > different QoS parameters to those IPsec SAs, but that > > selection is > > > > > communicated to the other end at all. > > > > > > > > > > The sending site will then simply send traffic through > > > > those multiple > > > > > IPsec SA tunnels following his own policy. As the > > responder cannot > > > > > verify the policy anyways there is no need for > > responder even try, > > > > > which means it simply assumes sender site did follow the policy. > > > > > > > > > > In the GRE key situation the thing is same. As the GRE key > > > > checking on > > > > > the responder site does not really offer anything, there is > > > > no reason > > > > > for responder to do that, thus it can simply trust that > > sender did > > > > > follow acceptable policy (and if sender had already > > sent packet out > > > > > using too weak encryption the damage is already done when the > > > packet > > > > > is received by the other end). > > > > > > > > > > So what they can do is that sender site will create > > multiple IPsec > > > > > SAs, then it will decide that IPsec SA 1 is going to be used > for > > > > > traffic using GRE key 1231, so all traffic having GRE > > key 1231 is > > > > > going to be routed to IPsec SA 1. For traffic using GRE > > key 343 and > > > > > requiring different IPsec algorithms, the sender site > > will create > > > > > another IPsec SA (with normal traffic selectors) and it will > > > > > internally route GRE key 343 to tat IPsec SA 2. The > > > > responder end can > > > > > then get the packets from the tunnels and look at the > > GRE key and > > > > > route them forward. There is no need to negotiate that > > IPsec SA 1 > > > is > > > > > using GRE key 1231, it is enough both ends follow their own > > > policies > > > > > when they select IPsec SA what they are using. > > > > > > > > > > Their GRE based policy might be something like: This GRE > > > > key xxx must > > > > > use 3DES, this GRE key yyy must go on separate IPsec SA, > > > > all other GRE > > > > > keys can share IPsec SA and use AES. > > > > > > > > > > I think that is the best solution to this problem. > > > > > > > > > > The traffic selector negotiation is really only needed > > for the exit > > > > > tunnel checks on the recipent end. > > > > > -- > > > > > kivinen@safenet-inc.com > > > > > > > > _______________________________________________ > > > > 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 Aug 26 16:06: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 C42C23A69CE; Tue, 26 Aug 2008 16:06:21 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09D53A6C44 for ; Tue, 26 Aug 2008 16:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtWXjipZnQFU for ; Tue, 26 Aug 2008 16:06:19 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B4CE53A68C6 for ; Tue, 26 Aug 2008 16:06:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[131.203.63.29]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KY7bl-0000Hf-EW; Tue, 26 Aug 2008 19:05:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00b101c907af$0f8d9ce0$2ea8d6a0$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <48AC22D8.1050903@checkpoint.com> <18605.11934.365458.291102@fireball.kivinen.iki.fi> <00ab01c904ae$e53e8470$afbb8d50$@wu@zteusa.com> <18610.38682.150024.202623@fireball.kivinen.iki.fi> <00b801c906eb$eec8ad60$cc5a0820$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A3C336C@zrc2hxm1.corp.nortel.com> <000f01c9072d$ab38f810$01aae830$@wu@zteusa.com> <57852B615814704D91EC988F6EA9DF220A400316@zrc2hxm1.corp.nortel.com> <00b101c907af$0f8d9ce0$2ea8d6a0$@wu@zteusa.com> Date: Tue, 26 Aug 2008 18:13:45 -0400 To: "Yingzhe Wu" From: Stephen Kent Cc: ipsec@ietf.org, 'Ricky Charlet' , fd@cisco.com, 'Tero Kivinen' Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 want to point out that the SPD selector function and associated text in 4301 were introduced specifically to support PPVPN scenarios. So, I agree with Tero and Ricky about the need to justify a GRE key traffic selector given this history. Sinec the IPsec architecture has been defined and stable for a few of years, any change we make in traffic selectors may have significant implications for hardware implementations. Thus this WG probably should establish a pretty high bar for any proposed changes of that sort. Also, if we label a change of this sort as an optional extension, we encourage non-interoperable implementations, so we should think very carefully before endorsing changes in the set of traffic selectors. Also I agree with Rickey that using transport mode IPsec to convey tunneled traffic is NOT what IPsec access control is about. When using transport mode to protect tunneled traffic, one is bypassing most of the access control mechanisms that IPsec is designed to enforce. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 27 04:12: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 3393B28C0D7; Wed, 27 Aug 2008 04:12:31 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0423A6843 for ; Wed, 27 Aug 2008 04:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 K2m7gLCFjt3j for ; Wed, 27 Aug 2008 04:12:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id DC9BF28C22F for ; Wed, 27 Aug 2008 04:12:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7RBBCH9006536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2008 14:11:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7RBBCpL025324; Wed, 27 Aug 2008 14:11:12 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18613.13904.159708.797010@fireball.kivinen.iki.fi> Date: Wed, 27 Aug 2008 14:11:12 +0300 From: Tero Kivinen To: "Yingzhe Wu" In-Reply-To: <00a301c907aa$19887da0$4c9978e0$@wu@zteusa.com> References: <1218726814.7492.91.camel@fdetienn-laptop> <002401c8fe6e$741d3cf0$5c57b6d0$@wu@zteusa.com> <1218786554.7492.249.camel@fdetienn-laptop> <001e01c901c1$291ea580$7b5bf080$@wu@zteusa.com> <18602.47431.660136.328236@fireball.kivinen.iki.fi> <004301c90253$4871abc0$d9550340$@wu@zteusa.com> <18604.724.57192.305854@fireball.kivinen.iki.fi> <00aa01c904ae$225ef980$671cec80$@wu@zteusa.com> <18610.37154.828874.211382@fireball.kivinen.iki.fi> <00ae01c906ea$17fd4d00$47f7e700$@wu@zteusa.com> <18611.52320.33486.701810@fireball.kivinen.iki.fi> <00a301c907aa$19887da0$4c9978e0$@wu@zteusa.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 28 min X-Total-Time: 36 min Cc: ipsec@ietf.org, fd@cisco.com Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments 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 Yingzhe Wu writes: > I may have misunderstood. Let me clarify the scenario: There is IP node > (single address), in PPVPN case called PE, which uses GRE tunnel for > multiplexing and carrying user traffic over IP. Now IPsec is added as BITS, > other than using GRE key as traffic selector, how is IPsec going to provide > different SA protection for different GRE tunnel? How does the GRE module decide which key to associte to which traffic? Most likely it either uses interface information of the incoming packets (or IP-addresses). The 4.4.1 of architecture document (RFC 4301) describes inputs which are used to select the SPD to be used, and one of those is any local metadata (e.g. the interface via which the packet arrived), so that information should be available for the IPsec module to allow SPD selection. So then IPsec selects suitable SPD based on the interface (or IP-addresses or whetever information is available) and that SPD provides differet SA protection for different GRE tunnels. > There is no multiple interfaces here as BITS does not have access to > IP source code and there may not be overlapping addresses as user > plane may not be IP traffic at all. BITS does not need to have access to the IP source code to provide information about interfaces and such. Even in BITS implementations there is quite common to be able to access or even attach meta-data associated with the packet (for example our implementation is closest to BITS as we do not do require sources of the IP code or modify the OS code, we use suitable firewall etc hooks to get packets to IPsec module). But if there is no multiple-interfaces, where do the packets get in then? How does GRE know which key to associtate to the traffic? > And the same for BITW or SGW in tunnel mode. There is no other information > that is accessible by IPsec besides GRE key. As we are talking about transport mode I do not think BITW or SGW in tunnel mode is concern here. I agree that in BITW or SGW in tunnel mode cases the information is not avaible, but remember that it is possible the GRE key is not also available, because of fragmentation (i.e. BITW or SGW needs to do stateful fragment processing or reassemble fragmented packets to process them). > Please see the scenario I described above to see if it clarifies. It didn't clarify, as it left out the information how GRE module knows which key to associate to which traffic. > > Note, that checking that one authenticated peer only uses GRE keys he > > is authenticated to use, can be done without traffic selectors (i.e. > > for example by just using normal firewall rules). > For that reason, there would be no need for other traffic selector: > protocol, port etc. > Note that RFC4301 says: The IPsec firewall function makes use of the > cryptographically-enforced authentication and integrity provided for all > IPsec traffic to offer better access control than could be obtained through > use of a firewall (one not privy to IPsec internal parameters) plus separate > cryptographic protection. The firewall functionality in the IPsec firewalls is usually much larger than what is explained in the RFC4301, the RFC4301 only lists minimum requirements. For example it commonly includes stateful TCP flow checking and so on. Expanding it even more to include checks for GRE keys, is quite trivial. Also another option is to use the firewall rules provided by the operating system or the firewall rules provided by the GRE module (it is very common now to have multiple firewall/access control modules in the system, one provided by IPsec, another provided by the OS, another provided by the specific modules etc). IPsec firewall rules normally already make sure that other firewall rules after it can trust the source IP-address of the packet when doing their policy checking, i.e. if transport mode (i.e. PROTECT) is required for all GRE traffic from certain IP-addresses (i.e. the PE gateways), then no packets other than from that node protected with IPsec will ever be able to pass IPsec firewall checks, thus the GRE module access control rules can check the GRE source IP-address and GRE key (I am pretty sure they already have some kind of mechanisms for doing that). > Yes, GRE key selector is needed here, otherwise one can't be sure the > algorithm requirement and data separation. So you agree there is benefits of > GRE key and the solution comes not-complicated at all. Yes, I agree that if there is requirement that IPsec exit tunnel checks for GRE keys must be done, then traffic selectors are needed. On the other hand I have not seen such requirement, or reasons for that requirement. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 27 06:04:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785C23A67EF; Wed, 27 Aug 2008 06:04:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86A33A680C for ; Wed, 27 Aug 2008 06:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 Entl0XaZBF74 for ; Wed, 27 Aug 2008 06:04:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 06A183A67A6 for ; Wed, 27 Aug 2008 06:04:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D9733294007; Wed, 27 Aug 2008 16:04:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 187AF294003 for ; Wed, 27 Aug 2008 16:04:37 +0300 (IDT) Received: from [172.31.21.145] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7RD4ajI006942 for ; Wed, 27 Aug 2008 16:04:36 +0300 (IDT) Message-Id: <88C3EF0B-1094-4F62-B407-D55736F8C324@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 16:04:36 +0300 X-Mailer: Apple Mail (2.928.1) Subject: [IPsec] Marking 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've re-read the thread we had 2-3 weeks ago about the rationale for ESP-NULL marking, and I have to say that I'm still not convinced that this is a good idea. I agree that there's no way to transmit to middleware boxes the fact that an SA is ESP-NULL without a new protocol. But a new protocol has some major drawbacks. It's not enough to have both endpoints support this new protocol - all middleboxes need to support it, and that will take many years. Now let's look at the problem. We have two nodes, one on either "side" of the middlebox, that are communicating using ESP (or whatever replacement we define for it). They're allowed to use NULL encryption, but not allowed to use another cipher. That's so the middlebox can, say, allow only HTTP and FTP, and inspect transfered files for viruses. The "attackers" in this case are endpoints who negotiate and use ESP with a real cipher. How hard is it to distinguish random data from a regular TCP (or UDP, or SCTP) packet? routers, operating systems and such do it very easily. So assuming that the traffic is ESP-NULL and dropping things that don't match the security policy is such a good heuristic, that it will work every time. I can't see why as a firewall manufacturer, I need to learn this new XESP just to inspect it like a regular packet. If there is some reason to do this that I'm missing, the IPsec standards already have a protected-but-not-encrypted way to mark packets. Why not make AH work? You could easily make a variant of AH that treats the IP addresses and TCP/UDP ports as mutable fields, and negotiate this variation in IKE. The advantage of this, is that you don't change the format of the AH packet, so the middlebox can still inspect it just like regular AH. We may or may not want to mark the packets (there are 16 reserved bits on the AH header) to hint the middleboxes that it's OK to NAT this packet. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 27 23:49: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 A57F03A6891; Wed, 27 Aug 2008 23:49:29 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F083A6891 for ; Wed, 27 Aug 2008 23:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 rV-GccyxRcWj for ; Wed, 27 Aug 2008 23:49:26 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 440EA3A6829 for ; Wed, 27 Aug 2008 23:49:25 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F2763294003; Thu, 28 Aug 2008 09:49:20 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 02187294001 for ; Thu, 28 Aug 2008 09:49:20 +0300 (IDT) Received: from [172.16.10.81] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7S6nFOx007104 for ; Thu, 28 Aug 2008 09:49:18 +0300 (IDT) Message-ID: <48B64A69.2010705@checkpoint.com> Date: Thu, 28 Aug 2008 09:49:13 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] IKEv2-bis notes 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="===============1072243588==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1072243588== Content-Type: multipart/alternative; boundary="------------040708090206060205090001" This is a multi-part message in MIME format. --------------040708090206060205090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the comments below refer to the previous version of the draft. But Paul promises me that they should still be applicable (including unchanged section numbers). Thanks, Yaron - Sec. 1: "intended to replace": the status WRT IKEv1 and IKEv2 is obviously very different. I suggest: [4306] has obsoleted the IKEv1 document set. The current document replaces [IKEv2] and [Clarif] by a single unified description of the IKEv2 protocol. - Sec. 1 (editorial): is there a good reason to call Child SAs "CHILD_SAs" rather than "Child SAs" (why the Fortran-like underscore?). "That's the way 4306 has it" is not a sufficient reason. - Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. They deserve their own subsection, as well as mention of the commonly used name "DPD, dead peer detection". - 1.1.2: "if there is an inner IP header" then this is not transport mode, contrary to the previous sentence. - 1.1.3: this text "for the initiator to request an IP address owned by the security gateway for use for the duration of its SA" implies that the lifetime of the address is identical to that of the IKE SA. If this is true, it should be explicit in the text of 3.15.1. - 1.2 "All but the headers of all the messages that follow are encrypted and integrity protected." This sentence is hard to understand. I suggest: "The messages that follow are encrypted and integrity protected in their entirety, with the exception of message headers." - 1.2: Clarif-4.3 is a nit, it probably belongs somewhere else, rather than the first description of the protocol. - 1.3.1: the two clarifications at the end are a bit confusing. TFC is negotiated separately for each peer, but non-first-fragment is apparently negotiated for both sides. But this is not explicity stated for the latter. Also, please reword "If the peer rejects the proposal of the SA" as "If the peer is unwilling to send or to receive non-first fragments". - 1.3.2: "supplied in the SPI fields", add: "of the SA payload". - Need a reference to 2.14 (generation of the IKE_SA crypto material) from both 1.2 and 1.3.2. - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it is omitted? - 1.4: "replaced for the purpose of rekeying" - replace by "rekeyed". - 1.4: "This is the expected way an endpoint can ask the other endpoint to verify that it is alive." Add: "This is often referred to as a liveness check, or Dead Peer Detection (DPD)". - 1.4: "in inbound half" should be "the inbound half". - 1.4: the section should be broken into two, maybe "The INFORMATIONAL Exchange" and "Deleting an SA". - 1.6: page 17 is a bit late in the game to introduce the word "MUST". - 1.7: I don't know what "amplifications" means. Also, the following paragraph (major and minor numbers) is redundant and confusing. This *is* the same protocol. - 2. Clarif-7.5 is redundant, it is mentioned in 2.23. - 2.3: The first paragraph contains an apparent contradiciton. It mentions that pipelining is done "if the other endpoint has indicated its ability to handle such requests" and then goes on to describe how a pipelining implementation can interoperate with a non-pipelining one. Which should be trivial if the pipelining side knows what the other side is capable of. - 2.4: Clarif-7.9 is unclear: "however, receiving parties need to deal with it in other requests" - what requests? How? Why should it ever happen? - 2.6: "needs to choose them so as to be unique identifiers of an IKE_SA" - why was the SHOULD demoted? Uniqueness of the SPI is essential to the protocol. - 2.9 "an IP packet and matches" should be "an IP packet that matches". - 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol. - 2.12: "In particular, it MUST forget [...] any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets". This is confusing and probably incorrect. Any PRNG state used to generate the DH value is long past by the time the IKE SA is deleted. And ff it isn't, then what we are asking here is to reset the PRNG to a base (0-state) configuration, which is insecure. - 2.12: Exponential reuse - can we give a reference on how to do it securely? - 2.16: "The shared key generated during an IKE exchange MUST NOT" - it would be clearer to refer to the previous sentence, "This key MUST NOT". - 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what the gateway should do if the address lease expires? On a related note, the section does not specify the lifetime of the configuration values, i.e. should they be renewed by the next IKE SA rekey, or reauthentication, or never? - 2.22: I suggest to add the following last paragraph: In some cases Robust Header Compression (ROHC) may be more appropriate than IP Compression. The reader is referred to an extension [informational ref] that defines the use of ROHC with IKEv2 and IPsec. - 2.23: in the 2nd bullet, "the location... are" ==> "is". - 3.1 under Flags: "Presence of options are" ==> "is". - 3.1: V flag: since no implementation has V=1 yet, can we define that it is also set for minor version changes? Otherwise an attacker can downgrade the minor version advertised by the peers, which could affect their functionality. - 3.3.2: "This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA." Should be: "This syntax is inherited from ISAKMP, but is unnecessary because the last Transform could be identified from the length of the Proposal." - 3.3.2: there is no explanation here or elsewhere what is meant by the D-H transform for ESP and AH. If nobody's using it, it should be depracated. - 3.3.2: "tranform" - typo. - 3.3.2: please add at the bottom of the section: "Numerous additional transform types have been defined since the publication of RFC 4306. Please refer to the IANA IKEv2 registry for details." - 3.3.4, 2nd paragraph: many things have changed in the last few years. Please remove all the text starting "For example". - 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec). - 3.5: we mention that ID_KEY_ID is opaque and vendor specific, and then we have a MUST implement of ID_KEY_ID for interoperability. This is a contradiction. - 3.6: it is unclear exactly which X.509 format implementations MUST support (presumably #4). Also, the last paragraph is unclear on whether 4 certificate payloads or a bundle with 4 certificates MUST be supported. - 3.12: "Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft." The rules for notifications mean that this is often not needed, because you can ignore unknown notifications. Can we eliminate this requirement? - 3.15.3: shouldn't we remove the whole section, and add a reference to the work-in-progress in IPv6 configuration? - 5: "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." This is kind of strange: how is an implementation supposed to derive these exponents then? - 5: Additional proposed text for the Security Considerations: Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those used for other forms of trust, e.g. to identify trusted Web servers. Moreover, although IKE provides a wide leeway in defining the security policy for trusted peers' identity, credentials and the correlation between them, having such security policy defined explicitly is essential to a secure implementation. Both IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator is authenticated. As a result, an implementation of this protocol (all 100-odd pages!) must be completely robust when deployed on any insecure network. Any implementation vulnerability can and will be exploited by unauthenticated peers. This applies in particular to denial of service attacks, and we note the particular potential issue with the unlimited number of messages in EAP-based authentication. - 7: last paragraph: add "Note to RFC Editor" or the poor guy/gal might miss it. - Appendix C: please also mention extension notifications [N+]. Also, Vendor ID in the CCSA exchange. --------------040708090206060205090001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,


the comments below refer to the previous version of the draft. But Paul promises me that they should still be applicable (including unchanged section numbers).


Thanks,

    Yaron


- Sec. 1: "intended to replace": the status WRT IKEv1 and IKEv2 is obviously very different. I suggest:

    [4306] has obsoleted the IKEv1 document set. The current document replaces [IKEv2] and [Clarif] by a single unified description of the IKEv2 protocol.

- Sec. 1 (editorial): is there a good reason to call Child SAs "CHILD_SAs" rather than "Child SAs" (why the Fortran-like underscore?). "That's the way 4306 has it" is not a sufficient reason.

- Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. They deserve their own subsection, as well as mention of the commonly used name "DPD, dead peer detection".

- 1.1.2: "if there is an inner IP header" then this is not transport mode, contrary to the previous sentence.

- 1.1.3: this text "for the initiator to request an IP address owned by the security gateway for use for the duration of its SA" implies that the lifetime of the address is identical to that of the IKE SA. If this is true, it should be explicit in the text of 3.15.1.

- 1.2 "All but the headers of all the messages that follow are encrypted and integrity protected." This sentence is hard to understand. I suggest: "The messages that follow are encrypted and integrity protected in their entirety, with the exception of message headers."

- 1.2: Clarif-4.3 is a nit, it probably belongs somewhere else, rather than the first description of the protocol.

- 1.3.1: the two clarifications at the end are a bit confusing. TFC is negotiated separately for each peer, but non-first-fragment is apparently negotiated for both sides. But this is not explicity stated for the latter. Also, please reword "If the peer rejects the proposal of the SA" as "If the peer is unwilling to send or to receive non-first fragments".

- 1.3.2: "supplied in the SPI fields", add: "of the SA payload".

- Need a reference to 2.14 (generation of the IKE_SA crypto material) from both 1.2 and 1.3.2.

- 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it is omitted?

- 1.4: "replaced for the purpose of rekeying" - replace by "rekeyed".

- 1.4: "This is the expected way an endpoint can ask the other endpoint to verify that it is alive." Add: "This is often referred to as a liveness check, or Dead Peer Detection (DPD)".

- 1.4: "in inbound half" should be "the inbound half".

- 1.4: the section should be broken into two, maybe "The INFORMATIONAL Exchange" and "Deleting an SA".

- 1.6: page 17 is a bit late in the game to introduce the word "MUST".

- 1.7: I don't know what "amplifications" means. Also, the following paragraph (major and minor numbers) is redundant and confusing. This *is* the same protocol.

- 2. Clarif-7.5 is redundant, it is mentioned in 2.23.

- 2.3: The first paragraph contains an apparent contradiciton. It mentions that pipelining is done "if the other endpoint has indicated its ability to handle such requests" and then goes on to describe how a pipelining implementation can interoperate with a non-pipelining one. Which should be trivial if the pipelining side knows what the other side is capable of.

- 2.4: Clarif-7.9 is unclear: "however, receiving parties need to deal with it in other requests" - what requests? How? Why should it ever happen?

- 2.6: "needs to choose them so as to be unique identifiers of an IKE_SA" - why was the SHOULD demoted? Uniqueness of the SPI is essential to the protocol.

- 2.9 "an IP packet and matches" should be "an IP packet that matches".

- 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol.

- 2.12: "In particular, it MUST forget [...] any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets". This is confusing and probably incorrect. Any PRNG state used to generate the DH value is long past by the time the IKE SA is deleted. And ff it isn't, then what we are asking here is to reset the PRNG to a base (0-state) configuration, which is insecure.

- 2.12: Exponential reuse - can we give a reference on how to do it securely?

- 2.16: "The shared key generated during an IKE exchange MUST NOT" - it would be clearer to refer to the previous sentence, "This key MUST NOT".

- 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what the gateway should do if the address lease expires? On a related note, the section does not specify the lifetime of the configuration values, i.e. should they be renewed by the next IKE SA rekey, or reauthentication, or never?

- 2.22: I suggest to add the following last paragraph: In some cases Robust Header Compression (ROHC) may be more appropriate than IP Compression. The reader is referred to an extension [informational ref] that defines the use of ROHC with IKEv2 and IPsec.

- 2.23: in the 2nd bullet, "the location... are" ==> "is".

- 3.1 under Flags: "Presence of options are" ==> "is".

- 3.1: V flag: since no implementation has V=1 yet, can we define that it is also set for minor version changes? Otherwise an attacker can downgrade the minor version advertised by the peers, which could affect their functionality.

- 3.3.2: "This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA." Should be: "This syntax is inherited from ISAKMP, but is unnecessary because the last Transform could be identified from the length of the Proposal."

- 3.3.2: there is no explanation here or elsewhere what is meant by the D-H transform for ESP and AH. If nobody's using it, it should be depracated.

- 3.3.2: "tranform" - typo.

- 3.3.2: please add at the bottom of the section: "Numerous additional transform types have been defined since the publication of RFC 4306. Please refer to the IANA IKEv2 registry for details."

- 3.3.4, 2nd paragraph: many things have changed in the last few years. Please remove all the text starting "For example".

- 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec).

- 3.5: we mention that ID_KEY_ID is opaque and vendor specific, and then we have a MUST implement of ID_KEY_ID for interoperability. This is a contradiction.

- 3.6: it is unclear exactly which X.509 format implementations MUST support (presumably #4). Also, the last paragraph is unclear on whether 4 certificate payloads or a bundle with 4 certificates MUST be supported.

- 3.12: "Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft." The rules for notifications mean that this is often not needed, because you can ignore unknown notifications. Can we eliminate this requirement?

- 3.15.3: shouldn't we remove the whole section, and add a reference to the work-in-progress in IPv6 configuration?

- 5: "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." This is kind of strange: how is an implementation supposed to derive these exponents then?

- 5: Additional proposed text for the Security Considerations:

Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those used for other forms of trust, e.g. to identify trusted Web servers. Moreover, although IKE provides a wide leeway in defining the security policy for trusted peers' identity, credentials and the correlation between them, having such security policy defined explicitly is essential to a secure implementation.

Both IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator is authenticated. As a result, an implementation of this protocol (all 100-odd pages!) must be completely robust when deployed on any insecure network. Any implementation vulnerability can and will be exploited by unauthenticated peers. This applies in particular to denial of service attacks, and we note the particular potential issue with the unlimited number of messages in EAP-based authentication.

- 7: last paragraph: add "Note to RFC Editor" or the poor guy/gal might miss it.

- Appendix C: please also mention extension notifications [N+]. Also, Vendor ID in the CCSA exchange.

--------------040708090206060205090001-- --===============1072243588== 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 --===============1072243588==-- From ipsec-bounces@ietf.org Thu Aug 28 03:24: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 110EA3A6AA1; Thu, 28 Aug 2008 03:24:14 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD4E3A6AA1 for ; Thu, 28 Aug 2008 03:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_32=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 N7A8grQDQn7T for ; Thu, 28 Aug 2008 03:24:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 86A153A67AC for ; Thu, 28 Aug 2008 03:24:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7SANnVJ020110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 13:23:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7SANm0m020435; Thu, 28 Aug 2008 13:23:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18614.31924.283924.160375@fireball.kivinen.iki.fi> Date: Thu, 28 Aug 2008 13:23:48 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <48B64A69.2010705@checkpoint.com> References: <48B64A69.2010705@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 31 min X-Total-Time: 97 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2-bis notes 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 agree your other notes, just commenting few of them. Yaron Sheffer writes: > - Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. > They deserve their own subsection, as well as mention of the commonly > used name "DPD, dead peer detection". The reason it is liveness test instead of dead peer detection, is that we are not detecting whether the other end is dead, we are detecting whether the other end is live. If the other end is not alive, then we will be retransmitting packets until we time out. Thats why I think liveness test is much better term than dead peer detection. > - 1.1.3: this text "for the initiator to request an IP address owned by > the security gateway for use for the duration of its SA" implies that > the lifetime of the address is identical to that of the IKE SA. If this > is true, it should be explicit in the text of 3.15.1. The INTERNAL_ADDRESS_EXPIRY was already removed from 3.15.1, but I agree that we need explicit text there too. > - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it > is omitted? We had this discussion April 2005, and I think we did not reach concensus on the matter: http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html Perhaps we can now reach concensus how it should be. I still think that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus Diffie-Hellman group cannot be NONE, and KE payloads MUST be present. If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can be NONE (it cannot be left out,as the Diffie-Hellman Group transform type is mandatory for IKE), then KE payloads would be ommitted. The original RFC4306 text was confusing as it shared the same picture and text for Child SA creation and rekeying of both IPsec SA and IKE SA. The new text is much better. > - 2.4: Clarif-7.9 is unclear: "however, receiving parties need to deal > with it in other requests" - what requests? How? Why should it ever happen? I think the text is there to say that even if other end sends INITIAL_CONTACT as separate informational exchange or some other IKE_AUTH request (i.e. not first), then receiving end needs to ignore it or something (i.e. it is not fatal error to see it in other places). I agree this text should be clarified. > - 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what > the gateway should do if the address lease expires? On a related note, > the section does not specify the lifetime of the configuration values, > i.e. should they be renewed by the next IKE SA rekey, or > reauthentication, or never? The needs to be renewed when new IKE SA is negotiated, they do not need to renewed on IKE SA rekey or based on time. As there is no longer INTERNAL_ADDRESS_EXPIRY the address lease will not expire anymore, but if server side is using some mechanism which have address expiry, it needs to renew it by himself, and if that fails, I think the only thing it can do is to tear down the IKE SA, which will force other end to restart IKE SA negotiation and request addresses again. Reauthentication is just starting IKE SA from the start, thus it needs to request addresses again. > - 3.1: V flag: since no implementation has V=1 yet, can we define that > it is also set for minor version changes? Otherwise an attacker can > downgrade the minor version advertised by the peers, which could affect > their functionality. There is no need, as the major and minor version numbers are authenticated after the exchange finishes, so if attacker modifies minor version number both ends will fail the authentication, thus SA creation will fail. The reason it is needed for major version number, is that in that case the responder cannot reply with authenticated error for bigger version number, thus we need to trust unauthenticated error and fall back to lower version. > - 3.3.2: there is no explanation here or elsewhere what is meant by the > D-H transform for ESP and AH. If nobody's using it, it should be depracated. See 1.3.1 and the KE payloads there. D-H transforms are used to provide PFS for IPsec SAs, and it is widely used. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 28 03:46: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 0DEBF3A6B03; Thu, 28 Aug 2008 03:46:02 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932A628C1A8 for ; Thu, 28 Aug 2008 03:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 ofdXG0P2l77y for ; Thu, 28 Aug 2008 03:45:59 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0E5693A69C9 for ; Thu, 28 Aug 2008 03:45:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 97E28294002; Thu, 28 Aug 2008 13:45:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BFB78294001; Thu, 28 Aug 2008 13:45:36 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7SAjaOx013219; Thu, 28 Aug 2008 13:45:36 +0300 (IDT) Message-ID: <48B681CF.8000300@checkpoint.com> Date: Thu, 28 Aug 2008 13:45:35 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <48B64A69.2010705@checkpoint.com> <18614.31924.283924.160375@fireball.kivinen.iki.fi> In-Reply-To: <18614.31924.283924.160375@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2-bis notes 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="===============1256083232==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1256083232== Content-Type: multipart/alternative; boundary="------------020605010209050707010505" This is a multi-part message in MIME format. --------------020605010209050707010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit HI Tero, thanks for your response. See below. Yaron Tero Kivinen wrote: > I agree your other notes, just commenting few of them. > Same here. > Yaron Sheffer writes: > >> - Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. >> They deserve their own subsection, as well as mention of the commonly >> used name "DPD, dead peer detection". >> > > The reason it is liveness test instead of dead peer detection, is that > we are not detecting whether the other end is dead, we are detecting > whether the other end is live. If the other end is not alive, then we > will be retransmitting packets until we time out. Thats why I think > liveness test is much better term than dead peer detection. > > No problem. I am OK with "liveness test" being the preferred name, but we still need to mention the commonly used synonym. And my essential point is, instead of mentioning it 3-4 times, we should have one section describing it. [snip] >> - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it >> is omitted? >> > > We had this discussion April 2005, and I think we did not reach > concensus on the matter: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html > > Perhaps we can now reach concensus how it should be. I still think > that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus > Diffie-Hellman group cannot be NONE, and KE payloads MUST be present. > > If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can > be NONE (it cannot be left out,as the Diffie-Hellman Group transform > type is mandatory for IKE), then KE payloads would be ommitted. > > The original RFC4306 text was confusing as it shared the same picture > and text for Child SA creation and rekeying of both IPsec SA and IKE > SA. The new text is much better. > > We are not changing the protocol this time (although my original comment did imply that), even if we don't like this "SHOULD". But then we still need to explain how the SA is generated if KE is not there. Sec. 2.14 always requires the quantity "g^ir". [snip] --------------020605010209050707010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

HI Tero,


thanks for your response. See below.


    Yaron


Tero Kivinen wrote:

I agree your other notes, just commenting few of them.
Same here.
Yaron Sheffer writes:
  
- Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. 
They deserve their own subsection, as well as mention of the commonly 
used name "DPD, dead peer detection".
    

The reason it is liveness test instead of dead peer detection, is that
we are not detecting whether the other end is dead, we are detecting
whether the other end is live. If the other end is not alive, then we
will be retransmitting packets until we time out. Thats why I think
liveness test is much better term than dead peer detection.
No problem. I am OK with "liveness test" being the preferred name, but we still need to mention the commonly used synonym. And my essential point is, instead of mentioning it 3-4 times, we should have one section describing it.

[snip] 
- 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it 
is omitted?
    

We had this discussion April 2005, and I think we did not reach
concensus on the matter:

http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html

Perhaps we can now reach concensus how it should be. I still think
that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus
Diffie-Hellman group cannot be NONE, and KE payloads MUST be present.

If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can
be NONE (it cannot be left out,as the Diffie-Hellman Group transform
type is mandatory for IKE), then KE payloads would be ommitted.

The original RFC4306 text was confusing as it shared the same picture
and text for Child SA creation and rekeying of both IPsec SA and IKE
SA. The new text is much better.
We are not changing the protocol this time (although my original comment did imply that), even if we don't like this "SHOULD". But then we still need to explain how the SA is generated if KE is not there. Sec. 2.14 always requires the quantity "g^ir".

[snip] --------------020605010209050707010505-- --===============1256083232== 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 --===============1256083232==-- From ipsec-bounces@ietf.org Thu Aug 28 03:53:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B7B3A6B03; Thu, 28 Aug 2008 03:53:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704F73A69D8 for ; Thu, 28 Aug 2008 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_32=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 TZmUaE+Z+11E for ; Thu, 28 Aug 2008 03:53:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 36BC63A6844 for ; Thu, 28 Aug 2008 03:53:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m7SArheZ016602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 13:53:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m7SArhQ5002838; Thu, 28 Aug 2008 13:53:43 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18614.33719.854741.268338@fireball.kivinen.iki.fi> Date: Thu, 28 Aug 2008 13:53:43 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <48B681CF.8000300@checkpoint.com> References: <48B64A69.2010705@checkpoint.com> <18614.31924.283924.160375@fireball.kivinen.iki.fi> <48B681CF.8000300@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 1 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2-bis notes 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 Yaron Sheffer writes: > >> - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it > >> is omitted? > >> > > > > We had this discussion April 2005, and I think we did not reach > > concensus on the matter: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html > > http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html > > > > Perhaps we can now reach concensus how it should be. I still think > > that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus > > Diffie-Hellman group cannot be NONE, and KE payloads MUST be present. > > > > If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can > > be NONE (it cannot be left out,as the Diffie-Hellman Group transform > > type is mandatory for IKE), then KE payloads would be ommitted. > > > > The original RFC4306 text was confusing as it shared the same picture > > and text for Child SA creation and rekeying of both IPsec SA and IKE > > SA. The new text is much better. > > > > > We are not changing the protocol this time (although my original comment > did imply that), even if we don't like this "SHOULD". But then we still > need to explain how the SA is generated if KE is not there. Sec. 2.14 > always requires the quantity "g^ir". 2.14 requires it, which means KE is mandatory in the initial exchange. 2.18 does not require it, which means it could be left out for IKE SA rekey. There is also Clarif-5.12 there explaining the situation. Perhaps we should add pointer to 1.3.2 to 2.18? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 28 03:58: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 BAE5A3A69D8; Thu, 28 Aug 2008 03:58:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1CA3A67E5 for ; Thu, 28 Aug 2008 03:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 hmL7d6yBAJrg for ; Thu, 28 Aug 2008 03:58:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 263FD3A6B59 for ; Thu, 28 Aug 2008 03:58:48 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 85EC0294002; Thu, 28 Aug 2008 13:58:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 99F69294001; Thu, 28 Aug 2008 13:58:49 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7SAwmOx016618; Thu, 28 Aug 2008 13:58:49 +0300 (IDT) Message-ID: <48B684E8.4030105@checkpoint.com> Date: Thu, 28 Aug 2008 13:58:48 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <48B64A69.2010705@checkpoint.com> <18614.31924.283924.160375@fireball.kivinen.iki.fi> <48B681CF.8000300@checkpoint.com> <18614.33719.854741.268338@fireball.kivinen.iki.fi> In-Reply-To: <18614.33719.854741.268338@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2-bis notes 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="===============1501520001==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1501520001== Content-Type: multipart/alternative; boundary="------------010505040502020100050400" This is a multi-part message in MIME format. --------------010505040502020100050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You are right, I missed 2.18, and a pointer to it in 1.3.2 would help. Yaron Tero Kivinen wrote: > Yaron Sheffer writes: > >>>> - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it >>>> is omitted? >>>> >>>> >>> We had this discussion April 2005, and I think we did not reach >>> concensus on the matter: >>> >>> http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html >>> http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html >>> http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html >>> http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html >>> http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html >>> >>> Perhaps we can now reach concensus how it should be. I still think >>> that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus >>> Diffie-Hellman group cannot be NONE, and KE payloads MUST be present. >>> >>> If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can >>> be NONE (it cannot be left out,as the Diffie-Hellman Group transform >>> type is mandatory for IKE), then KE payloads would be ommitted. >>> >>> The original RFC4306 text was confusing as it shared the same picture >>> and text for Child SA creation and rekeying of both IPsec SA and IKE >>> SA. The new text is much better. >>> >>> >>> >> We are not changing the protocol this time (although my original comment >> did imply that), even if we don't like this "SHOULD". But then we still >> need to explain how the SA is generated if KE is not there. Sec. 2.14 >> always requires the quantity "g^ir". >> > > 2.14 requires it, which means KE is mandatory in the initial exchange. > 2.18 does not require it, which means it could be left out for IKE SA > rekey. > > There is also Clarif-5.12 there explaining the situation. Perhaps we > should add pointer to 1.3.2 to 2.18? > --------------010505040502020100050400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

You are right, I missed 2.18, and a pointer to it in 1.3.2 would help.


    Yaron


Tero Kivinen wrote:

Yaron Sheffer writes:
  
- 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it 
is omitted?
    
        
We had this discussion April 2005, and I think we did not reach
concensus on the matter:

http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html

Perhaps we can now reach concensus how it should be. I still think
that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus
Diffie-Hellman group cannot be NONE, and KE payloads MUST be present.

If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can
be NONE (it cannot be left out,as the Diffie-Hellman Group transform
type is mandatory for IKE), then KE payloads would be ommitted.

The original RFC4306 text was confusing as it shared the same picture
and text for Child SA creation and rekeying of both IPsec SA and IKE
SA. The new text is much better.

  
      
We are not changing the protocol this time (although my original comment 
did imply that), even if we don't like this "SHOULD". But then we still 
need to explain how the SA is generated if KE is not there. Sec. 2.14 
always requires the quantity "g^ir".
    

2.14 requires it, which means KE is mandatory in the initial exchange.
2.18 does not require it, which means it could be left out for IKE SA
rekey.

There is also Clarif-5.12 there explaining the situation. Perhaps we
should add pointer to 1.3.2 to 2.18?
--------------010505040502020100050400-- --===============1501520001== 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 --===============1501520001==-- From ipsec-bounces@ietf.org Sat Aug 30 21:56:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABB43A68AC; Sat, 30 Aug 2008 21:56:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6A73A68AC for ; Sat, 30 Aug 2008 21:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 WE+AI60uyFOw for ; Sat, 30 Aug 2008 21:56:47 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2AF153A6820 for ; Sat, 30 Aug 2008 21:56:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 83768294001; Sun, 31 Aug 2008 07:56:47 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7D5EB200479; Sun, 31 Aug 2008 07:56:46 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m7V4ukOx004336; Sun, 31 Aug 2008 07:56:46 +0300 (IDT) Message-Id: From: Yoav Nir To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 31 Aug 2008 07:18:43 +0300 References: <88C3EF0B-1094-4F62-B407-D55736F8C324@checkpoint.com> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Marking 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 On Aug 29, 2008, at 5:03 AM, Stephen Kent wrote: > I don't think it is fair to say that all middleboxes need to support > a new IPsec header, such as the one that has been proposed for XESP. > Only middleboxes that need to examine content and that operate in an > environment where IPsec is in use (primarily on an E-to-E basis?) > will need to become aware of a new header. I agree, but in today's Internet, end-to-end paths will have some middleboxes along the path that actually do examine the content to some extent: firewalls, IPS devices, and NAT devices. >> Now let's look at the problem. We have two nodes, one on either >> "side" of the middlebox, that are communicating using ESP (or >> whatever replacement we define for it). They're allowed to use NULL >> encryption, but not allowed to use another cipher. That's so the >> middlebox can, say, allow only HTTP and FTP, and inspect transfered >> files for viruses. The "attackers" in this case are endpoints who >> negotiate and use ESP with a real cipher. How hard is it to >> distinguish random data from a regular TCP (or UDP, or SCTP) >> packet? routers, operating systems and such do it very easily. So >> assuming that the traffic is ESP-NULL and dropping things that >> don't match the security policy is such a good heuristic, that it >> will work every time. I can't see why as a firewall manufacturer, >> I need to learn this new XESP just to inspect it like a regular >> packet. > > I don't recall seeing a concise description of the (range of) > security policies the proponents of his solution believe motivate > this solution approach. (If I missed the message that did this, > please excuse me, and provide a copy of the message.) See discussion in the archives from 6-Aug and 7-Aug entitled "Motivation for ESP-null marking", particularly two responses from Ken Grewal. > Absent such a characterization, we can't determine if simpler > solutions are preferable. However, even if the only policy to be > enforced is the one described above, it is not clear that is is > "easy" for a middlebox to measure the entropy in packet payloads > (at high data rates). Some additional justification for this > assertion would be helpful. As you've said, it's only the middlebox that inspects the packets, and they already do it at the same data rate. It's not really necessary to measure entropy. They only need to run their usual inspection, and get random data instead of the protocol they were expecting. >> If there is some reason to do this that I'm missing, the IPsec >> standards already have a protected-but-not-encrypted way to mark >> packets. Why not make AH work? > > AH is inefficient, compared to ESP-NULL. That's why 4301 downgraded > support for it to a MAY vs. a MUST. Why is AH inefficient? The integrity protection is similar to ESP except that you sign some extra fields (or set them to zero). I was under the impression that AH was downgraded because NAT boxes break it. >> You could easily make a variant of AH that treats the IP addresses >> and TCP/UDP ports as mutable fields, and negotiate this variation >> in IKE. The advantage of this, is that you don't change the format >> of the AH packet, so the middlebox can still inspect it just like >> regular AH. We may or may not want to mark the packets (there are >> 16 reserved bits on the AH header) to hint the >> middleboxes that it's OK to NAT this packet. > > Before we consider a variant of AH that provides even less integrity > protection, I think we need to have a lot of discussion of the > implications of this approach. Also If we create a variant of AH, > why is it less intrusive than a new protocol like XESP? We don't > carry version numbers in AH and ESP. We rely on IKE to negotiate > them, so a middlebox cannot know what version of AH is in use, > unless we assign a new protocol number, as has been sggested for XESP. What I'm suggesting is to change the buffer that is integrity protected. The AH packet on the wire would look like regular AH, so the middlebox would not need to be aware of the changes. Only the endpoints need to be aware. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec