From ipsec-bounces@ietf.org Sun Feb 1 11:21:28 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A81828C187; Sun, 1 Feb 2009 11:21:28 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD6A3A6818 for ; Sun, 1 Feb 2009 11:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.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 dmKjLiYY+QAZ for ; Sun, 1 Feb 2009 11:21:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2742E28C178 for ; Sun, 1 Feb 2009 11:21:01 -0800 (PST) Received: from [10.20.30.158] (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 n11JKekA002085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 12:20:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 1 Feb 2009 11:20:38 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Subject: [IPsec] Reminder: virtual interim meeting on Feb. 3 - additional details X-BeenThere: ipsec@ietf.org 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 everyone, The meeting is on for next week, and authors are reminded to send their slides on time. We are planning to use the TeamSpeak application for both voice conferencing and IM. Paul has kindly set up a private server for our use, and the full details are on the wiki: http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls Please make sure to download and try the client at least one day in advance. The server is already available. Let us know if you have any problems. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Wednesday, January 21, 2009 19:02 > To: ipsec@ietf.org > Subject: [IPsec] ipsecme - virtual interim meeting on Feb. 3 > > Hi everyone, > > The ipsecme working group will hold a virtual interim meeting on Feb. 3, > 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. > Like the Minneapolis meeting, we will focus on getting IKEv2-bis issues > closed. But there's lots of other fun stuff. > > Proposed agenda: > > - Agenda bash (0:05) > - Session resumption update (0:15) > - Visibility heuristics (0:15) > - Redirect open issues (0:10) > - Roadmap document (plus call for volunteers) (0:10) > - Mandatory access control (off-charter item) (0:15) > - IKEv2-bis open issues (0:50) > > We will send an update within the next week on the technicalities of the > call. > > Document editors, please send me your slides by Jan. 29. > > Thanks, > Yaron Email secured by Check Point _______________________________________________ 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 Sun Feb 1 14:17:45 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEF73A6868; Sun, 1 Feb 2009 14:17:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E527C3A6868 for ; Sun, 1 Feb 2009 14:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 VTECEM9ZOJ+1 for ; Sun, 1 Feb 2009 14:17:42 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 668803A67E4 for ; Sun, 1 Feb 2009 14:17:42 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7F03029C004; Mon, 2 Feb 2009 00:17:22 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 96A2A29C002 for ; Mon, 2 Feb 2009 00:16:27 +0200 (IST) X-CheckPoint: {49861C61-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n11MGQ5f019921 for ; Mon, 2 Feb 2009 00:16:27 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 2 Feb 2009 00:16:26 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 2 Feb 2009 00:16:23 +0200 Thread-Topic: [IPsec] Reminder: virtual interim meeting on Feb. 3 - additional details Thread-Index: AcmEokYhm2gaWOO+QxuVhwSSSlKxywAF8PRw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F7E3@il-ex01.ad.checkpoint.com> References: In-Reply-To: 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] Reminder: virtual interim meeting on Feb. 3 - additional details X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The meeting is this Tuesday, Feb. 3. Meeting materials (slides) will be available on the ipsecme wiki, here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203 See you on Tuesday! Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Sunday, February 01, 2009 21:21 > To: ipsec@ietf.org > Subject: [IPsec] Reminder: virtual interim meeting on Feb. 3 - additional > details > > Hi everyone, > > The meeting is on for next week, and authors are reminded to send their > slides on time. > > We are planning to use the TeamSpeak application for both voice > conferencing and IM. Paul has kindly set up a private server for our use, > and the full details are on the wiki: > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls > > Please make sure to download and try the client at least one day in > advance. The server is already available. Let us know if you have any > problems. > > Thanks, > Yaron > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > > Yaron Sheffer > > Sent: Wednesday, January 21, 2009 19:02 > > To: ipsec@ietf.org > > Subject: [IPsec] ipsecme - virtual interim meeting on Feb. 3 > > > > Hi everyone, > > > > The ipsecme working group will hold a virtual interim meeting on Feb. 3, > > 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. > > Like the Minneapolis meeting, we will focus on getting IKEv2-bis issues > > closed. But there's lots of other fun stuff. > > > > Proposed agenda: > > > > - Agenda bash (0:05) > > - Session resumption update (0:15) > > - Visibility heuristics (0:15) > > - Redirect open issues (0:10) > > - Roadmap document (plus call for volunteers) (0:10) > > - Mandatory access control (off-charter item) (0:15) > > - IKEv2-bis open issues (0:50) > > > > We will send an update within the next week on the technicalities of the > > call. > > > > Document editors, please send me your slides by Jan. 29. > > > > Thanks, > > Yaron > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Feb 1 18:08:25 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D59B3A68CE; Sun, 1 Feb 2009 18:08:25 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD473A68CE for ; Sun, 1 Feb 2009 18:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.449 X-Spam-Level: * X-Spam-Status: No, score=1.449 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Haw5e1HM6beb for ; Sun, 1 Feb 2009 18:08:24 -0800 (PST) Received: from ctyaarimta01.yaariinvites.com (ctyaarimta01.yaariinvites.com [63.167.241.174]) by core3.amsl.com (Postfix) with ESMTP id F30CE3A6873 for ; Sun, 1 Feb 2009 18:08:23 -0800 (PST) Received: from strongmail ([63.167.241.220]) by ctyaarimta01.yaariinvites.com (StrongMail Enterprise 4.1.1.1(4.1.1-44827)); Sun, 01 Feb 2009 21:08:05 -0500 X-VirtualServer: Default, ctyaarimta01.yaariinvites.com, 63.167.241.174 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::5281352 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: ipsec@ietf.org X-SMFBL: aXBzZWNAaWV0Zi5vcmc= Date: Sun, 1 Feb 2009 21:08:05 -0500 To: ipsec@ietf.org From: Arnab Bakshi Message-ID: X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc1] MIME-Version: 1.0 Subject: [IPsec] Arnab Bakshi sent you a Friend Request on Yaari X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arnab.bakshi@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559834838==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1559834838== Content-Type: multipart/alternative; boundary="b1_b451a3a74d90af60e19001ecb24fb21c" --b1_b451a3a74d90af60e19001ecb24fb21c Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Arnab Bakshi wants you to join Yaari! Is Arnab your friend? Yes, Arnab is my friend! No, Arnab isn't my friend. Please respond or Arnab may think you said no :( Thanks, The Yaari Team ____ If you prefer not to receive this email tell us here. If you have any concerns regarding the content of this message, please email abuse@yaari.com. Yaari LLC, 358 Angier Ave, Atlanta, GA 30312 YaariDPT219IWD344XVA577EVJ827 --b1_b451a3a74d90af60e19001ecb24fb21c Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Arnab Bakshi wants you to join Yaari!

Is Arnab your friend?

Yes, Arnab is my friend! No, Arnab isn't my friend.

Please respond or Arnab may think you said no :(

Thanks,
The Yaari Team
____
If you prefer not to receive this email tell us here. If you have any concerns
regarding the content of this message, please email abuse@yaari.com.
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariDPT219IWD344XVA577EVJ827 --b1_b451a3a74d90af60e19001ecb24fb21c-- --===============1559834838== 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 --===============1559834838==-- From ipsec-bounces@ietf.org Mon Feb 2 11:00:03 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8873A69DD; Mon, 2 Feb 2009 11:00:03 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 85EE63A6999; Mon, 2 Feb 2009 11:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090202190001.85EE63A6999@core3.amsl.com> Date: Mon, 2 Feb 2009 11:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-03.txt Pages : 11 Date : 2009-02-02 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to re-direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-02105726.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Mon Feb 2 11:05:57 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F039D3A69DD; Mon, 2 Feb 2009 11:05:56 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13ED93A69DD for ; Mon, 2 Feb 2009 11:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 szR4Z7GlDHNQ for ; Mon, 2 Feb 2009 11:05:54 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id A35373A6965 for ; Mon, 2 Feb 2009 11:05:54 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so917144ana.4 for ; Mon, 02 Feb 2009 11:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QwRNw5XYq9DiUmVBQpNmzTZZ4eigh+LQRMtBbWGwPJQ=; b=HfeqP9LDmK9ypnImVZ6EMjoXkw8oTdRtlKPyqRX6zfJAu77RfB71caqBxKd3UWrCRB 3Q90F9XncnPWkh0OOK3h+tyIAoFqPi/Z5tj4sWpz54d66p+mX3VwDIHeNRs6i5euFJxP IoKJGLsj9jeGm3BpfmLX9R0YFfQpdbFKMvJu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NNyNnbK+2poqBsOA+NF9uN6BLswXzklbwzJNzThGL+dgp5hysEY1DuV6xtDfGhsKFO 2ITcnznxvcKQHs8AG1JJUzVnUEWsNBNXEqsHrHPHlZh6DL18f2ByWXtmF3XreSRJCTw4 +8eLYHomGDWkG4QiQ/RGLcMRnsqQs99NQjBQw= MIME-Version: 1.0 Received: by 10.142.58.2 with SMTP id g2mr1945961wfa.313.1233601534110; Mon, 02 Feb 2009 11:05:34 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> Date: Mon, 2 Feb 2009 11:05:34 -0800 Message-ID: From: Vijay Devarapalli To: Yaron Sheffer Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, On Sun, Dec 21, 2008 at 3:58 AM, Yaron Sheffer wrote: > Hi Vijay, Tero, > > Now the real issue: I suggest that we reconsider the solution we're > proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is > left with an IKE SA which is basically useless. So the client will naturally > fail the entire connection attempt. With the current proposal we are asking > the client to *guess* that the gateway wants to redirect it somewhere else, > and to wait (for an indefinite time) for that redirect notification to > arrive. If the Redirect never arrives, we just have a useless timeout. First, the client does not have to wait for an indefinite amount of time. The gateway sends a REDIRECT message right away. The REDIRECT message is re-transmitted until an ack is received from the client. So I don't think the above is an issue. Back to the basic question. What do we want to achieve when the gateway decides the re-direct the client in the middle of an IKE_AUTH exchange? We want to be able to prevent the client from creating an CHILD_SA that is worthless. We want to be able to prevent the client from sending any traffic. Both are achieve by sending NO_ADDITIONAL_SAS in the IKE_AUTH response. The IKE SA has already been created. There is nothing that needs to be done about. The subsequent REDIRECT payload from the gateway to the client would say the IKE SA to be deleted anyway. Therefore I suggest going with NO_ADDITIONAL_SAS payload during the IKE_AUTH exchange, followed by the REDIRECT message from the gateway. Vijay > > In other words, I propose to go back to Fan's proposal of an explicit > Redirect notify in IKE_AUTH, so that the client knows for sure what type of > failure it is seeing. > > Thanks, and Happy Holidays! > > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Tero Kivinen >> Sent: Friday, December 19, 2008 12:24 >> To: Vijay Devarapalli >> Cc: ipsec@ietf.org; Yoav Nir >> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH >> >> Vijay Devarapalli writes: >> > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH >> > response followed by the re-direct message. >> >> Good. >> >> > However, I think we need a clarification in IKEv2bis draft. It would >> > be very easy for someone to interpret that the NO_ADDITIONAL_SAS >> > payload can only be used to reject a CREATE_CHILD_SA request and not >> > the IKE_AUTH request (because thats what the text in RFC 4306 says.) >> > and implement accordingly. >> >> Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS >> text in the draft to indicate those can be also sent during imbedded >> Child SA creation hapening in the IKE_AUTH. >> >> This would mean that we dofollowing changes: >> ---------------------------------------------------------------------- >> In section "1.2. The Initial Exchanges" change >> >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange >> fails for some reason, the IKE SA is still created as usual. The >> list of responses in the IKE_AUTH exchange that do not prevent an IKE >> SA from being set up include at least the following: >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, >> INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. >> >> to (i.e add NO_ADDITIONAL_SAS to the example list) >> >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange >> fails for some reason, the IKE SA is still created as usual. The >> list of responses in the IKE_AUTH exchange that do not prevent an IKE >> SA from being set up include at least the following: >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, >> INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS. >> ---------------------------------------------------------------------- >> In section "1.3. The CREATE_CHILD_SA Exchange" change >> >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification >> to indicate that a CREATE_CHILD_SA request is unacceptable because >> the responder is unwilling to accept any more Child SAs on this IKE >> SA. Some minimal implementations may only accept a single Child SA >> setup in the context of an initial IKE exchange and reject any >> subsequent attempts to add more. >> >> to (explained the situation for minimal clients here already described >> in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH >> and explained what it means): >> >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS >> notification to indicate that a child SA creation request is >> unacceptable because the responder is unwilling to accept any more >> Child SAs on this IKE SA (either because implementation limitations >> or because of policy reasons). Some minimal implementations may >> only accept a single Child SA setup in the context of an initial >> IKE exchange and reject any subsequent attempts to add more. If >> this error message is received it means it is not useful to try to >> create more Child SAs with this IKE SA, because all of them will >> fail with this error. If this error is received during >> CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA >> and create new IKE SA with new Child SA if it wants to get the new >> Child SA created. If this error is received during initial Child SA >> creation in IKE_AUTH that means the Child SA creation was rejected >> either because of policy reasons or resource constraint reasons, >> and there is no point of retrying Child SA creation immediately. >> Instead the recipient should wait for suitable timeout (several >> minutes) to see if server either deletes the IKE SA or indicates >> that situation has changed (for example creates Child SA himself). >> After the timeout expires the client should delete the IKE SA and >> try again. >> ---------------------------------------------------------------------- >> In section "2.9. Traffic Selector Negotiation" change >> >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a >> CREATE_CHILD_SA request is unacceptable because its sender is only >> willing to accept traffic selectors specifying a single pair of >> addresses. The requestor is expected to respond by requesting an SA >> for only the specific traffic it is trying to forward. >> >> to (replace CREATE_CHILD_SA with "Child SA creation" >> >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a >> Child SA creation request is unacceptable because its sender is >> only willing to accept traffic selectors specifying a single pair >> of addresses. The requestor is expected to respond by requesting an >> SA for only the specific traffic it is trying to forward. >> -- >> kivinen@iki.fi >> _______________________________________________ >> 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 Mon Feb 2 11:09:14 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B7928C16E; Mon, 2 Feb 2009 11:09:14 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2CB28C16E for ; Mon, 2 Feb 2009 11:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcBbRNoSSTi3 for ; Mon, 2 Feb 2009 11:09:12 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id ED5D73A69DD for ; Mon, 2 Feb 2009 11:09:11 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1828190wfd.31 for ; Mon, 02 Feb 2009 11:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=c7KcrXwN92bg8uh4PvJcYhqJ4c/bRZ1QbDy/n4OVCZM=; b=HkcGyvioT7xV6pJK3x7sjxOXCXlSPOmFxeforu4aKJzwoQoBFl9c2kMKgDvVwfUbgh jfz4SbNfo+qdU+k1ypuWpYdsCU0eedfaYKGOvQukwJUxSL51A3YezW1bXs+B9+cBq8j8 +RYhPJW2aX3I0YLs18Uc8MA02Yd0MiD+4mKXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cZI/PvbkpOwRqV5O5ax8se59vjNXrjlwr2Xw5EG2vMLe7RHQhs79Q2KAuhIiHlHk6S f35ApEUfftXbseFUb8Cc7/+nru4KbYXo2f04zLdBr1iGlSkFgmKgiIEsHY2dUeNKWGla J3jlNRRMpwpdlk+g/hhkQdyLnpBAWxQTaMhNc= MIME-Version: 1.0 Received: by 10.142.214.5 with SMTP id m5mr1959078wfg.37.1233601732322; Mon, 02 Feb 2009 11:08:52 -0800 (PST) In-Reply-To: <20090202190001.85EE63A6999@core3.amsl.com> References: <20090202190001.85EE63A6999@core3.amsl.com> Date: Mon, 2 Feb 2009 11:08:52 -0800 Message-ID: From: Vijay Devarapalli To: ipsec@ietf.org Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-03.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 Hello, I got quite a few emails offline asking for an update of the draft. So here it is. The only change is removal of the REDIRECT_ACK notification payload. An empty Informational message is used by the client to indicate that it processed the REDIRECT payload. There is still one open issue on the exact procedure when the gateway decides to re-direct the client during the IKE_AUTH exchange. Vijay 2009/2/2 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. > > > Title : Re-direct Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-03.txt > Pages : 11 > Date : 2009-02-02 > > IKEv2 is a protocol for setting up VPN tunnels from a remote location > to a gateway so that the VPN client can access services in the > network behind the gateway. Currently there is no standard mechanism > specified that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to re-direct the VPN client to > attach to another gateway. This document proposes a re-direct > mechanism for IKEv2. The proposed mechanism can also be used in > Mobile IPv6 to enable the home agent to re-direct the mobile node to > another home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 2 11:44:09 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5C73A68E5; Mon, 2 Feb 2009 11:44:09 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF813A68C5 for ; Mon, 2 Feb 2009 11:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSi9kLPQDI69 for ; Mon, 2 Feb 2009 11:44:08 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 3303928C1AE for ; Mon, 2 Feb 2009 11:44:08 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1843947wfd.31 for ; Mon, 02 Feb 2009 11:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rGg9gxCY7UhBkcyk0xP9yQtatgfQiAO2FGQ/vly9xVI=; b=DXkMYcwm3RYPVXNW8hob1mkKdz92M0lauekt7FLv2ekdWuwb2mpAjJd/ScogUxFNHt oiRTJTlNG2lE65RY2nWDxjpi7Vlmy+8VmSlxdlnkTWBZhas95geuwEHYnnZzdS8OUbGm wwTSjM84Y+VepMKcHQvt1cg0YIzCMgZHx7d2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BvQFaWuQPQHFrelevmaCi9/3b+JUt5Wi5X+92nPMku+J0KF/jk+jPtEC9aUa7MWoyH 7S45slMzXCruly4B6SR8HnVZ1bvXIcvTItAcaHkC6r4+R+/NZm1VBHCdGFeAkiLa3E2W +U0W2ILrOdFO7ODw69QQzKuVbqi6hwoiHphCc= MIME-Version: 1.0 Received: by 10.142.245.5 with SMTP id s5mr1957099wfh.198.1233603829243; Mon, 02 Feb 2009 11:43:49 -0800 (PST) In-Reply-To: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> Date: Mon, 2 Feb 2009 11:43:49 -0800 Message-ID: From: Vijay Devarapalli To: Richard Graveman Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, On Mon, Jan 12, 2009 at 5:13 AM, Richard Graveman wrote: > Hi, > > I just read this draft and think your idea is useful. I have one > question (please excuse me if it's been answered): Its not been brought up before. But from the beginning the focus for this draft has always been on IKEv2 client-gateway scenarios. > Is there anything special about VPNs (or MIPv6) that limits the use of > this? Could you just say "IKEv2 Initiator" instead of "VPN client" and > "IKEv2 Responder" instead of "VPN Gateway" everywhere? The mechanism proposed in the draft can be used between any IKEv2 initiator and responder without any changes to the protocol. > I have uses for IKEv2 that are neither VPNs nor MIPv6 and could > possibly benefit from this, but the terminology is somewhat > constraining. If you don't mind, can you share those use-cases/scenarios with us? I can't imagine a scenario where a re-direct would be useful between two IKEv2 peers. Vijay > > Thanks, Rich Graveman > _______________________________________________ > 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 Feb 2 13:27:19 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E743A69B7; Mon, 2 Feb 2009 13:27:19 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAEC3A69B7 for ; Mon, 2 Feb 2009 13:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 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 3QxEA5FueDO3 for ; Mon, 2 Feb 2009 13:27:16 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 011E93A68EC for ; Mon, 2 Feb 2009 13:27:16 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2160329C005; Mon, 2 Feb 2009 23:26:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EAF2B29C002; Mon, 2 Feb 2009 23:26:54 +0200 (IST) X-CheckPoint: {4987623B-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n12LQsei000177; Mon, 2 Feb 2009 23:26:54 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 2 Feb 2009 23:26:54 +0200 From: Yaron Sheffer To: Vijay Devarapalli Date: Mon, 2 Feb 2009 23:26:55 +0200 Thread-Topic: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH Thread-Index: AcmFaTwiFR0u/rB7QkCDJIaYn8NK1wAEvgzA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, Apologies for repeating myself. At the point when the client receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's going to receive a Redirect "right away". So the reasonable thing for it to do is to tear down the IKE SA immediately - the SA has just become useless. In other words, we have a race condition between this notification (and the client's response to it) and the Redirect notification. And the simple solution is to send both notifications together. Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:dvijay@gmail.com] > Sent: Monday, February 02, 2009 21:06 > To: Yaron Sheffer > Cc: Tero Kivinen; ipsec@ietf.org > Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH > > Hi Yaron, > > On Sun, Dec 21, 2008 at 3:58 AM, Yaron Sheffer > wrote: > > Hi Vijay, Tero, > > > > Now the real issue: I suggest that we reconsider the solution we're > > proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is > > left with an IKE SA which is basically useless. So the client will > naturally > > fail the entire connection attempt. With the current proposal we are > asking > > the client to *guess* that the gateway wants to redirect it somewhere > else, > > and to wait (for an indefinite time) for that redirect notification to > > arrive. If the Redirect never arrives, we just have a useless timeout. > > First, the client does not have to wait for an indefinite amount of > time. The gateway sends a REDIRECT message right away. The REDIRECT > message is re-transmitted until an ack is received from the client. So > I don't think the above is an issue. > > Back to the basic question. What do we want to achieve when the > gateway decides the re-direct the client in the middle of an IKE_AUTH > exchange? We want to be able to prevent the client from creating an > CHILD_SA that is worthless. We want to be able to prevent the client > from sending any traffic. Both are achieve by sending > NO_ADDITIONAL_SAS in the IKE_AUTH response. > > The IKE SA has already been created. There is nothing that needs to be > done about. The subsequent REDIRECT payload from the gateway to the > client would say the IKE SA to be deleted anyway. Therefore I suggest > going with NO_ADDITIONAL_SAS payload during the IKE_AUTH exchange, > followed by the REDIRECT message from the gateway. > > Vijay > > > > > > > > In other words, I propose to go back to Fan's proposal of an explicit > > Redirect notify in IKE_AUTH, so that the client knows for sure what type > of > > failure it is seeing. > > > > Thanks, and Happy Holidays! > > > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > >> Tero Kivinen > >> Sent: Friday, December 19, 2008 12:24 > >> To: Vijay Devarapalli > >> Cc: ipsec@ietf.org; Yoav Nir > >> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH > >> > >> Vijay Devarapalli writes: > >> > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH > >> > response followed by the re-direct message. > >> > >> Good. > >> > >> > However, I think we need a clarification in IKEv2bis draft. It would > >> > be very easy for someone to interpret that the NO_ADDITIONAL_SAS > >> > payload can only be used to reject a CREATE_CHILD_SA request and not > >> > the IKE_AUTH request (because thats what the text in RFC 4306 says.) > >> > and implement accordingly. > >> > >> Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS > >> text in the draft to indicate those can be also sent during imbedded > >> Child SA creation hapening in the IKE_AUTH. > >> > >> This would mean that we dofollowing changes: > >> ---------------------------------------------------------------------- > >> In section "1.2. The Initial Exchanges" change > >> > >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH > exchange > >> fails for some reason, the IKE SA is still created as usual. The > >> list of responses in the IKE_AUTH exchange that do not prevent an > IKE > >> SA from being set up include at least the following: > >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > >> INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. > >> > >> to (i.e add NO_ADDITIONAL_SAS to the example list) > >> > >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH > exchange > >> fails for some reason, the IKE SA is still created as usual. The > >> list of responses in the IKE_AUTH exchange that do not prevent an > IKE > >> SA from being set up include at least the following: > >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > >> INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS. > >> ---------------------------------------------------------------------- > >> In section "1.3. The CREATE_CHILD_SA Exchange" change > >> > >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification > >> to indicate that a CREATE_CHILD_SA request is unacceptable because > >> the responder is unwilling to accept any more Child SAs on this IKE > >> SA. Some minimal implementations may only accept a single Child SA > >> setup in the context of an initial IKE exchange and reject any > >> subsequent attempts to add more. > >> > >> to (explained the situation for minimal clients here already described > >> in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH > >> and explained what it means): > >> > >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS > >> notification to indicate that a child SA creation request is > >> unacceptable because the responder is unwilling to accept any more > >> Child SAs on this IKE SA (either because implementation limitations > >> or because of policy reasons). Some minimal implementations may > >> only accept a single Child SA setup in the context of an initial > >> IKE exchange and reject any subsequent attempts to add more. If > >> this error message is received it means it is not useful to try to > >> create more Child SAs with this IKE SA, because all of them will > >> fail with this error. If this error is received during > >> CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA > >> and create new IKE SA with new Child SA if it wants to get the new > >> Child SA created. If this error is received during initial Child SA > >> creation in IKE_AUTH that means the Child SA creation was rejected > >> either because of policy reasons or resource constraint reasons, > >> and there is no point of retrying Child SA creation immediately. > >> Instead the recipient should wait for suitable timeout (several > >> minutes) to see if server either deletes the IKE SA or indicates > >> that situation has changed (for example creates Child SA himself). > >> After the timeout expires the client should delete the IKE SA and > >> try again. > >> ---------------------------------------------------------------------- > >> In section "2.9. Traffic Selector Negotiation" change > >> > >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a > >> CREATE_CHILD_SA request is unacceptable because its sender is only > >> willing to accept traffic selectors specifying a single pair of > >> addresses. The requestor is expected to respond by requesting an SA > >> for only the specific traffic it is trying to forward. > >> > >> to (replace CREATE_CHILD_SA with "Child SA creation" > >> > >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a > >> Child SA creation request is unacceptable because its sender is > >> only willing to accept traffic selectors specifying a single pair > >> of addresses. The requestor is expected to respond by requesting an > >> SA for only the specific traffic it is trying to forward. > >> -- > >> kivinen@iki.fi > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 2 19:02:20 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E16E28C233; Mon, 2 Feb 2009 19:02:20 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA4128C233 for ; Mon, 2 Feb 2009 19:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6G9+HA+zm4a for ; Mon, 2 Feb 2009 19:02:18 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 4744028C131 for ; Mon, 2 Feb 2009 19:02:18 -0800 (PST) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1331t729044 for ; Tue, 3 Feb 2009 03:01:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 22:01:26 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8w== From: "Dragan Grebovich" To: Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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="===============0822920907==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0822920907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C985AB.B4C9ACEC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C985AB.B4C9ACEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable, however: 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics code. Our preference is to find a quick direct match (in a few instructions max). We would have to respin hardware to allow your heuristics implementation. This might not be implementable today, as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS. It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs. =20 4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe. Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancing between flows. That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows". One must keep a significant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices will remain in the future; these will not be able to perform heuristics as defined in the heuristics draft. They may have to be redeployed to other places in the network, causing forklift replacements 8) Even by your own conclusion, heuristics are not 100% accurate. There are some "false positives" and some "false negatives" situations. In summary, I find your draft to be interesting, and I am looking forward to seeing it progress on Informational track. I believe also, that a deterministic approach would be quicker and easier. I suggest the "visibility" draft remain on the WG Standards track as it is more implementable. _____________________________ Dragan Grebovich, CISSP Nortel Networks Enterprise Communication Solutions Product Development Data Systems Strategy and Architecture - Security (978) 288-8069 Billerica, MA 01821 U.S.A ------_=_NextPart_001_01C985AB.B4C9ACEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Tero
I reviewed your heuristics draft and I = believe it is interesting and doable, however:

1) I believe the actual implementation = would require more code than current front-end hardware allows.  = The hardware we work with have a limited space for that much heuristics = code.   Our preference is to find a quick direct match (in a = few instructions max).  We would have to respin hardware to allow = your heuristics implementation.  This might not be implementable = today, as hardware respins are costly and take relatively = long.

2) On low-end products, e.g. Access = (aka Edge) it is unlikely that today's and even tomorrow's = implementations will have stateful DPI implemented; these devices have = low target COGS and usually do not have simple packet filters and = stateless firewalls and signature-based DPI and IDS/IPS.  It is = unlikely that this would be the potential implementation target for = heuristics, as the cost/price would go up.

3) High-end products, e.g. Data Center = front-ends, would allow a heuristics implementation; it may have a = stateful firewall and/or IDS/IPS and other DPI capabilities, however = this class of devices is migrating towards virtualized platforms (major = vendors are moving in that direction), and they would be terminating = tens or even hundreds of thousands of SAs. 

4) Even if these high-end devices have = implementations running on multicores, everyone is struggling to provide = low latency and high throughput, squeezing the last possible bit through = of the pipe.  Keeping state until one finds that there is a match = or not may introduce unwanted latency and create large memory = consumption (multiply everything by e.g. 100K Sas) which we may not be = able to afford.

5) On these High-end appliances, there = is a definite need for load-balancing between flows.  That means = the amount of the required memory space will be at least 2x or 3x more, = and also there is need for additional CPU and I/O overhead to maintain = two or more loanbalancers in sync.

6) Another problem I see is that more = traffic today is carried on UDP, and those are inherently difficult to = track as "flows".  One must keep a significant portion of = traffic to determine ESP vs. ESP-NULL.  Years ago it was rare and = mostly used for implementations such as SNMP, but these days new = applications ar ecoming out (e.g. Bittorrent-over-UDP).  = SIP-over-UDP is another such implementation that may cause problems, if = heuristics are implemented in intermediate devices.

7) There will be stateful appliances in = the future, but stateless devices will remain in the future;  these = will not be able to perform heuristics as defined in the heuristics = draft.  They may have to be redeployed to other places in the = network, causing forklift replacements

8) Even by your own conclusion, = heuristics are not 100% accurate.  There are some "false = positives" and some "false negatives" = situations.

In summary, I find your draft to be = interesting, and I am looking forward to seeing it progress on = Informational track.  I believe also, that a deterministic approach = would be quicker and easier.  I suggest the "visibility" = draft remain on the WG Standards track as it is more = implementable.

_____________________________
Dragan Grebovich, = CISSP
Nortel = Networks
Enterprise = Communication Solutions
Product Development = Data Systems
Strategy and = Architecture - Security
(978) = 288-8069
Billerica, MA 01821 = U.S.A



------_=_NextPart_001_01C985AB.B4C9ACEC-- --===============0822920907== 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 --===============0822920907==-- From ipsec-bounces@ietf.org Mon Feb 2 22:20:51 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0963A6BF7; Mon, 2 Feb 2009 22:20:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074983A6BF7 for ; Mon, 2 Feb 2009 22:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAPs7kKM3zPt for ; Mon, 2 Feb 2009 22:20:49 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id C6AB43A6B04 for ; Mon, 2 Feb 2009 22:20:48 -0800 (PST) Received: by gxk14 with SMTP id 14so1501808gxk.13 for ; Mon, 02 Feb 2009 22:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y00QPNeLCTYa3SKBB9/JAWI+/dpC4VxhcpuCK6I6Hhk=; b=gHbO8FyVqGNpKxiSOqgjxZQ18FuRJy3aZjrK5M1SJECrMJk1w3Qg+V7ZygP1A23/nm XwPdzqv7TpljlSYBB5Uq136FHl5HtkTuX0fFnboc51+IRm7JGvacSQ68iGEFiNM0COpE S8mhkrLmU/2ta7vm1GuOz858OpgePu0kqlNSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xeixjEjCN58oiFX+VR3iKUpNEhId7PKh3NDgMVm5O512MkI12jmwFxLc9oRa2EI5DF LX5ppSZLxmlJmjRImuzX4bRXVm+Ojrv44/7sMN+7oW03INPR03Zmk0iIbXyLrj1VYdh4 vVkJKfjg1X3UNUCwa/DeSRepkrmNTu0Y1wVuw= MIME-Version: 1.0 Received: by 10.90.74.7 with SMTP id w7mr2618934aga.60.1233642026408; Mon, 02 Feb 2009 22:20:26 -0800 (PST) In-Reply-To: References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> Date: Tue, 3 Feb 2009 01:20:26 -0500 Message-ID: <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> From: Richard Graveman To: Vijay Devarapalli Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, Thanks for your reply. >> I just read this draft and think your idea is useful. I have one >> question (please excuse me if it's been answered): > > Its not been brought up before. But from the beginning the focus for > this draft has always been on IKEv2 client-gateway scenarios. > >> Is there anything special about VPNs (or MIPv6) that limits the use of >> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and >> "IKEv2 Responder" instead of "VPN Gateway" everywhere? > > The mechanism proposed in the draft can be used between any IKEv2 > initiator and responder without any changes to the protocol. Thanks for the clarification. I think this is worth saying. >> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could >> possibly benefit from this, but the terminology is somewhat >> constraining. > > If you don't mind, can you share those use-cases/scenarios with us? I > can't imagine a scenario where a re-direct would be useful between two > IKEv2 peers. Sure. My "client" and "server" happen to be running a peer-to-peer signaling protocol to handle GMPLS provisioning. It's a peer-to-peer protocol, because sometimes you "get a phone call" as well as "make a phone call." The "server" at the so-called Provider Edge (PE) has as natural an application of redirect as the remote-access-VPN case (planned downtime, load balancing, etc.) Regards, Rich Graveman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 02:15:36 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B513A6C1A; Tue, 3 Feb 2009 02:15:36 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B313A6C1A for ; Tue, 3 Feb 2009 02:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 F3QmH7ipg0v5 for ; Tue, 3 Feb 2009 02:15:34 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C622A3A6C15 for ; Tue, 3 Feb 2009 02:15:33 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CA5F829C005; Tue, 3 Feb 2009 12:15:13 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A8CDF29C002; Tue, 3 Feb 2009 12:15:12 +0200 (IST) X-CheckPoint: {49881648-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n13AFBei001524; Tue, 3 Feb 2009 12:15:12 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Feb 2009 12:15:11 +0200 From: Yoav Nir To: Dragan Grebovich , "ipsec@ietf.org" Date: Tue, 3 Feb 2009 12:15:37 +0200 Thread-Topic: draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQ Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.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] draft-kivinen-ipsecme-esp-null-heuristics 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="===============1506051083==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1506051083== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C78036130846B597ilex01adcheck_" --_000_9FB7C7CE79B84449B52622B506C78036130846B597ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dragan Grebovich wrote: Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable= , however: 1) I believe the actual implementation would require more code than current= front-end hardware allows. The hardware we work with have a limited space= for that much heuristics code. Our preference is to find a quick direct = match (in a few instructions max). We would have to respin hardware to all= ow your heuristics implementation. This might not be implementable today, = as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's = and even tomorrow's implementations will have stateful DPI implemented; the= se devices have low target COGS and usually do not have simple packet filte= rs and stateless firewalls and signature-based DPI and IDS/IPS. It is unli= kely that this would be the potential implementation target for heuristics,= as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics= implementation; it may have a stateful firewall and/or IDS/IPS and other D= PI capabilities, however this class of devices is migrating towards virtual= ized platforms (major vendors are moving in that direction), and they would= be terminating tens or even hundreds of thousands of SAs. 4) Even if these high-end devices have implementations running on multicore= s, everyone is struggling to provide low latency and high throughput, squee= zing the last possible bit through of the pipe. Keeping state until one fi= nds that there is a match or not may introduce unwanted latency and create = large memory consumption (multiply everything by e.g. 100K Sas) which we ma= y not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancin= g between flows. That means the amount of the required memory space will b= e at least 2x or 3x more, and also there is need for additional CPU and I/O= overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and = those are inherently difficult to track as "flows". One must keep a signif= icant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was r= are and mostly used for implementations such as SNMP, but these days new ap= plications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is anot= her such implementation that may cause problems, if heuristics are implemen= ted in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices w= ill remain in the future; these will not be able to perform heuristics as = defined in the heuristics draft. They may have to be redeployed to other p= laces in the network, causing forklift replacements 8) Even by your own conclusion, heuristics are not 100% accurate. There ar= e some "false positives" and some "false negatives" situations. In summary, I find your draft to be interesting, and I am looking forward t= o seeing it progress on Informational track. I believe also, that a determ= inistic approach would be quicker and easier. I suggest the "visibility" d= raft remain on the WG Standards track as it is more implementable. In previous discussions we've reached the conclusion that traffic visibilit= y matters only for a subset of the traffic, where your policy says two thin= gs: 1. You intend to do some kind of inspection on the protected payload (cou= ld be as shallow as checking ports or as deep as scanning the transported f= iles for malware) 2. You don't allow any ESP that isn't NULL, because then you won't be abl= e to inspect it. ESP non-NULL is dropped. Given that this is the kind of policy we're enforcing, you cannot really es= cape doing some inspection on the payload - you intend to do this anyway. E= ven if the packet was "tagged" as the visibility draft suggests, you would = still need to verify that the ESP is indeed NULL - you can't rely on a tag. So IMO it doesn't really matter how weak or powerful the edge device is, it= has to be powerful enough to inspect all ESP-NULL packets if it is to impl= ement such a policy. If it's not powerful enough, then it can't enforce suc= h a policy, and it doesn't really have to decide whether or not the ESP alg= orithm is NULL or not. In that case it doesn't have to implement any heuris= tics. Stateless devices are such a case. They shouldn't care whether or not= the traffic is ESP-NULL or not. As for heuristics not being 100% accurate, that is correct, but the chances= can be made arbitrarily small, and small enough that we are willing to liv= e with it. Yoav =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036130846B597ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments</TITL= E> <META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18241"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2 face=3DArial><SP= AN=20 class=3D043205709-03022009>Dragan Grebovich wrote:</SPAN></FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5p= x; MARGIN-RIGHT: 0px"> <DIV></DIV><!-- Converted from text/rtf format --> <P><FONT size=3D2 face=3DArial>Hi Tero</FONT> <BR><FONT size=3D2 face=3DA= rial>I=20 reviewed your heuristics draft and I believe it is interesting and doable= ,=20 however:</FONT> </P> <P><FONT size=3D2 face=3DArial>1) I believe the actual implementation wou= ld=20 require more code than current front-end hardware allows.  The hardw= are=20 we work with have a limited space for that much heuristics code. &nb= sp;=20 Our preference is to find a quick direct match (in a few instructions=20 max).  We would have to respin hardware to allow your heuristics=20 implementation.  This might not be implementable today, as hardware= =20 respins are costly and take relatively long.</FONT></P> <P><FONT size=3D2 face=3DArial>2) On low-end products, e.g. Access (aka E= dge) it=20 is unlikely that today's and even tomorrow's implementations will have=20 stateful DPI implemented; these devices have low target COGS and usually = do=20 not have simple packet filters and stateless firewalls and signature-base= d DPI=20 and IDS/IPS.  It is unlikely that this would be the potential=20 implementation target for heuristics, as the cost/price would go=20 up.</FONT></P> <P><FONT size=3D2 face=3DArial>3) High-end products, e.g. Data Center fro= nt-ends,=20 would allow a heuristics implementation; it may have a stateful firewall= =20 and/or IDS/IPS and other DPI capabilities, however this class of devices = is=20 migrating towards virtualized platforms (major vendors are moving in that= =20 direction), and they would be terminating tens or even hundreds of thousa= nds=20 of SAs.  </FONT></P> <P><FONT size=3D2 face=3DArial>4) Even if these high-end devices have=20 implementations running on multicores, everyone is struggling to provide = low=20 latency and high throughput, squeezing the last possible bit through of t= he=20 pipe.  Keeping state until one finds that there is a match or not ma= y=20 introduce unwanted latency and create large memory consumption (multiply= =20 everything by e.g. 100K Sas) which we may not be able to afford.</FONT></= P> <P><FONT size=3D2 face=3DArial>5) On these High-end appliances, there is = a=20 definite need for load-balancing between flows.  That means the amou= nt of=20 the required memory space will be at least 2x or 3x more, and also there = is=20 need for additional CPU and I/O overhead to maintain two or more loanbala= ncers=20 in sync.</FONT></P> <P><FONT size=3D2 face=3DArial>6) Another problem I see is that more traf= fic today=20 is carried on UDP, and those are inherently difficult to track as=20 "flows".  One must keep a significant portion of traffic to determin= e ESP=20 vs. ESP-NULL.  Years ago it was rare and mostly used for implementat= ions=20 such as SNMP, but these days new applications ar ecoming out (e.g.=20 Bittorrent-over-UDP).  SIP-over-UDP is another such implementation t= hat=20 may cause problems, if heuristics are implemented in intermediate=20 devices.</FONT></P> <P><FONT size=3D2 face=3DArial>7) There will be stateful appliances in th= e future,=20 but stateless devices will remain in the future;  these will not be = able=20 to perform heuristics as defined in the heuristics draft.  They may = have=20 to be redeployed to other places in the network, causing forklift=20 replacements</FONT></P> <P><FONT size=3D2 face=3DArial>8) Even by your own conclusion, heuristics= are not=20 100% accurate.  There are some "false positives" and some "false=20 negatives" situations.</FONT></P> <P><FONT face=3DArial><FONT size=3D2>In summary, I find your draft to be= =20 interesting, and I am looking forward to seeing it progress on Informatio= nal=20 track.  I believe also, that a deterministic approach would be quick= er=20 and easier.  I suggest the "visibility" draft remain on the WG Stand= ards=20 track as it is more implementable.<SPAN class=3D043205709-03022009><FONT= =20 color=3D#0000ff> </FONT></SPAN></FONT></FONT></P></BLOCKQUOTE> <P><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN class=3D04320570= 9-03022009>In=20 previous discussions we've reached the conclusion that traffic visibility=20 matters only for a subset of the traffic, where your policy says two=20 things:</SPAN></FONT></FONT></P> <OL> <LI><FONT face=3DArial><FONT size=3D2><SPAN class=3D043205709-03022009><F= ONT=20 color=3D#0000ff>You intend to do some kind of inspection on the protected= =20 payload</FONT> <FONT color=3D#0000ff>(could be as shallow as checkin= g ports=20 or as deep as scanning the transported files for=20 malware)</FONT></SPAN></FONT></FONT></LI> <LI><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009>You don't allow any ESP that isn't NULL, becau= se then=20 you won't be able to inspect it. ESP non-NULL is=20 dropped.</SPAN></FONT></FONT></LI></OL> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009>Given that this is the kind of policy we're enfo= rcing,=20 you cannot really escape doing some inspection on the payload - you intend = to do=20 this anyway. Even if the packet was "tagged" as the visibility draft sugges= ts,=20 you would still need to verify that the ESP is indeed NULL - you can't rely= =20 on a tag.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009>So IMO it doesn't really matter how weak or powe= rful=20 the edge device is, it has to be powerful enough to inspect all ESP-NULL pa= ckets=20 if it is to implement such a policy. If it's not powerful enough, then it c= an't=20 enforce such a policy, and it doesn't really have to decide whether or not = the=20 ESP algorithm is NULL or not. In that case it doesn't have to implement any= =20 heuristics. Stateless devices are such a case. They shouldn't care whether = or=20 not the traffic is ESP-NULL or not.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009>As for heuristics not being 100% accurate, that = is=20 correct, but the chances can be made arbitrarily small, and small enough th= at we=20 are willing to live with it.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20 class=3D043205709-03022009>Yoav</SPAN></FONT></FONT></DIV> <br>= =0D=0A <br>Email secured by Check Point=0D=0A <br> <br>= </BODY></HTML> --_000_9FB7C7CE79B84449B52622B506C78036130846B597ilex01adcheck_-- --===============1506051083== 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 --===============1506051083==-- From ipsec-bounces@ietf.org Tue Feb 3 03:32:59 2009 Return-Path: <ipsec-bounces@ietf.org> X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232AA3A6991; Tue, 3 Feb 2009 03:32:59 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96763A67B2 for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 03:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 M5yZzSdAzCzU for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 03:32:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 006D128C19A for <ipsec@ietf.org>; Tue, 3 Feb 2009 03:32:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n13BWDhZ027519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 13:32:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n13BWBCJ026504; Tue, 3 Feb 2009 13:32:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18824.11067.918325.672141@fireball.kivinen.iki.fi> Date: Tue, 3 Feb 2009 13:32:11 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Yaron Sheffer <yaronf@checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> References: <f1f4dcdc0812161619x676ef491j4bf9181732ba67cf@mail.gmail.com> <18760.62138.517458.691565@fireball.kivinen.iki.fi> <f1f4dcdc0812181701w61423389tddecfc26530aedc9@mail.gmail.com> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> <f1f4dcdc0902021105k7675f859w3e9f03b32c2d3313@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Vijay Devarapalli <dvijay@gmail.com> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols <ipsec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ipsec> List-Post: <mailto:ipsec@ietf.org> List-Help: <mailto:ipsec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=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: > Apologies for repeating myself. At the point when the client > receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's > going to receive a Redirect "right away". So the reasonable thing > for it to do is to tear down the IKE SA immediately - the SA has > just become useless. It should not tear down the IKE SA immediately, it should have short delay there before doing that. That kind of delay is also needed in case NO_ADDITIONAL_SAS is used for other reasons, as if that is not used, then client will busy loop creating new IKE_SA with IKE_SA_INIT, IKE_AUTH, INFORMATIONAL exchange deleting the IKE SA, and then starting immediately from the IKE_SA_INIT. If there is short timeout (10 seconds or so) between IKE_AUTH and the INFORMATIONAL exchange containing the delete payload deleting the IKE SA then this will not be busy loop doing Diffie-Hellman, but slower rate loop. The short timeout will also give server time to reply. Note, that server can send reply immediately it does not need to wait anything, i.e the INFORMATIONAL message telling client to redirect can be send just immediately after sending IKE_AUTH reply. Also client MUST still process incoming exchange while it is waiting for the reply to the its delete, thus it will most likely get the redirect message during that even if it issued delete immediately. > In other words, we have a race condition between this notification > (and the client's response to it) and the Redirect notification. And > the simple solution is to send both notifications together. Which means client code needs to understand that redirect notification can come also during the IKE_AUTH, and depending on the IKE_AUTH use of EAP, multiple auth etc things that requires modifications to the existing complicated code. So while adding support for the redirect in the client, it would be good also be quite easy thing to ensure it does not delete the IKE SA immediately, but wait for some time before deleting IKE SA. I really do not want to make the most complicated exchange (IKE_AUTH) even more complicated. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 05:12:50 2009 Return-Path: <ipsec-bounces@ietf.org> X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6846D3A6C2E; Tue, 3 Feb 2009 05:12:50 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FB03A6C22 for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 05:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VVK8fSYxIBN for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 05:12:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 17A563A69EC for <ipsec@ietf.org>; Tue, 3 Feb 2009 05:12:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n13DCOAV006880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 15:12:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n13DCNUP025156; Tue, 3 Feb 2009 15:12:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18824.17079.363126.331101@fireball.kivinen.iki.fi> Date: Tue, 3 Feb 2009 15:12:23 +0200 From: Tero Kivinen <kivinen@iki.fi> To: "Dragan Grebovich" <dragan@nortel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 98 min Cc: ipsec@ietf.org Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols <ipsec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ipsec> List-Post: <mailto:ipsec@ietf.org> List-Help: <mailto:ipsec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dragan Grebovich writes: > Hi Tero > I reviewed your heuristics draft and I believe it is interesting and > doable, however: > > 1) I believe the actual implementation would require more code than > current front-end hardware allows. The hardware we work with have a > limited space for that much heuristics code. Our preference is to find > a quick direct match (in a few instructions max). We would have to > respin hardware to allow your heuristics implementation. This might not > be implementable today, as hardware respins are costly and take > relatively long. In normal cases, I would expect that heuristics are not run on the hardware, only the SPI cache is run there (i.e. the Appendix A.1 part of the operations). This kind of processing is already run on the firewalls, deep inspection devices and so on, usually per TCP flow basis. Adding that to be run on per IPsec SA basis should be very small addition to the front-end hardware. Are you saying that even that is too complicated? > 2) On low-end products, e.g. Access (aka Edge) it is unlikely that > today's and even tomorrow's implementations will have stateful DPI > implemented; these devices have low target COGS and usually do not have > simple packet filters and stateless firewalls and signature-based DPI > and IDS/IPS. It is unlikely that this would be the potential > implementation target for heuristics, as the cost/price would go up. If they do not have "simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS", then they do not need heuristics at all, as there is no need to differentiate the ESP vs ESP-NULL. Heuristics solution do not require any changes to those low-end product. On the other hand the new protocol number for ESP most likely will require changes to those devices, as they need to be sure to pass that protocol number also. > 3) High-end products, e.g. Data Center front-ends, would allow a > heuristics implementation; it may have a stateful firewall and/or > IDS/IPS and other DPI capabilities, however this class of devices is > migrating towards virtualized platforms (major vendors are moving in > that direction), and they would be terminating tens or even hundreds of > thousands of SAs. Heuristics are not needed on the devices which are terminating IPsec SAs. Devices terminating IPsec SAs already know all IPsec SA state, thus they do not need heuristics. Heuristics is only needed on devices which do all the following: 1) Do want to some kind of deep inspection on the ESP-NULL packets. 2) Are on the path of the IPsec flow, but not participating in the IPsec SA (i.e. is not a node where IPsec SA terminates). Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP flows inside, thus for each entry added to the SPI cache, the TCP or UDP caches require much more. This means that high-end producsts need to have memory for storing hundreds of thousands or even millions of TCP/UDP flows anyways, and adding some for IPsec SA flows does not significantly increase the number (in the worst case scenario, where each IPsec SA has exactly one TCP flow inside, it might double the number of flows needed to be stored). > 4) Even if these high-end devices have implementations running on > multicores, everyone is struggling to provide low latency and high > throughput, squeezing the last possible bit through of the pipe. > Keeping state until one finds that there is a match or not may introduce > unwanted latency and create large memory consumption (multiply > everything by e.g. 100K Sas) which we may not be able to afford. During normal operation there is no increased latency or slow throughput, as the used IPsec SAs are already in the SPI flow cache, and the parameters are fetched from there. Even if there is hundreds of tousands of SAs, the rate of new IPsec SAs created per second is very low. I.e. if IPsec SAs has lifetime of 1 hour, that means that every second we create on average of ~30 new IPsec SA flows to keep up 100 000 IPsec SA flows running. Thus the actual heuristics processing only requires to process around that amount of flows. Of course during the monday morning problem the rate will be higher, but even so the heuristics is cheaper than the Diffie-Hellman required to actually create those IPsec SAs, so even low powered CPU should be able to easily to run heuristics on thousands or tens of thousands packets per second. After the heuristics is run then the processing is moved to the actual fast path which only inspects the IPsec SPI flow cache and the src/dst addresses and SPI number found from the packet. > 5) On these High-end appliances, there is a definite need for > load-balancing between flows. That means the amount of the required > memory space will be at least 2x or 3x more, and also there is need for > additional CPU and I/O overhead to maintain two or more loanbalancers in > sync. Heuristics can be run separetely on each devices without any problems, but the deep inspection usually cannot be run separetely. Thus I do not think deep inspection engines will be load balanced so that same flow can end up in multiple devices. Usually the load balancing there is done based on the IP addresses or similar, where they can guarantee that each flow ends to one specific node of the load balancing cluster. > 6) Another problem I see is that more traffic today is carried on UDP, > and those are inherently difficult to track as "flows". One must keep a > significant portion of traffic to determine ESP vs. ESP-NULL. Years ago > it was rare and mostly used for implementations such as SNMP, but these > days new applications ar ecoming out (e.g. Bittorrent-over-UDP). > SIP-over-UDP is another such implementation that may cause problems, if > heuristics are implemented in intermediate devices. As you said the UDP is hard to keep track, but heuristics does not NEED to keep track of UDP flows, it just need to find enough information in the beginning of the flow, to create the flow information for the ESP-NULL flow. After that it does not care what kind of UDP traffic go inside. The deep inspection device inspecting the traffic inside ESP-NULL flow, still need to keep track of UDP flows, but heuristics has already been done in that case. > 7) There will be stateful appliances in the future, but stateless > devices will remain in the future; these will not be able to perform > heuristics as defined in the heuristics draft. They may have to be > redeployed to other places in the network, causing forklift replacements Normal steteless devices do not need to do heuristics, as they do not do deep inspection or things that require looking in to the ESP-NULL packets. > 8) Even by your own conclusion, heuristics are not 100% accurate. There > are some "false positives" and some "false negatives" situations. Not sure what you mean by "false positives" or "false negatives", but as explained in the draft it can only make errors that valid ESP packet is detected as being ESP-NULL packet. It will never detect valid ESP-NULL packet as ESP packet. > In summary, I find your draft to be interesting, and I am looking > forward to seeing it progress on Informational track. I believe also, > that a deterministic approach would be quicker and easier. I suggest > the "visibility" draft remain on the WG Standards track as it is more > implementable. It might be easier, but it definately will not be quickier. Heuristics can also be implemented regardless of IKEv1 or IKEv2. Modifying the ESP will be IKEv2 only, thus it will require end nodes to start using that too. It seems that quite a lot of devices are still using already obsoleted IKEv1 still, even when IKEv2 has been out for 3 years... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 05:14:39 2009 Return-Path: <ipsec-bounces@ietf.org> X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031A33A6C2E; Tue, 3 Feb 2009 05:14:39 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2943A6C2E for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 05:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja2e7ofqS2PC for <ipsec@core3.amsl.com>; Tue, 3 Feb 2009 05:14:36 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B74E83A6C22 for <ipsec@ietf.org>; Tue, 3 Feb 2009 05:14:35 -0800 (PST) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n13DAEi08293 for <ipsec@ietf.org>; Tue, 3 Feb 2009 13:10:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 08:13:23 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuA= References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> From: "Dragan Grebovich" <dragan@nortel.com> To: "Yoav Nir" <ynir@checkpoint.com>, <ipsec@ietf.org> Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols <ipsec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ipsec> List-Post: <mailto:ipsec@ietf.org> List-Help: <mailto:ipsec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0189071132==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0189071132== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98601.32465C7B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98601.32465C7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yoav =20 I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. =20 =20 I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. =20 I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: =20 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). =20 =20 IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. =20 Dragan =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, February 03, 2009 5:16 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Hi Tero=20 I reviewed your heuristics draft and I believe it is interesting and doable, however:=20 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics code. Our preference is to find a quick direct match (in a few instructions max). We would have to respin hardware to allow your heuristics implementation. This might not be implementable today, as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS. It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs. =20 4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe. Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancing between flows. That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows". One must keep a significant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices will remain in the future; these will not be able to perform heuristics as defined in the heuristics draft. They may have to be redeployed to other places in the network, causing forklift replacements 8) Even by your own conclusion, heuristics are not 100% accurate. There are some "false positives" and some "false negatives" situations. In summary, I find your draft to be interesting, and I am looking forward to seeing it progress on Informational track. I believe also, that a deterministic approach would be quicker and easier. I suggest the "visibility" draft remain on the WG Standards track as it is more implementable.=20 In previous discussions we've reached the conclusion that traffic visibility matters only for a subset of the traffic, where your policy says two things: 1. You intend to do some kind of inspection on the protected payload (could be as shallow as checking ports or as deep as scanning the transported files for malware)=20 2. You don't allow any ESP that isn't NULL, because then you won't be able to inspect it. ESP non-NULL is dropped. Given that this is the kind of policy we're enforcing, you cannot really escape doing some inspection on the payload - you intend to do this anyway. Even if the packet was "tagged" as the visibility draft suggests, you would still need to verify that the ESP is indeed NULL - you can't rely on a tag. =20 So IMO it doesn't really matter how weak or powerful the edge device is, it has to be powerful enough to inspect all ESP-NULL packets if it is to implement such a policy. If it's not powerful enough, then it can't enforce such a policy, and it doesn't really have to decide whether or not the ESP algorithm is NULL or not. In that case it doesn't have to implement any heuristics. Stateless devices are such a case. They shouldn't care whether or not the traffic is ESP-NULL or not. =20 As for heuristics not being 100% accurate, that is correct, but the chances can be made arbitrarily small, and small enough that we are willing to live with it. =20 Yoav Email secured by Check Point=20 ------_=_NextPart_001_01C98601.32465C7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>draft-kivinen-ipsecme-esp-null-heuristics = comments
Yoav
 
I apologize for not being clearer = earlier.  I was=20 not suggesting any new/different policy enforcement.  =
 
I believe/agree that traffic visibility will = matter only to=20 a subset of traffic, but that is enforced at each appliance level, = or on a=20 more granular (per interface) level.  Not all devices have to be = capable of=20 doing it, however if they are tasked to do it, they have to be able to = scale and=20 perform transparently and quickly.  Therefore, if heuristics are turned on, all = traffic=20 will be subject to inspection (heuristic or deterministic), and = then=20 resource consumption matter.
 
I definitely concur that not all ESP traffic = will be NULL,=20 but I believe your statement actually supports my point.  When a = packet=20 hits a decision point, the following has to be determined=20 asap:
 
   1) Is the = packet terminated here or=20 am I to forward it?  Until now, forwarded packets were always = forwarded and=20 no action was performed on the content.  Now we may want to = turn on a=20 policy to inspect packet content which is not terminated=20 here.
   2) Can I do anything with it" (has = it=20 cleartext or IPSEC payload)?  If cleartext - it is trivial=20 ...
   3) Is it AH or ESP?  This is = quick and=20 trivial too ...
   4) If it is ESP, is it ESP-NULL or = full-ESP?=20 If it is full-ESP, I can't do anything with it - pass (preferrably) or = drop (if=20 policy insists, but I doubt someone would prevent IPSEC, you never = know). =20
 
IMHO for each packet we have to = perform the four=20 steps.  It is the implementation-specific choice whether it is = deterministic or heuristic inspection to make a = call.  I=20 need to make a call if it would take a few instructions or a chunk of = code,=20 potentially with some % of false-positives or false = negatives.  =20 Again, I agree with you it may be "tweaked" to be close to = 0%, however each=20 additional discrimination requires more code, more cpu and more time to = execute=20 (latency).  I am concerned that on large (high-end) devices this = may take=20 an unacceptably large toll.
 
Dragan
 

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent:=20 Tuesday, February 03, 2009 5:16 AM
To: Grebovich, Dragan = (BL60:SF00);=20 ipsec@ietf.org
Subject: Re: [IPsec]=20 draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:

Hi Tero
I=20 reviewed your heuristics draft and I believe it is interesting and = doable,=20 however:

1) I believe the actual implementation = would=20 require more code than current front-end hardware allows.  The = hardware=20 we work with have a limited space for that much heuristics = code.  =20 Our preference is to find a quick direct match (in a few instructions=20 max).  We would have to respin hardware to allow your heuristics=20 implementation.  This might not be implementable today, as = hardware=20 respins are costly and take relatively long.

2) On low-end products, e.g. Access = (aka Edge) it=20 is unlikely that today's and even tomorrow's implementations will have = stateful DPI implemented; these devices have low target COGS and = usually do=20 not have simple packet filters and stateless firewalls and = signature-based DPI=20 and IDS/IPS.  It is unlikely that this would be the potential=20 implementation target for heuristics, as the cost/price would go=20 up.

3) High-end products, e.g. Data Center = front-ends,=20 would allow a heuristics implementation; it may have a stateful = firewall=20 and/or IDS/IPS and other DPI capabilities, however this class of = devices is=20 migrating towards virtualized platforms (major vendors are moving in = that=20 direction), and they would be terminating tens or even hundreds of = thousands=20 of SAs. 

4) Even if these high-end devices have=20 implementations running on multicores, everyone is struggling to = provide low=20 latency and high throughput, squeezing the last possible bit through = of the=20 pipe.  Keeping state until one finds that there is a match or not = may=20 introduce unwanted latency and create large memory consumption = (multiply=20 everything by e.g. 100K Sas) which we may not be able to = afford.

5) On these High-end appliances, there = is a=20 definite need for load-balancing between flows.  That means the = amount of=20 the required memory space will be at least 2x or 3x more, and also = there is=20 need for additional CPU and I/O overhead to maintain two or more = loanbalancers=20 in sync.

6) Another problem I see is that more = traffic today=20 is carried on UDP, and those are inherently difficult to track as=20 "flows".  One must keep a significant portion of traffic to = determine ESP=20 vs. ESP-NULL.  Years ago it was rare and mostly used for = implementations=20 such as SNMP, but these days new applications ar ecoming out (e.g.=20 Bittorrent-over-UDP).  SIP-over-UDP is another such = implementation that=20 may cause problems, if heuristics are implemented in intermediate=20 devices.

7) There will be stateful appliances in = the future,=20 but stateless devices will remain in the future;  these will not = be able=20 to perform heuristics as defined in the heuristics draft.  They = may have=20 to be redeployed to other places in the network, causing forklift=20 replacements

8) Even by your own conclusion, = heuristics are not=20 100% accurate.  There are some "false positives" and some "false=20 negatives" situations.

In summary, I find your draft to = be=20 interesting, and I am looking forward to seeing it progress on = Informational=20 track.  I believe also, that a deterministic approach would be = quicker=20 and easier.  I suggest the "visibility" draft remain on the WG = Standards=20 track as it is more implementable. 

In=20 previous discussions we've reached the conclusion that traffic = visibility=20 matters only for a subset of the traffic, where your policy says two=20 things:

  1. You intend to do some kind of inspection on the = protected=20 payload (could be as shallow as = checking ports=20 or as deep as scanning the transported files for=20 malware)=20
  2. You don't allow any ESP that isn't NULL, = because then=20 you won't be able to inspect it. ESP non-NULL is=20 dropped.
Given that this is the kind of policy we're = enforcing,=20 you cannot really escape doing some inspection on the payload - you = intend to do=20 this anyway. Even if the packet was "tagged" as the visibility draft = suggests,=20 you would still need to verify that the ESP is indeed NULL - you can't = rely=20 on a tag.
 
So IMO it doesn't really matter how weak or = powerful=20 the edge device is, it has to be powerful enough to inspect all ESP-NULL = packets=20 if it is to implement such a policy. If it's not powerful enough, then = it can't=20 enforce such a policy, and it doesn't really have to decide whether or = not the=20 ESP algorithm is NULL or not. In that case it doesn't have to implement = any=20 heuristics. Stateless devices are such a case. They shouldn't care = whether or=20 not the traffic is ESP-NULL or not.
 
As for heuristics not being 100% accurate, = that is=20 correct, but the chances can be made arbitrarily small, and small enough = that we=20 are willing to live with it.
 
Yoav


Email = secured by=20 Check Point

------_=_NextPart_001_01C98601.32465C7B-- --===============0189071132== 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 --===============0189071132==-- From ipsec-bounces@ietf.org Tue Feb 3 07:57:26 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA8E28C121; Tue, 3 Feb 2009 07:57:26 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF303A6C44 for ; Tue, 3 Feb 2009 07:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 NhIFxogmJ3G5 for ; Tue, 3 Feb 2009 07:57:24 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 4F5633A6C3B for ; Tue, 3 Feb 2009 07:57:24 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1923352rvf.49 for ; Tue, 03 Feb 2009 07:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yEPOzX0BzX43Mx/iQYojzROT3IQy3B2KP0tB8lZrkVI=; b=U2O6UUklc7eh8Az1IG5mp/+TtslgBg2ihETg6Cr/fG3Al5Z8wFF3YpBGc+Bqe2g98Y g5/vfCSp3z7dG+kAdYDX2EMtjfO5cJMyhYKYmg5Xlmop6SCCJsZR4jTs0/Eo/JELFjk8 N35XObQq7zo/Vv6fIivKaCgjesDJWjaslANNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x0cb52gVWqzwWwnFJdfD2RZYzfUEFszeTOHJ54TSxd1wn327FcRqdoKI6ztnmJvSH2 VGZ15VdwNawQbplJ6x3a+tTkMnUVDNQYfxB2YBVy3Nv7g69h0eP4AQ0Yg7jZuo66Cq0u M1w3PnztZJ193gbTNB+YEs2VR7H+fwBCQCrlA= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr2422922wfe.181.1233676624399; Tue, 03 Feb 2009 07:57:04 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> Date: Tue, 3 Feb 2009 07:57:04 -0800 Message-ID: From: Vijay Devarapalli To: Yaron Sheffer Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, On Mon, Feb 2, 2009 at 1:26 PM, Yaron Sheffer wrote: > Hi Vijay, > > Apologies for repeating myself. At the point when the client receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's going to receive a Redirect "right away". So the reasonable thing for it to do is to tear down the IKE SA immediately - the SA has just become useless. Even if the client decides to tear down the IKE SA, it sends a INFORMATIONAL message with the DELETE payload to the gateway. > > In other words, we have a race condition between this notification (and the client's response to it) and the Redirect notification. And the simple solution is to send both notifications together. The REDIRECT from the gateway to the client will come either before or along with the response to the DELETE payload. Vijay > > Thanks, > Yaron > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:dvijay@gmail.com] >> Sent: Monday, February 02, 2009 21:06 >> To: Yaron Sheffer >> Cc: Tero Kivinen; ipsec@ietf.org >> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH >> >> Hi Yaron, >> >> On Sun, Dec 21, 2008 at 3:58 AM, Yaron Sheffer >> wrote: >> > Hi Vijay, Tero, >> > >> > Now the real issue: I suggest that we reconsider the solution we're >> > proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is >> > left with an IKE SA which is basically useless. So the client will >> naturally >> > fail the entire connection attempt. With the current proposal we are >> asking >> > the client to *guess* that the gateway wants to redirect it somewhere >> else, >> > and to wait (for an indefinite time) for that redirect notification to >> > arrive. If the Redirect never arrives, we just have a useless timeout. >> >> First, the client does not have to wait for an indefinite amount of >> time. The gateway sends a REDIRECT message right away. The REDIRECT >> message is re-transmitted until an ack is received from the client. So >> I don't think the above is an issue. >> >> Back to the basic question. What do we want to achieve when the >> gateway decides the re-direct the client in the middle of an IKE_AUTH >> exchange? We want to be able to prevent the client from creating an >> CHILD_SA that is worthless. We want to be able to prevent the client >> from sending any traffic. Both are achieve by sending >> NO_ADDITIONAL_SAS in the IKE_AUTH response. >> >> The IKE SA has already been created. There is nothing that needs to be >> done about. The subsequent REDIRECT payload from the gateway to the >> client would say the IKE SA to be deleted anyway. Therefore I suggest >> going with NO_ADDITIONAL_SAS payload during the IKE_AUTH exchange, >> followed by the REDIRECT message from the gateway. >> >> Vijay >> >> >> >> >> > >> > In other words, I propose to go back to Fan's proposal of an explicit >> > Redirect notify in IKE_AUTH, so that the client knows for sure what type >> of >> > failure it is seeing. >> > >> > Thanks, and Happy Holidays! >> > >> > Yaron >> > >> >> -----Original Message----- >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >> >> Tero Kivinen >> >> Sent: Friday, December 19, 2008 12:24 >> >> To: Vijay Devarapalli >> >> Cc: ipsec@ietf.org; Yoav Nir >> >> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH >> >> >> >> Vijay Devarapalli writes: >> >> > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH >> >> > response followed by the re-direct message. >> >> >> >> Good. >> >> >> >> > However, I think we need a clarification in IKEv2bis draft. It would >> >> > be very easy for someone to interpret that the NO_ADDITIONAL_SAS >> >> > payload can only be used to reject a CREATE_CHILD_SA request and not >> >> > the IKE_AUTH request (because thats what the text in RFC 4306 says.) >> >> > and implement accordingly. >> >> >> >> Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS >> >> text in the draft to indicate those can be also sent during imbedded >> >> Child SA creation hapening in the IKE_AUTH. >> >> >> >> This would mean that we dofollowing changes: >> >> ---------------------------------------------------------------------- >> >> In section "1.2. The Initial Exchanges" change >> >> >> >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH >> exchange >> >> fails for some reason, the IKE SA is still created as usual. The >> >> list of responses in the IKE_AUTH exchange that do not prevent an >> IKE >> >> SA from being set up include at least the following: >> >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, >> >> INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. >> >> >> >> to (i.e add NO_ADDITIONAL_SAS to the example list) >> >> >> >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH >> exchange >> >> fails for some reason, the IKE SA is still created as usual. The >> >> list of responses in the IKE_AUTH exchange that do not prevent an >> IKE >> >> SA from being set up include at least the following: >> >> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, >> >> INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS. >> >> ---------------------------------------------------------------------- >> >> In section "1.3. The CREATE_CHILD_SA Exchange" change >> >> >> >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification >> >> to indicate that a CREATE_CHILD_SA request is unacceptable because >> >> the responder is unwilling to accept any more Child SAs on this IKE >> >> SA. Some minimal implementations may only accept a single Child SA >> >> setup in the context of an initial IKE exchange and reject any >> >> subsequent attempts to add more. >> >> >> >> to (explained the situation for minimal clients here already described >> >> in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH >> >> and explained what it means): >> >> >> >> {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS >> >> notification to indicate that a child SA creation request is >> >> unacceptable because the responder is unwilling to accept any more >> >> Child SAs on this IKE SA (either because implementation limitations >> >> or because of policy reasons). Some minimal implementations may >> >> only accept a single Child SA setup in the context of an initial >> >> IKE exchange and reject any subsequent attempts to add more. If >> >> this error message is received it means it is not useful to try to >> >> create more Child SAs with this IKE SA, because all of them will >> >> fail with this error. If this error is received during >> >> CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA >> >> and create new IKE SA with new Child SA if it wants to get the new >> >> Child SA created. If this error is received during initial Child SA >> >> creation in IKE_AUTH that means the Child SA creation was rejected >> >> either because of policy reasons or resource constraint reasons, >> >> and there is no point of retrying Child SA creation immediately. >> >> Instead the recipient should wait for suitable timeout (several >> >> minutes) to see if server either deletes the IKE SA or indicates >> >> that situation has changed (for example creates Child SA himself). >> >> After the timeout expires the client should delete the IKE SA and >> >> try again. >> >> ---------------------------------------------------------------------- >> >> In section "2.9. Traffic Selector Negotiation" change >> >> >> >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a >> >> CREATE_CHILD_SA request is unacceptable because its sender is only >> >> willing to accept traffic selectors specifying a single pair of >> >> addresses. The requestor is expected to respond by requesting an SA >> >> for only the specific traffic it is trying to forward. >> >> >> >> to (replace CREATE_CHILD_SA with "Child SA creation" >> >> >> >> {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a >> >> Child SA creation request is unacceptable because its sender is >> >> only willing to accept traffic selectors specifying a single pair >> >> of addresses. The requestor is expected to respond by requesting an >> >> SA for only the specific traffic it is trying to forward. >> >> -- >> >> kivinen@iki.fi >> >> _______________________________________________ >> >> IPsec mailing list >> >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> Scanned by Check Point Total Security Gateway. >> > >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. > > Email secured by Check Point > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 08:28:06 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E7F28C128; Tue, 3 Feb 2009 08:28:06 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB2328C128 for ; Tue, 3 Feb 2009 08:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL37X5oJOokB for ; Tue, 3 Feb 2009 08:28:03 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by core3.amsl.com (Postfix) with ESMTP id C235C28C0E3 for ; Tue, 3 Feb 2009 08:28:03 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j66so1400184rne.18 for ; Tue, 03 Feb 2009 08:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OP5+B17W7HqXIR7R5wIQTA2dDAicg4485owPQrVhllA=; b=jdo1zNt45/pO9tQpOijL1S+rkQS4avcyRq8ZDivOYI76jVWVjLzp7IE6h3nDPV19an iuUqK/vNXHsGhZduiTXtM9HXPNd7AB700lrpyAk7yivo1dKQTVifv8DQ8xDiYphAnXBK 8/X0uRC8YEqg663f6oFIk02m4UnwDciWCZr3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rGzZi2NW2Ezl0q1xg1oLuEdGzLXPOYHgc+dUVdvh363ggif/OHwqPTlpoVWwf4J9xl 9tgNcxZzw4GRVs928A7A8RrV6hLFg/x90l5Xh40vwlfrW0qvWaKqw1GA7z+GKuVwnvOP 51oB0QHR0yQkgaD83c/KO4FZ5I8ouOXj/2q48= MIME-Version: 1.0 Received: by 10.142.14.18 with SMTP id 18mr1288304wfn.35.1233678463145; Tue, 03 Feb 2009 08:27:43 -0800 (PST) In-Reply-To: <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> Date: Tue, 3 Feb 2009 08:27:43 -0800 Message-ID: From: Vijay Devarapalli To: Richard Graveman Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman wrote: >>> I just read this draft and think your idea is useful. I have one >>> question (please excuse me if it's been answered): >> >> Its not been brought up before. But from the beginning the focus for >> this draft has always been on IKEv2 client-gateway scenarios. >> >>> Is there anything special about VPNs (or MIPv6) that limits the use of >>> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and >>> "IKEv2 Responder" instead of "VPN Gateway" everywhere? >> >> The mechanism proposed in the draft can be used between any IKEv2 >> initiator and responder without any changes to the protocol. > > Thanks for the clarification. I think this is worth saying. I added the following to the Introduction section. The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers. The IKEv2 responder can re- direct the initiator to another responder with no changes to the mechanism described in this document. Is this sufficient? Vijay > >>> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could >>> possibly benefit from this, but the terminology is somewhat >>> constraining. >> >> If you don't mind, can you share those use-cases/scenarios with us? I >> can't imagine a scenario where a re-direct would be useful between two >> IKEv2 peers. > > Sure. My "client" and "server" happen to be running a peer-to-peer > signaling protocol to handle GMPLS provisioning. It's a peer-to-peer > protocol, because sometimes you "get a phone call" as well as "make a > phone call." The "server" at the so-called Provider Edge (PE) has as > natural an application of redirect as the remote-access-VPN case > (planned downtime, load balancing, etc.) > > Regards, Rich Graveman > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 09:07:07 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF9E28C237; Tue, 3 Feb 2009 09:07:07 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA83728C237 for ; Tue, 3 Feb 2009 09:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tprOKh11mw+w for ; Tue, 3 Feb 2009 09:07:06 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id 1E0F828C1C9 for ; Tue, 3 Feb 2009 09:07:06 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so1352071ele.13 for ; Tue, 03 Feb 2009 09:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0gAYzlh80nIf2IEBLoGJPUOh+UmEx02v8HLlk7holYI=; b=QiG9HbnjmlyruJgzFS9oD1PRPz8RT/oxDFyiYCWh9bxbRMf1+DKxdkMmm8jOHrfGyX YCkD1a+ogIZ9X/z9DOulFxbxVTiABlsF60dwVcJCjOFa7uTtzAeWApFZyxUJSAJ76uMj GxdSZBEL5pJSZXJ8W/JsvkKNB2x/GBLaB1/zA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R5Lu70WdM0gXBCTo9K+CDygEdQtw1Nnv/jmFIrpOdfzrcgHPd4bp74W+poqnqA0qSr yX33tzV7AYkgTS+d75jGAUeuaRMMdwWRsDexzvFsikjvq1rMr7K0h7P/l9mEnfFX4jJ5 GVimLF92m396NRr4+jOGS7Gk7CziiVggR2auM= MIME-Version: 1.0 Received: by 10.90.98.13 with SMTP id v13mr456095agb.112.1233680805580; Tue, 03 Feb 2009 09:06:45 -0800 (PST) In-Reply-To: References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> Date: Tue, 3 Feb 2009 12:06:45 -0500 Message-ID: <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> From: Richard Graveman To: Vijay Devarapalli Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org 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. Your text is fine. The point was raised that we may not want both parties redirecting at once. In your use cases, is it always the IKEv2 responder that would redirect? Rich On Tue, Feb 3, 2009 at 11:27 AM, Vijay Devarapalli wrote: > Hi, > > On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman wrote: > >>>> I just read this draft and think your idea is useful. I have one >>>> question (please excuse me if it's been answered): >>> >>> Its not been brought up before. But from the beginning the focus for >>> this draft has always been on IKEv2 client-gateway scenarios. >>> >>>> Is there anything special about VPNs (or MIPv6) that limits the use of >>>> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and >>>> "IKEv2 Responder" instead of "VPN Gateway" everywhere? >>> >>> The mechanism proposed in the draft can be used between any IKEv2 >>> initiator and responder without any changes to the protocol. >> >> Thanks for the clarification. I think this is worth saying. > > I added the following to the Introduction section. > > The Re-direct mechanism described in this document is mainly intended > for use in client-gateway scenarios. However, the mechanism can also > be used between any two IKEv2 peers. The IKEv2 responder can re- > direct the initiator to another responder with no changes to the > mechanism described in this document. > > Is this sufficient? > > Vijay > > >> >>>> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could >>>> possibly benefit from this, but the terminology is somewhat >>>> constraining. >>> >>> If you don't mind, can you share those use-cases/scenarios with us? I >>> can't imagine a scenario where a re-direct would be useful between two >>> IKEv2 peers. >> >> Sure. My "client" and "server" happen to be running a peer-to-peer >> signaling protocol to handle GMPLS provisioning. It's a peer-to-peer >> protocol, because sometimes you "get a phone call" as well as "make a >> phone call." The "server" at the so-called Provider Edge (PE) has as >> natural an application of redirect as the remote-access-VPN case >> (planned downtime, load balancing, etc.) >> >> Regards, Rich Graveman >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 09:36:18 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7D53A6C44; Tue, 3 Feb 2009 09:36:18 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EE73A6C44 for ; Tue, 3 Feb 2009 09:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qmEFg7yK2nj for ; Tue, 3 Feb 2009 09:36:16 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id EAB2A3A6B96 for ; Tue, 3 Feb 2009 09:36:15 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so936452fgb.41 for ; Tue, 03 Feb 2009 09:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=HTn2Tydg8vS18pYmMPx2rIk1W+cf0+XdAmTMQauzgFE=; b=FJPCPZq2KILGgPTIZJNLX8QK/1Dkb/bt7Wk6fqGckHLUql7Z8nRybtzJ/bgIbqeys0 xgnEvQCtGw2AyxwSCSrZJICHnv+hG3B0c95IcMBk05SHc/gGByemSfd4jOY28VNBZK03 lHwy83hUj2cG7123hUeJzrr8pgr5Qvuz6NAQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=H5Zh1gbDyKqGjEAIEr4pd4KVvDsO6cx/rsAOvDR0oy1xg7+QydHnKR/aCa8kRmlQ4A nd/npcM+ujnXPEPZSnKxVAyhcL8rzm235jVHMcVdDlB0M4z/evYEZKqzl4QzEFi5jbHl yeL0p6/CUFDAVuX3K1hy1w+WgIFnHuF02Y/iE= MIME-Version: 1.0 Received: by 10.86.59.2 with SMTP id h2mr5743fga.30.1233682554421; Tue, 03 Feb 2009 09:35:54 -0800 (PST) Date: Tue, 3 Feb 2009 18:35:54 +0100 Message-ID: <729b68be0902030935g39daeb27i6ab2e2d00221808b@mail.gmail.com> From: Jean-Michel Combes To: IPsec WG Subject: [IPsec] [draft-ietf-ipsecme-roadmap-00] Comments about references X-BeenThere: ipsec@ietf.org 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, as promised during the interim meeting, here are comments about references: o IPSECKEY implementation IPSECKEY RR has been implemented here: http://www.idsa.prd.fr/index.php?page=code&lang=en and included in BIND after (cf. https://www.isc.org/about/pr/2007032700). o PANA and IPsec AFAIK, it was decided in Dublin meeting that PANA WG has to work again on PANA based IPsec bootstrapping (http://tools.ietf.org/html/draft-ietf-pana-ipsec-07) but, as I didn't attend Minneapolis meeting, I don't know whether this is still the case ... o Pfr+ use Pfr+ is used in RFC 5295 (cf. section 3.1.2). Hope that helps. Best regards. JMC. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 10:38:29 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736E43A6806; Tue, 3 Feb 2009 10:38:29 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51EF3A6806 for ; Tue, 3 Feb 2009 10:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 ywmhd3DEHpEB for ; Tue, 3 Feb 2009 10:38:27 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 9DD263A67FD for ; Tue, 3 Feb 2009 10:38:27 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2386190wfd.31 for ; Tue, 03 Feb 2009 10:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WaLkge9R4Z5DJdCgVL1DmuB8e3jUKthRB0+1YxhlkVo=; b=dFURkRplfUR3yZD4DkGmIBk5KO6SVqQ2r40HNdbRaXQK04ES0/0lAXAAfY6ZFXmfbw ybEo26rlOEWtpj04ycgE2w0GzftyK4ZLC2lWel+T0UMbOz3nFcxiHafIjbuLRiYPVcuh 4e/W5/nFHOo/LcEkUKssVRKzTrvJkvFNh4fAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B0r5Zk1dK9Y262itYx1UdmnBRnv8uaBlsT6T4pb2p0Xjm0J/hlGAb2No2vVc/G0tyg GZ01IwC1SPj1vdaIrGL2HdbrFQ074yFrQ0TMjAKY6cJ81s4ciJK+yE87ySd3U1e+m2Pc QLx/9Q31zasWvVOFfD7mmb357d4dT7unZiSNY= MIME-Version: 1.0 Received: by 10.142.125.9 with SMTP id x9mr2481083wfc.38.1233686287260; Tue, 03 Feb 2009 10:38:07 -0800 (PST) In-Reply-To: References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F986@il-ex01.ad.checkpoint.com> Date: Tue, 3 Feb 2009 10:38:07 -0800 Message-ID: From: Vijay Devarapalli To: Yaron Sheffer , Tero Kivinen , Yoav Nir Cc: "ipsec@ietf.org" Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, Here is the proposed text for re-direct during IKE_AUTH exchange. If the gateway decides to re-direct the client during the IKE_AUTH exchange, it prevents the creation of a CHILD SA by sending the NO_ADDITIONAL_SAS Notify Payload in the IKE_AUTH response. It then follows up with an INFORMATIONAL message with the REDIRECT payload immediately. The following shows the message exchange between the client and the gateway. Initiator Responder ( VPN GW) --------- ------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_SUPPORTED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> When the client receives the IKE_AUTH response with the NO_ADDITIONAL_SAS payload from the gateway, it may decide to delete the IKEv2 SA. In case the gateway receives the INFORMATIONAL message to delete the IKEv2 SA before sending the REDIRECT message, then the gateway includes the REDIRECT payload in the response along with the DELETE payload. Feel free to modify the text. A temporary pre04 version is at http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2-redirect-04.txt Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 3 10:54:36 2009 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4823B3A6C51; Tue, 3 Feb 2009 10:54:36 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106A53A6C51 for ; Tue, 3 Feb 2009 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 WhXjj36N0Lgt for ; Tue, 3 Feb 2009 10:54:34 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9A27C3A67FD for ; Tue, 3 Feb 2009 10:54:33 -0800 (PST) Received: from [10.20.30.158] (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 n13Is8En030596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 11:54:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <729b68be0902030935g39daeb27i6ab2e2d00221808b@mail.gmail.com> References: <729b68be0902030935g39daeb27i6ab2e2d00221808b@mail.gmail.com> Date: Tue, 3 Feb 2009 10:54:07 -0800 To: Jean-Michel Combes , IPsec WG From: Paul Hoffman Subject: Re: [IPsec] [draft-ietf-ipsecme-roadmap-00] Comments about references X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 6:35 PM +0100 2/3/09, Jean-Michel Combes wrote: >Hi, > >as promised during the interim meeting, here are comments about references: > >o IPSECKEY implementation > >IPSECKEY RR has been implemented here: >http://www.idsa.prd.fr/index.php?page=code&lang=en > >and included in BIND after (cf. https://www.isc.org/about/pr/2007032700). This seems good enough for listing RFC 4025 in the roadmap. >o PANA and IPsec > >AFAIK, it was decided in Dublin meeting that PANA WG has to work again >on PANA based IPsec bootstrapping >(http://tools.ietf.org/html/draft-ietf-pana-ipsec-07) but, as I didn't >attend Minneapolis meeting, I don't know whether this is still the >case ... We should wait for this to stabilize. >o Pfr+ use > >Pfr+ is used in RFC 5295 (cf. section 3.1.2). As I said on the call, it seems like overkill to list docs that have picked up our PRFs. That's not reall IPsec. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From dvijay@gmail.com Tue Feb 3 13:46:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD843A6BF0 for ; Tue, 3 Feb 2009 13:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFW4Gp+cntz4 for ; Tue, 3 Feb 2009 13:46:52 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 0D9A73A6904 for ; Tue, 3 Feb 2009 13:46:26 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1238294ana.4 for ; Tue, 03 Feb 2009 13:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p+SDg95GxSzEJgdpfqSdjEjNE0TpoRUHlIzD7oao0vk=; b=JZMq50f9eO6hfNronKSs7vNITFP5FpcbfNdfhZzsLTbk6bUwfdyEujrDwKKjIrJVfG B40O3naMRCzyx3ilR3yv62jDUH93092kyb6qgZ+23TRu7foNrh3txEJdw9STqAjPJvs+ zecNSdPsQ1Tg23ZgJ+nN5r2lL7phzEcVEj3x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IMwYdtiIAloNJTmanu+iU8WvVv5y9LyBg7nJrBoylAcSZpd+74dhrEFi53D6Llq4Uo bKfUV9y7L7PnXsQkS8SM5MJuMkX+Ww0pI81ODTisXAmFgFjqscWZxnPUlMhdFLNzp8MD KLJ5pYV807bT6uJBKydDQSWdkOcRg3wsPcMLI= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr1083783wfe.55.1233697565830; Tue, 03 Feb 2009 13:46:05 -0800 (PST) In-Reply-To: <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> Date: Tue, 3 Feb 2009 13:46:05 -0800 Message-ID: From: Vijay Devarapalli To: Richard Graveman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:46:53 -0000 Hi, On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman wrote: > Thanks. Your text is fine. The point was raised that we may not want > both parties redirecting at once. In your use cases, is it always the > IKEv2 responder that would redirect? Yes. It is always the responder in the client-gateway scenarios. Vijay > > Rich > > On Tue, Feb 3, 2009 at 11:27 AM, Vijay Devarapalli wrote: >> Hi, >> >> On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman wrote: >> >>>>> I just read this draft and think your idea is useful. I have one >>>>> question (please excuse me if it's been answered): >>>> >>>> Its not been brought up before. But from the beginning the focus for >>>> this draft has always been on IKEv2 client-gateway scenarios. >>>> >>>>> Is there anything special about VPNs (or MIPv6) that limits the use of >>>>> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and >>>>> "IKEv2 Responder" instead of "VPN Gateway" everywhere? >>>> >>>> The mechanism proposed in the draft can be used between any IKEv2 >>>> initiator and responder without any changes to the protocol. >>> >>> Thanks for the clarification. I think this is worth saying. >> >> I added the following to the Introduction section. >> >> The Re-direct mechanism described in this document is mainly intended >> for use in client-gateway scenarios. However, the mechanism can also >> be used between any two IKEv2 peers. The IKEv2 responder can re- >> direct the initiator to another responder with no changes to the >> mechanism described in this document. >> >> Is this sufficient? >> >> Vijay >> >> >>> >>>>> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could >>>>> possibly benefit from this, but the terminology is somewhat >>>>> constraining. >>>> >>>> If you don't mind, can you share those use-cases/scenarios with us? I >>>> can't imagine a scenario where a re-direct would be useful between two >>>> IKEv2 peers. >>> >>> Sure. My "client" and "server" happen to be running a peer-to-peer >>> signaling protocol to handle GMPLS provisioning. It's a peer-to-peer >>> protocol, because sometimes you "get a phone call" as well as "make a >>> phone call." The "server" at the so-called Provider Edge (PE) has as >>> natural an application of redirect as the remote-access-VPN case >>> (planned downtime, load balancing, etc.) >>> >>> Regards, Rich Graveman >>> >> > From rfgraveman@gmail.com Tue Feb 3 14:45:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D13A6A4C for ; Tue, 3 Feb 2009 14:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6kFdygU--b9 for ; Tue, 3 Feb 2009 14:45:40 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 82C4C3A6A30 for ; Tue, 3 Feb 2009 14:45:40 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2024728yxg.49 for ; Tue, 03 Feb 2009 14:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=etXA4FVifPr5JY4bXQYCWlOMf1OmNFuJ5mv2e0Yqts8=; b=D00giFQbbCqqrOh+rlN+p39ZV2XfUoUCm4h0DFEpABJeJ7vc/UXwrK6RgpTYmc200C oQJQ7J4kw7DpJ7NBwbUJbZ8kwRXlOOedzH8QGoCiMmD67FgdIoqoEN8S0gPpjhfT8wPM MZSrun7TiU836rU1HyuyK2cVyUUsr59GLsdPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NxSJEAq0gp6e5q2/Z2EVv/MazExWLVEibNT0oKKq/vLa5hAcqj78Sc/o/cWpt0u363 ulhE1hhuO9/OenJj2a9jyLmlHl0JSEwM87IVv7jnImtvtp+o/XkUwpv1E5bLfoNhKmEw cywMSLMoIt2m/TDOYJwT66+i6JUtodsqUNShg= MIME-Version: 1.0 Received: by 10.90.71.16 with SMTP id t16mr275437aga.8.1233701120262; Tue, 03 Feb 2009 14:45:20 -0800 (PST) In-Reply-To: References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> Date: Tue, 3 Feb 2009 17:45:20 -0500 Message-ID: <45c8c21a0902031445y234f0227u652d4bcc261675cd@mail.gmail.com> From: Richard Graveman To: Vijay Devarapalli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:45:41 -0000 Hi, > On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman wrote: >> Thanks. Your text is fine. The point was raised that we may not want >> both parties redirecting at once. In your use cases, is it always the >> IKEv2 responder that would redirect? > > Yes. It is always the responder in the client-gateway scenarios. Then, perhaps consider: "If a responder wants to redirect and receives a redirect request from the initiator, ignore the initiator's request. [The idea is that if this causes the initiator to fail, well then, initiate again.] Regards, Rich From dvijay@gmail.com Tue Feb 3 16:59:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925203A688E for ; Tue, 3 Feb 2009 16:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 7efHBWZlTdpB for ; Tue, 3 Feb 2009 16:59:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 7CB2E3A67DB for ; Tue, 3 Feb 2009 16:59:07 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2553229wfd.31 for ; Tue, 03 Feb 2009 16:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h732wDz1DE/FKbPqicgmknClG0uXoH2VYpt4wJW4CZI=; b=cAeDL4071081DjoLhiYRHErPy9zgDFyhH3eH4Fgs1/wBoeWFe1GYfpd8JhGBQTAqAL WHtwwEjl4u8qq0H41OT7wHFUlXYwhAS92c3Bj+TuwycsQWsHjplOmx22cUpYmpYXhJtN ZKAHwiZD5u3TeELNPc7kRI9rDYHOh+BvXmy0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VRLEVZEwglltBbTJK5EhkDUqwgKauskwJ3e6mnKO1ovkeihpBkSprWeC/F2O9nyLyn mcXYtRnJvUIY0u/XxDNReSy49uoDrRxKyO0elvRdNgCf+2TTvKD3J9SlX2628ABihWsM lRYHR7g3b9UNQQfqBQ38XdmfiE+knagiR5mec= MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr2604854wfe.317.1233709127565; Tue, 03 Feb 2009 16:58:47 -0800 (PST) In-Reply-To: <45c8c21a0902031445y234f0227u652d4bcc261675cd@mail.gmail.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> <45c8c21a0902031445y234f0227u652d4bcc261675cd@mail.gmail.com> Date: Tue, 3 Feb 2009 16:58:47 -0800 Message-ID: From: Vijay Devarapalli To: Richard Graveman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 00:59:08 -0000 Hello, On Tue, Feb 3, 2009 at 2:45 PM, Richard Graveman wrote: > Hi, > >> On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman wrote: >>> Thanks. Your text is fine. The point was raised that we may not want >>> both parties redirecting at once. In your use cases, is it always the >>> IKEv2 responder that would redirect? >> >> Yes. It is always the responder in the client-gateway scenarios. > > Then, perhaps consider: "If a responder wants to redirect and receives > a redirect request from the initiator, ignore > the initiator's request. [The idea is that if this causes the > initiator to fail, well then, initiate again.] I created a new section in the draft, since it was getting complicated. :) Here is the text. 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers. This is especially useful for IKEv2 sessions between two gateway peer routers. When used between a client and gateway, the re-direct procedure is always initiated by the gateway. But when used between two IKEv2 peers, either of the IKEv2 end points can initiate the re-direct message. In order to prevent any race condition that might occur if both decide to re-direct at the same time, the responder MUST not respond to re-direct message from the initiator, if it has already decided to re-direct the initiator. A temporary pre04 version of the draft is at http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2-redirect-04.txt Vijay From paul.hoffman@vpnc.org Tue Feb 3 17:50:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FE03A6903 for ; Tue, 3 Feb 2009 17:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 tnwiY1-+8zph for ; Tue, 3 Feb 2009 17:50:40 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 268173A63D3 for ; Tue, 3 Feb 2009 17:50:39 -0800 (PST) Received: from [10.20.30.158] (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 n141oFTg051231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Feb 2009 18:50:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 3 Feb 2009 17:50:14 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Recording of today's interim WG 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: , X-List-Received-Date: Wed, 04 Feb 2009 01:50:41 -0000 ... is available at ; it's about 30 megabytes (2 hours). Yaron and I will have minutes from the meeting in a while. We will leave the slides from the meeting up at --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Wed Feb 4 00:03:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D983A6B65 for ; Wed, 4 Feb 2009 00:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 VFcAPaxlZpeK for ; Wed, 4 Feb 2009 00:03:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 079DD3A6991 for ; Wed, 4 Feb 2009 00:03:25 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B4E1A29C005; Wed, 4 Feb 2009 10:03:05 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0E6A929C002; Wed, 4 Feb 2009 10:03:04 +0200 (IST) X-CheckPoint: {498948C7-10001-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n14833ei023073; Wed, 4 Feb 2009 10:03:03 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 4 Feb 2009 10:03:03 +0200 From: Yoav Nir To: Dragan Grebovich , "ipsec@ietf.org" Date: Wed, 4 Feb 2009 10:03:32 +0200 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcA== Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C78036130846B6BCilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Wed, 04 Feb 2009 08:03:28 -0000 --_000_9FB7C7CE79B84449B52622B506C78036130846B6BCilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/di= fferent policy enforcement. I believe/agree that traffic visibility will matter only to a subset of tra= ffic, but that is enforced at each appliance level, or on a more granular (= per interface) level. Not all devices have to be capable of doing it, howe= ver if they are tasked to do it, they have to be able to scale and perform = transparently and quickly. Therefore, if heuristics are turned on, all tra= ffic will be subject to inspection (heuristic or deterministic), and then r= esource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe yo= ur statement actually supports my point. When a packet hits a decision poi= nt, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forw= arded packets were always forwarded and no action was performed on the cont= ent. Now we may want to turn on a policy to inspect packet content which i= s not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If c= leartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't = do anything with it - pass (preferrably) or drop (if policy insists, but I = doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implemen= tation-specific choice whether it is deterministic or heuristic inspection = to make a call. I need to make a call if it would take a few instructions = or a chunk of code, potentially with some % of false-positives or false neg= atives. Again, I agree with you it may be "tweaked" to be close to 0%, ho= wever each additional discrimination requires more code, more cpu and more = time to execute (latency). I am concerned that on large (high-end) devices= this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don= 't agree with what you wrote in #4. If the appliance is willing to pass ESP= -non-NULL, then it doesn't really care about content inspection. That is fi= ne, and probably the more common case, but in that case it shouldn't care w= hether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things = it doesn't understand, such as non-NULL ESP and possibly SSL (they might ma= ke an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular ins= pection 3. Is the process ESP with an SPI and endpoints that have already determi= ned to be NULL?: If so, skip to the payload and inspect. Note that this is = a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL,= and then after the heuristics marked it as OK, begin encryption. This "att= ack" will work if all your policy says is "ESP must be NULL". But that is n= ot an interesting policy. Real policies will require deeper inspection of t= he internal flows, so the cost of the heuristics becomes negligible, as it = only requires looking at the first few packets of each ESP SA. =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036130846B6BCilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments</TITL= E> <META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18241"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT color=3D#0000ff><FONT= =20 size=3D2>Dragan Grebovich wrote:</FONT></FONT></FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5p= x; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>Yoav</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>I apologize for not being clearer earlier.&nbs= p; I was=20 not suggesting any new/different policy enforcement. =20 </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>I believe/agree that traffic visibility will matter= only to=20 a subset of traffic, but that is enforced at each appliance level, or&nbs= p;on=20 a more granular (per interface) level.  Not all devices have to be=20 capable of doing it, however if they are tasked to do it, they have to be= able=20 to scale and perform transparently and quickly.  </FONT></SPAN><SPAN= =20 class=3D281042812-03022009><FONT color=3D#0000ff size=3D2=20 face=3DArial>T</FONT></SPAN><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial>herefore, if heuristics are turned on, all tra= ffic will=20 be subject to inspection (heuristic or deterministic), and then reso= urce=20 consumption matter.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>I definitely concur that not all ESP traffic will be NULL, b= ut I=20 believe your statement actually supports my point.  When a packet hi= ts a=20 decision point, the following has to be determined=20 asap:</FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial></FONT></SPAN></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>   1) Is the packet terminated here or a= m I to=20 forward it?  Until now, forwarded packets were always forwarded and = no=20 action was performed on the content.  Now we may want to turn o= n a=20 policy to inspect packet content which is not terminated=20 here.</FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>   2) Can I do anything with it" (has it cleartext= or=20 IPSEC payload)?  If cleartext - it is trivial=20 ...</FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>   3) Is it AH or ESP?  This is quick and tri= vial=20 too ...</FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>   4) If it is ESP, is it ESP-NULL or full-ESP? If= it is=20 full-ESP, I can't do anything with it - pass (preferrably) or drop (if po= licy=20 insists, but I doubt someone would prevent IPSEC, you never know). = =20 </FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial></FONT></SPAN></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D281042812-03022009><FONT color= =3D#0000ff=20 size=3D2 face=3DArial><SPAN class=3D281042812-03022009><FONT color=3D#000= 0ff size=3D2=20 face=3DArial>IMHO for each packet we have to perform the four steps.=  =20 It is the implementation-specific choice whether it is deterministic= =20 or heuristic inspection to make a call.  I need to ma= ke a=20 call if it would take a few instructions or a chunk of code, potentially = with=20 some % of false-positives or false negatives.   Again, I agree = with=20 you it may be "tweaked" to be close to 0%, however each additional=20 discrimination requires more code, more cpu and more time to execute=20 (latency).  I am concerned that on large (high-end) devices this may= take=20 an unacceptably large toll.</FONT></SPAN></FONT></SPAN></DIV> <DIV><FONT color=3D#0000ff size=3D2 face=3DArial></FONT> </DIV> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#0= 000ff><FONT=20 size=3D2>Dragan<SPAN=20 class=3D481014807-04022009> </SPAN></FONT></FONT></FONT></SPAN></DIV= ></BLOCKQUOTE> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>I don't think the use case is to = inspect=20 every packet like that. I also don't agree with what you wrote in #4. = If=20 the appliance is willing to pass ESP-non-NULL, then it doesn't really care = about=20 content inspection. That is fine, and probably the more common case, but in= that=20 case it shouldn't care whether a packet is or is not=20 encrypted.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN=20 class=3D481014807-04022009></SPAN></FONT></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Our use case is an edge device th= at=20 inspects all traffic, and drops things it doesn't understand, such as non-N= ULL=20 ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM= =20 attack against the SSL)</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN=20 class=3D481014807-04022009></SPAN></FONT></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>So for each packet, the processin= g=20 is something like this:</SPAN></FONT></FONT></FONT></SPAN></DIV> <OL> <LI><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#00= 00ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Is the protocol non-IPsec?= if=20 so, do the regular inspection</SPAN></FONT></FONT></FONT></SPAN></LI= > <LI><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#00= 00ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Is the protocol AH? if so, &nbs= p;skip to=20 the payload and do the regular=20 inspection</SPAN></FONT></FONT></FONT></SPAN></LI> <LI><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#00= 00ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Is the process ESP with an SPI = and=20 endpoints that have already determined to be NULL?: If so, skip to the pa= yload=20 and inspect. Note that this is a simple table=20 lookup</SPAN></FONT></FONT></FONT></SPAN></LI> <LI><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#00= 00ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Is this a new ESP SA? Do the he= uristics,=20 and then mark it in the table</SPAN></FONT></FONT></FONT></SPAN></LI></OL= > <DIV><SPAN class=3D281042812-03022009><FONT face=3DArial><FONT color=3D#000= 0ff><FONT=20 size=3D2><SPAN class=3D481014807-04022009>Of course it's possible for the e= ndpoints=20 to cheat, start of with ESP-NULL, and then after the heuristics marked it a= s OK,=20 begin encryption. This "attack" will work if all your policy says is "ESP m= ust=20 be NULL". But that is not an interesting policy. Real policies will require= =20 deeper inspection of the internal flows, so the cost of the heuristics beco= mes=20 negligible, as it only requires looking at the first few packets of each ES= P=20 SA.</SPAN></FONT></FONT></FONT></SPAN></DIV> <br>= =0D=0A <br>Email secured by Check Point=0D=0A <br> <br>= </BODY></HTML> --_000_9FB7C7CE79B84449B52622B506C78036130846B6BCilex01adcheck_-- From ken.grewal@intel.com Wed Feb 4 09:41:40 2009 Return-Path: <ken.grewal@intel.com> X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD0928C271 for <ipsec@core3.amsl.com>; Wed, 4 Feb 2009 09:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX7kZOM2yJeK for <ipsec@core3.amsl.com>; Wed, 4 Feb 2009 09:41:38 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id B00CC28C26F for <ipsec@ietf.org>; Wed, 4 Feb 2009 09:41:38 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 04 Feb 2009 09:35:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,380,1231142400"; d="scan'208";a="428110537" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga002.fm.intel.com with ESMTP; 04 Feb 2009 09:37:34 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Wed, 4 Feb 2009 10:41:19 -0700 From: "Grewal, Ken" <ken.grewal@intel.com> To: Tero Kivinen <kivinen@iki.fi>, Dragan Grebovich <dragan@nortel.com> Date: Wed, 4 Feb 2009 10:40:48 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmGASqBRNBMlLBHQF+QWYocTFFRqAANBn3Q Message-ID: <C49B4B6450D9AA48AB99694D2EB0A4830CDF22E0@rrsmsx505.amr.corp.intel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> In-Reply-To: <18824.17079.363126.331101@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" <ipsec@ietf.org> Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols <ipsec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ipsec> List-Post: <mailto:ipsec@ietf.org> List-Help: <mailto:ipsec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 Feb 2009 17:41:40 -0000 Some comments inline... Thanks,=20 Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Tero Kivinen >Sent: Tuesday, February 03, 2009 5:12 AM >To: Dragan Grebovich >Cc: ipsec@ietf.org >Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > >Dragan Grebovich writes: >> Hi Tero >> I reviewed your heuristics draft and I believe it is interesting and >> doable, however: >> >> 1) I believe the actual implementation would require more code than >> current front-end hardware allows. The hardware we work with have a >> limited space for that much heuristics code. Our preference is to find >> a quick direct match (in a few instructions max). We would have to >> respin hardware to allow your heuristics implementation. This might not >> be implementable today, as hardware respins are costly and take >> relatively long. > >In normal cases, I would expect that heuristics are not run on the >hardware, only the SPI cache is run there (i.e. the Appendix A.1 part >of the operations). This kind of processing is already run on the >firewalls, deep inspection devices and so on, usually per TCP flow >basis. Adding that to be run on per IPsec SA basis should be very >small addition to the front-end hardware. > >Are you saying that even that is too complicated? Complexity is one thing, but there is a cost vector to consider too and the= answer may be different based on the device being targeted.=20 Some devices may be capable of doing the heuristics processing in SW as an = exception case, whereas other devices (e.g. requiring high bandwidth DPI) n= eed to do this in HW to maintain line rates.=20 >From a cost perspective, If a device is stateless in nature (e.g. traffic m= onitoring/logging for auditing purposes), then that device will now need to= be stateful to maintain all these (potentially hundreds of thousands) or 3= -tuples as state, which may not be practical.=20 Cost also reflects expensive SRAM to store these cached policies, which may= be pennies, but in a low end NIC can be a cost-inhibitive to implement.=20 > >> 2) On low-end products, e.g. Access (aka Edge) it is unlikely that >> today's and even tomorrow's implementations will have stateful DPI >> implemented; these devices have low target COGS and usually do not have >> simple packet filters and stateless firewalls and signature-based DPI >> and IDS/IPS. It is unlikely that this would be the potential >> implementation target for heuristics, as the cost/price would go up. > >If they do not have "simple packet filters and stateless firewalls and >signature-based DPI and IDS/IPS", then they do not need heuristics at >all, as there is no need to differentiate the ESP vs ESP-NULL. > >Heuristics solution do not require any changes to those low-end >product. On the other hand the new protocol number for ESP most likely >will require changes to those devices, as they need to be sure to pass >that protocol number also. Any addition of a new protocol will require changes to any device that does= not support that protocol, so this argument is not unique to WESP, but app= licable to all new protocols - e.g. how would these devices act when seeing= the recently introduced HIP protocol or UDP-Lite? If we use this argument = that a new protocol addition will impact legacy devices, we should not be a= llocating ANY new protocols - full stop! Also see previous argument for low end devices above. > >> 3) High-end products, e.g. Data Center front-ends, would allow a >> heuristics implementation; it may have a stateful firewall and/or >> IDS/IPS and other DPI capabilities, however this class of devices is >> migrating towards virtualized platforms (major vendors are moving in >> that direction), and they would be terminating tens or even hundreds of >> thousands of SAs. > >Heuristics are not needed on the devices which are terminating IPsec >SAs. Devices terminating IPsec SAs already know all IPsec SA state, >thus they do not need heuristics. > >Heuristics is only needed on devices which do all the following: > >1) Do want to some kind of deep inspection on the ESP-NULL packets. > >2) Are on the path of the IPsec flow, but not participating in the > IPsec SA (i.e. is not a node where IPsec SA terminates). > Agreed - any device terminating the SA has all the info it needs already. >Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP >flows inside, thus for each entry added to the SPI cache, the TCP or >UDP caches require much more.=20 This is typically true for VPN/Tunneling, but not true for transport mode, = E2E solutions, where an IPsec SA will be as granular as the traffic it is c= arrying (e.g. TCP port 123 to TCP port 456 between two endpoints). This wil= l result in a 1:1 correlation between a flow and an SA, hence the number of= SAs can and will be in the 10s and 100s of thousands, especially at interm= ediate nodes in the network.=20 >This means that high-end producsts need >to have memory for storing hundreds of thousands or even millions of >TCP/UDP flows anyways, and adding some for IPsec SA flows does not >significantly increase the number (in the worst case scenario, where >each IPsec SA has exactly one TCP flow inside, it might double the >number of flows needed to be stored). Agree with the last part for doubling the state, BUT this additional state = may be in the HW (e.g. dedicated SRAM on the NIC, instead of DRAM accessibl= e by the DPI inference engines), so even though the state doubles, the cost= associated with where that state is kept goes up by a larger factor (cost = of SRAM is many times the cost of DRAM). =20 > >> 4) Even if these high-end devices have implementations running on >> multicores, everyone is struggling to provide low latency and high >> throughput, squeezing the last possible bit through of the pipe. >> Keeping state until one finds that there is a match or not may introduce >> unwanted latency and create large memory consumption (multiply >> everything by e.g. 100K Sas) which we may not be able to afford. > >During normal operation there is no increased latency or slow >throughput, as the used IPsec SAs are already in the SPI flow cache, >and the parameters are fetched from there. > >Even if there is hundreds of tousands of SAs, the rate of new IPsec >SAs created per second is very low. I.e. if IPsec SAs has lifetime of >1 hour, that means that every second we create on average of ~30 new >IPsec SA flows to keep up 100 000 IPsec SA flows running. Thus the >actual heuristics processing only requires to process around that >amount of flows. The SA lifetimes will be dependent on policy and the type of traffic undern= eath. Again, we are talking transport mode and transient traffic - I connec= t to a server to retrieve some data and then move on with something else - = the life of the connection may be a few minutes or even seconds. How about = VOIP calls protected by IPsec? The usage model is securing traffic for all = connection using transport more IPsec and the typical connections from the = client to server are short lived, mixed in with a small percentage of long = lived connections - e.g. you may be connected to a resource continuously du= ring a given work day (check your email, Open channel IM with a colleague d= uring a meeting, keep an eye on the every decreasing stock price in order t= o decide when to empty your mattress and buy!, and so on...) Which brings up another important point... Cache eviction - how will this work? We can keep adding SAs (based on heuristics), but how do we decide when a g= iven SA is no longer needed? This compounds the issues with keeping state, = as in the best case, cache eviction will likely be policy based. How is the= policy determined and how do we differentiate between short and long lived= SAs? As the SA cache will be of a finite size, this WILL lead to a cache t= hrash (add SA, evict SA, ...), causing further resource consumption. > >Of course during the monday morning problem the rate will be higher, >but even so the heuristics is cheaper than the Diffie-Hellman required >to actually create those IPsec SAs, so even low powered CPU should be >able to easily to run heuristics on thousands or tens of thousands >packets per second. > >After the heuristics is run then the processing is moved to the actual >fast path which only inspects the IPsec SPI flow cache and the src/dst >addresses and SPI number found from the packet. How about dynamic route changes for already established SAs? The same probl= em will exist as the Monday morning problem, but without the diffie-hellman= overhead. Because we are caching state on one device, a change in route wh= ere the packets take a different path will force the new device to 'relearn= ' all the cached info.=20 > >> 5) On these High-end appliances, there is a definite need for >> load-balancing between flows. That means the amount of the required >> memory space will be at least 2x or 3x more, and also there is need for >> additional CPU and I/O overhead to maintain two or more loanbalancers in >> sync. > >Heuristics can be run separetely on each devices without any problems, >but the deep inspection usually cannot be run separetely. Thus I do >not think deep inspection engines will be load balanced so that same >flow can end up in multiple devices. Usually the load balancing there >is done based on the IP addresses or similar, where they can guarantee >that each flow ends to one specific node of the load balancing >cluster. It may also be desirable to load balance based on ports. E.g. traffic flowi= ng between two domains with a NAT may see a lot of flows with the same src/= dest IPs, so disambiguating by ports is the next step. High availability is another one to consider, especially during maintenance= periods. One device is powered down and a backup device takes over. This i= s similar to route changes in principle, where the backup device will need = to relearn all the state.=20 > >> 6) Another problem I see is that more traffic today is carried on UDP, >> and those are inherently difficult to track as "flows". One must keep a >> significant portion of traffic to determine ESP vs. ESP-NULL. Years ago >> it was rare and mostly used for implementations such as SNMP, but these >> days new applications ar ecoming out (e.g. Bittorrent-over-UDP). >> SIP-over-UDP is another such implementation that may cause problems, if >> heuristics are implemented in intermediate devices. > >As you said the UDP is hard to keep track, but heuristics does not >NEED to keep track of UDP flows, it just need to find enough >information in the beginning of the flow, to create the flow >information for the ESP-NULL flow. After that it does not care what >kind of UDP traffic go inside. The deep inspection device inspecting >the traffic inside ESP-NULL flow, still need to keep track of UDP >flows, but heuristics has already been done in that case. Agree, but the heuristics engine may be heavily used as VOIP becomes preval= ent, especially within the Enterprise. Lots and lots of UDP traffic that is= short lived, which ties back to earlier points on cache maintenance and fr= equency of exercising the heuristics engine.=20 > >> 7) There will be stateful appliances in the future, but stateless >> devices will remain in the future; these will not be able to perform >> heuristics as defined in the heuristics draft. They may have to be >> redeployed to other places in the network, causing forklift replacements > >Normal steteless devices do not need to do heuristics, as they do not >do deep inspection or things that require looking in to the ESP-NULL >packets. Auditing / logging / sniffing / sampling are some examples of stateless dev= ices that do require to peek in the packets. Probably lots more also, so lo= ok for others to provide examples... > >> 8) Even by your own conclusion, heuristics are not 100% accurate. There >> are some "false positives" and some "false negatives" situations. > >Not sure what you mean by "false positives" or "false negatives", but >as explained in the draft it can only make errors that valid ESP >packet is detected as being ESP-NULL packet. It will never detect >valid ESP-NULL packet as ESP packet. > >> In summary, I find your draft to be interesting, and I am looking >> forward to seeing it progress on Informational track. I believe also, >> that a deterministic approach would be quicker and easier. I suggest >> the "visibility" draft remain on the WG Standards track as it is more >> implementable. > >It might be easier, but it definately will not be quickier.=20 The speed of deployment may or may not be true. If the stars are aligned, t= hen it could be deployed within one or two refresh cycles, which is about t= he same for heuristics in intermediaries devices. After all, only a handful= of vendors own a large percentage of the market for OS / intermediary devi= ces. Adoption is obviously based on customer pull/perceived usefulness. > Heuristics >can also be implemented regardless of IKEv1 or IKEv2. Modifying the >ESP will be IKEv2 only, thus it will require end nodes to start using >that too. It seems that quite a lot of devices are still using already >obsoleted IKEv1 still, even when IKEv2 has been out for 3 years... >-- This point is somewhat moot, as we are trying to address a new use case for= ubiquitous transport mode IPsec, which is not the case today. It is a new = use case, so if people want it, they will use the correct version of IKE.=20 In fact, the same argument is true for all the other changes we are putting= into IKE under the different charter items... From ken.grewal@intel.com Wed Feb 4 10:26:30 2009 Return-Path: <ken.grewal@intel.com> X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DDB3A6954 for <ipsec@core3.amsl.com>; Wed, 4 Feb 2009 10:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebAkT01w3jGo for <ipsec@core3.amsl.com>; Wed, 4 Feb 2009 10:26:20 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 84A0E28C1BB for <ipsec@ietf.org>; Wed, 4 Feb 2009 10:26:20 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 04 Feb 2009 10:21:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,380,1231142400"; d="scan'208,217";a="383937144" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga002.jf.intel.com with ESMTP; 04 Feb 2009 10:34:57 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Wed, 4 Feb 2009 11:25:58 -0700 From: "Grewal, Ken" <ken.grewal@intel.com> To: Yoav Nir <ynir@checkpoint.com>, Dragan Grebovich <dragan@nortel.com>, "ipsec@ietf.org" <ipsec@ietf.org> Date: Wed, 4 Feb 2009 11:25:27 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcAAVKchA Message-ID: <C49B4B6450D9AA48AB99694D2EB0A4830CDF23BA@rrsmsx505.amr.corp.intel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF23BArrsmsx505amrcor_" MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols <ipsec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ipsec> List-Post: <mailto:ipsec@ietf.org> List-Help: <mailto:ipsec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 Feb 2009 18:26:30 -0000 --_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF23BArrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Quote ... "Our use case is an edge device that inspects all traffic, and drops things= it doesn't understand, such as non-NULL ESP and possibly SSL (they might m= ake an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, dr= op ESP-encrypted), as traffic patterns will be mixed in reality (encrypted = Vs. clear) and policy will dictate how a given traffic stream in inspected = and if it is opaque then take the associated action (drop / bypass / apply = QOS rules / send a different path in the network / etc...). e.g. There may = be a secure channel to transfer highly sensitive data (e.g. payroll, compan= y secrets, etc.) which should be encrypted and it may be undesirable to cat= egorize this under a general rule - this is a simple extension of the firew= all function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a= later stage uses ESP-Encrypted may also be possible unintentionally. E.g. = Connection to a server (cluster / farm) to gain access to a 'normal' servic= e uses ESP-NULL and then at a later stage, where the previous connection wa= s torn down and a new one built, the connection is obtaining some sensitive= data and is now using ESP-Encrypted. On the outside, the connection attrib= utes look the same (same server IP, same client IP (but may be different cl= ient due to NAT), same SPI - SPIs can be reused for new connections to pres= erve fast lookups algorithms at recipients), but underneath the connection = is to access a different resource (may be using a different port or service= above the IP layer). If the intermediate device has a cached rule (based o= n the previous connection) indicating the traffic is clear, it will lead to= falsely inferring the contents of the payload and undesirable results. Thi= s goes to my point on cache eviction policy for heuristics based intermedia= te devices, as highlighted in a separate thread. Reuse of the same 'tuple' = with different traffic characteristics may be infrequent, but still plausib= le. I agree with Yoav that this attack may also be possible intentionally betwe= en two colluding parties, where the policy indicates all traffic is ESP-NUL= L. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/di= fferent policy enforcement. I believe/agree that traffic visibility will matter only to a subset of tra= ffic, but that is enforced at each appliance level, or on a more granular (= per interface) level. Not all devices have to be capable of doing it, howe= ver if they are tasked to do it, they have to be able to scale and perform = transparently and quickly. Therefore, if heuristics are turned on, all tra= ffic will be subject to inspection (heuristic or deterministic), and then r= esource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe yo= ur statement actually supports my point. When a packet hits a decision poi= nt, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forw= arded packets were always forwarded and no action was performed on the cont= ent. Now we may want to turn on a policy to inspect packet content which i= s not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If c= leartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't = do anything with it - pass (preferrably) or drop (if policy insists, but I = doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implemen= tation-specific choice whether it is deterministic or heuristic inspection = to make a call. I need to make a call if it would take a few instructions = or a chunk of code, potentially with some % of false-positives or false neg= atives. Again, I agree with you it may be "tweaked" to be close to 0%, ho= wever each additional discrimination requires more code, more cpu and more = time to execute (latency). I am concerned that on large (high-end) devices= this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don= 't agree with what you wrote in #4. If the appliance is willing to pass ESP= -non-NULL, then it doesn't really care about content inspection. That is fi= ne, and probably the more common case, but in that case it shouldn't care w= hether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things = it doesn't understand, such as non-NULL ESP and possibly SSL (they might ma= ke an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular ins= pection 3. Is the process ESP with an SPI and endpoints that have already determi= ned to be NULL?: If so, skip to the payload and inspect. Note that this is = a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL,= and then after the heuristics marked it as OK, begin encryption. This "att= ack" will work if all your policy says is "ESP must be NULL". But that is n= ot an interesting policy. Real policies will require deeper inspection of t= he internal flows, so the cost of the heuristics becomes negligible, as it = only requires looking at the first few packets of each ESP SA. Email secured by Check Point --_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF23BArrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>draft-kivinen-ipsecme-esp-null-heuristics comments

Quote …=

“Our use case is an edge device that inspects all traffic, and d= rops things it doesn't understand, such as non-NULL ESP and possibly SSL (they m= ight make an exception for HTTPS, but do a MiTM attack against the SSL)

”

I do not think a typical policy will b= e black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns w= ill be mixed in reality (encrypted Vs. clear) and policy will dictate how a giv= en traffic stream in inspected and if it is opaque then take the associated ac= tion (drop / bypass / apply QOS rules / send a different path in the network / e= tc…). e.g. There may be a secure channel to transfer highly sensitive data (e.g. = payroll, company secrets, etc.) which should be encrypted and it may be undesirable = to categorize this under a general rule – this is a simple extension of = the firewall function.

 

The ‘bait and switch’ atta= ck where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypt= ed may also be possible unintentionally. E.g. Connection to a server (cluster = / farm) to gain access to a ‘normal’ service uses ESP-NULL and th= en at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (sam= e server IP, same client IP (but may be different client due to NAT), same SPI ̵= 1; SPIs can be reused for new connections to preserve fast lookups algorithms = at recipients), but underneath the connection is to access a different resource (may be usi= ng a different port or service above the IP layer). If the intermediate device h= as a cached rule (based on the previous connection) indicating the traffic is cl= ear, it will lead to falsely inferring the contents of the payload and undesirab= le results. This goes to my point on cache eviction policy for heuristics base= d intermediate devices, as highlighted in a separate thread. Reuse of the sam= e ‘tuple’ with different traffic characteristics may be infrequent, but still plausib= le.

 

I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the pol= icy indicates all traffic is ESP-NULL.

 

<= span style=3D'font-size:12.0pt;color:navy'>Thanks,

<= span style=3D'font-size:12.0pt;color:navy'>- Ken

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, February 04= , 2009 12:04 AM
To: Dragan Grebovich; ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Dragan Grebovich wrote:

Yoav

 

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement.&n= bsp;

 

I believe/agree that traffic visibilit= y will matter only to a subset of traffic, but that is enforced at each appli= ance level, or on a more granular (per interface) level.  Not all devi= ces have to be capable of doing it, however if they are tasked to do it, they h= ave to be able to scale and perform transparently and quickly.  Therefore,= if heuristics are turned on, all traffic will be subject to inspecti= on (heuristic or deterministic), and then resource consumption matter.

 

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following h= as to be determined asap:

 

   1) Is the packet terminated here or am I to forward it?  Until now, forward= ed packets were always forwarded and no action was performed on the content.&n= bsp; Now we may want to turn on a policy to inspect packet content which is= not terminated here.

   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...

   3) Is it AH or ESP?  This is quick and trivial too ...

   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 

 

IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection t= o make a call.  I need to make a call if it would take a few instru= ctions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked"= ; to be close to 0%, however each additional discrimination requires more c= ode, more cpu and more time to execute (latency).  I am concerned that on l= arge (high-end) devices this may take an unacceptably large toll.

 

Dragan <= /p>

I don't think the use case is to inspe= ct every packet like that. I also don't agree with what you wrote in #4. = If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, = but in that case it shouldn't care whether a packet is or is not encrypted.

 

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-N= ULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

 

So for each packet, the processing is something like this:

  1. Is the pr= otocol non-IPsec? if so, do the regular inspection
  2. Is the protoco= l AH? if so,  skip to the payload and do the regular inspection<= /font>
  3. Is the process= ESP with an SPI and endpoints that have already determined to be NULL?: If= so, skip to the payload and inspect. Note that this is a simple table look= up
  4. Is this a new = ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoi= nts to cheat, start of with ESP-NULL, and then after the heuristics marked it a= s OK, begin encryption. This "attack" will work if all your policy = says is "ESP must be NULL". But that is not an interesting policy. Rea= l policies will require deeper inspection of the internal flows, so the cost = of the heuristics becomes negligible, as it only requires looking at the first= few packets of each ESP SA.



Email secured by Check Point

--_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF23BArrsmsx505amrcor_-- From DRAGAN@nortel.com Wed Feb 4 11:24:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD6B28C12A for ; Wed, 4 Feb 2009 11:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYB64ndGqiqu for ; Wed, 4 Feb 2009 11:24:57 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DE76128C102 for ; Wed, 4 Feb 2009 11:24:56 -0800 (PST) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n14JOYS11159 for ; Wed, 4 Feb 2009 19:24:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C986FE.2DFDEDBC" Date: Wed, 4 Feb 2009 14:24:20 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4187A850F@zrtphxm2.corp.nortel.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcAAXIbjA References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> From: "Dragan Grebovich" To: "Yoav Nir" , Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Wed, 04 Feb 2009 19:24:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C986FE.2DFDEDBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav =20 As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI. That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower). Who am I to tell a Checkpoint guy about both implementations? :-) =20 I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache. Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow.=20 =20 I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. =20 =20 Also, DPI can be used for more than just AV or packet content snooping. It could be used for QoS to determine more granular traffic shaping and application-level routing. There is also LI/CALEA aspect but I will leave that alone for now. =20 =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav =20 I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. =20 =20 I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. =20 I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: =20 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). =20 =20 IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. =20 Dragan=20 I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. =20 Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) =20 So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection=20 2. Is the protocol AH? if so, skip to the payload and do the regular inspection=20 3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup=20 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA. Email secured by Check Point=20 ------_=_NextPart_001_01C986FE.2DFDEDBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics = comments
Hi Yoav
 
As per #4, I did not elaborate what the = policy should=20 be, because it is network-specific, however the goal of having = ESP-NULL (in this implementation) is to have strong authentication, = while=20 enabling thirds party (intermediate) equipment to perform = DPI.  That=20 could be integrated in the in-line switch/router/firewall (for better=20 performance, but more expensive), or could be handed off to the side to = an=20 appliance (more inspections, cheaper, but slower).  = Who am I to=20 tell a Checkpoint guy about both implementations?  = :-)
 
I also disagree that we should inspect just a = first few=20 packets (and keep their state), and then leave it alone to be done in=20 cache.  Besides the scenario you outlined below, there are other=20 applications when inspection must be done on each packet = in each=20 flow. 
 
I am not saying that heuristics are not = doable, I=20 am just saying I know of implementations today that require = this check=20 performed on all packets, and I don't believe devices we are working on = today or=20 in the future would be able to support it with heuristics turned on = and=20 meeting scalability and performance requirements..  =
 
Also, DPI can be used for more than = just AV or=20 packet content snooping.  It could be used for QoS to determine = more=20 granular traffic shaping and application-level routing.  There is = also=20 LI/CALEA aspect but I will leave that alone for now.
 
 

From: Yoav Nir = [mailto:ynir@checkpoint.com]=20
Sent: Wednesday, February 04, 2009 3:04 AM
To: = Grebovich,=20 Dragan (BL60:SF00); ipsec@ietf.org
Subject: RE: [IPsec]=20 draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:
Yoav
 
I apologize for not being clearer = earlier.  I=20 was not suggesting any new/different policy enforcement. =20
 
I believe/agree that traffic visibility will = matter only=20 to a subset of traffic, but that is enforced at each appliance level,=20 or on a more granular (per interface) level.  Not all = devices have=20 to be capable of doing it, however if they are tasked to do it, they = have to=20 be able to scale and perform transparently and quickly. =20 Therefore, if heuristics are turned = on, all traffic=20 will be subject to inspection (heuristic or deterministic), and = then=20 resource consumption matter.
 
I definitely concur that not all ESP traffic = will be=20 NULL, but I believe your statement actually supports my point.  = When a=20 packet hits a decision point, the following has to be = determined=20 asap:
 
   1) Is the = packet terminated here=20 or am I to forward it?  Until now, forwarded packets were always=20 forwarded and no action was performed on the content.  = Now we may=20 want to turn on a policy to inspect packet content which is not = terminated=20 here.
   2) Can I do anything with it" = (has it=20 cleartext or IPSEC payload)?  If cleartext - it is trivial=20 ...
   3) Is it AH or ESP?  This = is quick and=20 trivial too ...
   4) If it is ESP, is it ESP-NULL = or full-ESP?=20 If it is full-ESP, I can't do anything with it - pass (preferrably) or = drop=20 (if policy insists, but I doubt someone would prevent IPSEC, you never = know). 
 
IMHO for each packet we have to = perform the four=20 steps.  It is the implementation-specific choice whether it = is=20 deterministic or heuristic inspection to make a = call.  I=20 need to make a call if it would take a few instructions or a chunk of = code,=20 potentially with some % of false-positives or false = negatives.  =20 Again, I agree with you it may be "tweaked" to be close to = 0%, however=20 each additional discrimination requires more code, more cpu and more = time to=20 execute (latency).  I am concerned that on large (high-end) = devices this=20 may take an unacceptably = large toll.
 
Dragan 
I don't think the use case is = to inspect=20 every packet like that. I also don't agree with what you wrote in = #4. If=20 the appliance is willing to pass ESP-non-NULL, then it doesn't really = care about=20 content inspection. That is fine, and probably the more common case, but = in that=20 case it shouldn't care whether a packet is or is not=20 encrypted.
 
Our use case is an edge device = that=20 inspects all traffic, and drops things it doesn't understand, such as = non-NULL=20 ESP and possibly SSL (they might make an exception for HTTPS, but do a = MiTM=20 attack against the SSL)
 
So for each packet, the = processing=20 is something like this:
  1. Is the protocol = non-IPsec? if=20 so, do the regular inspection=20
  2. Is the protocol AH? if so, =  skip to=20 the payload and do the regular = inspection=20
  3. Is the process ESP with an = SPI and=20 endpoints that have already determined to be NULL?: If so, skip to the = payload=20 and inspect. Note that this is a simple table=20 lookup=20
  4. Is this a new ESP SA? Do the = heuristics,=20 and then mark it in the = table
Of course it's possible for = the endpoints=20 to cheat, start of with ESP-NULL, and then after the heuristics marked = it as OK,=20 begin encryption. This "attack" will work if all your policy says is = "ESP must=20 be NULL". But that is not an interesting policy. Real policies will = require=20 deeper inspection of the internal flows, so the cost of the heuristics = becomes=20 negligible, as it only requires looking at the first few packets of each = ESP=20 SA.


Email secured by = Check Point=20

------_=_NextPart_001_01C986FE.2DFDEDBC-- From yaronf@checkpoint.com Wed Feb 4 14:48:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C9B28C0DE for ; Wed, 4 Feb 2009 14:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 Hqg2E+8QV1ek for ; Wed, 4 Feb 2009 14:48:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7A6F43A685E for ; Wed, 4 Feb 2009 14:48:25 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3A46629C005; Thu, 5 Feb 2009 00:48:05 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DEED329C004 for ; Thu, 5 Feb 2009 00:48:03 +0200 (IST) X-CheckPoint: {498A182E-10001-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n14Mm3ei027664 for ; Thu, 5 Feb 2009 00:48:03 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 00:48:02 +0200 From: Yaron Sheffer To: IPsecme WG Date: Thu, 5 Feb 2009 00:48:05 +0200 Thread-Topic: Feedback on the interim session's format Thread-Index: AcmHGqR0HQ+DLImjS3SO/P70izadOg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7Ailex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:48:29 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7Ailex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We would like to have your feedback on yesterday's interim meeting, and we = will pass it on to other working groups. Please send us your general impressions (what worked, what didn't work). If you feel like going into detail, here are some things we would like to u= nderstand: is the voice+IM format sufficient, or is application sharing a M= ust? Can we live with push-to-talk? Were you able to follow the discussion = clearly? Were you able to participate effectively? Did you encounter any ma= jor technical problems (e.g. one person's corporate firewall prevented him = from joining)? Feel free to respond either to the list or privately to Paul and myself. Thanks, Yaron PS: we are working on meeting minutes, to be published RSN. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7Ailex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We would like to have your feedback on yesterday’s= interim meeting, and we will pass it on to other working groups.<= /font>

 

Please send us your general impressions (what worked, wh= at didn’t work).

 

If you feel like going into detail, here are some things= we would like to understand: is the voice+IM format sufficient, or is applicat= ion sharing a Must? Can we live with push-to-talk? Were you able to follow the discussion clearly? Were you able to participate effectively? Did you encou= nter any major technical problems (e.g. one person’s corporate firewall pr= evented him from joining)?

 

Feel free to respond either to the list or privately to = Paul and myself.

 

Thanks,

         &n= bsp;  Yaron

 

 

PS: we are working on meeting minutes, to be published R= SN.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7Ailex01adcheck_-- From peng.yang.chn@gmail.com Wed Feb 4 19:03:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F14D3A6898 for ; Wed, 4 Feb 2009 19:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=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 FsPaqekUlZ2r for ; Wed, 4 Feb 2009 19:03:19 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by core3.amsl.com (Postfix) with ESMTP id 4653D3A681F for ; Wed, 4 Feb 2009 19:03:19 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j66so13611rne.18 for ; Wed, 04 Feb 2009 19:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nlPTsXw7ZhV1UshuWev7YA9fDL/DX/s4G01xQptVg+c=; b=cBgUjZ9x2S8tUMg4EEnSd80vKXXw60yPJ9ewuRrWY/Q+FymuYoc9N0Nru/iSxxz4EB ZUulLz7XgWmbvxGwhli9AEx72mO1T3OgOi4V5zIB2JFhuNX5wjKzwekIqBiCF2b4k3pK v3Rvk73stT+MXj8VJmLtCjgFnQ7CsubfovYTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KcMX7Lc2hN2oEzElYTsj6u6B6fI0W4UCiEPS50YgG3P4udNyP4TdV8rif9YtcSFtxP vy/EgeGelnQN/BwoZSebbnxjHgT4G/dsE+HPw2+uqyXHsyNMhMOx8/10YPG/K2XMbImW 18IfxClaOe2LSNCC+FnQeDSSmbE/QC4ozHD08= MIME-Version: 1.0 Received: by 10.100.143.12 with SMTP id q12mr2032097and.22.1233802978254; Wed, 04 Feb 2009 19:02:58 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> Date: Thu, 5 Feb 2009 11:02:58 +0800 Message-ID: <4c5c7a6d0902041902o5d3a3e89k36bc84a41d6a7e3e@mail.gmail.com> From: Peny Yang To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 03:03:20 -0000 Hi, Yaron: Personally, I think it's a good system, which are easy to use as well. Some of my impressions are put below based on your questions. >>voice+IM format sufficient, or is application sharing a Must? [Peny] I think it's sufficient. Application sharing helps a little for people to follow the presenters. >>Can we live with push-to-talk? [Peny] PTT is fine. But, the floor control is not so robust. In the discussion, everybody could jump up to talk. Sometimes, there was a conflict. And the echo brought some trouble when more than two people were pushing. And, sometime, people may have the possibility to mis-operate the "push" button. >>Were you able to follow the discussion? Were you able to participate effectively? > clearly? [Peny] Yes for both questions. > Did you encounter any > major technical problems (e.g. one person's corporate firewall prevented him > from joining)? [Peny] Yeah. In my office, where the ports of the client software are banned, I can not access the server. Peny On Thu, Feb 5, 2009 at 6:48 AM, Yaron Sheffer wrote: > Hi, > > > > We would like to have your feedback on yesterday's interim meeting, and we > will pass it on to other working groups. > > > > Please send us your general impressions (what worked, what didn't work). > > > > If you feel like going into detail, here are some things we would like to > understand: is the voice+IM format sufficient, or is application sharing a > Must? Can we live with push-to-talk? Were you able to follow the discussion > clearly? Were you able to participate effectively? Did you encounter any > major technical problems (e.g. one person's corporate firewall prevented him > from joining)? > > > > Feel free to respond either to the list or privately to Paul and myself. > > > > Thanks, > > Yaron > > > > > > PS: we are working on meeting minutes, to be published RSN. > > Email secured by Check Point > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From yaronf@checkpoint.com Wed Feb 4 22:51:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06D13A67BD for ; Wed, 4 Feb 2009 22:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.048, 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 DSlcuckUj9DD for ; Wed, 4 Feb 2009 22:51:13 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0D9053A6359 for ; Wed, 4 Feb 2009 22:51:12 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AAD1429C005; Thu, 5 Feb 2009 08:50:51 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E0E1F29C002 for ; Thu, 5 Feb 2009 08:50:49 +0200 (IST) X-CheckPoint: {498A8951-10003-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n156omei011639 for ; Thu, 5 Feb 2009 08:50:49 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 08:50:48 +0200 From: Yaron Sheffer To: IPsecme WG Date: Thu, 5 Feb 2009 08:50:46 +0200 Thread-Topic: Draft minutes from the interim meeting Thread-Index: AcmHXhJY7wyTf/8GQlWjzYUiSFJAFA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8A@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8Ailex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Draft minutes from the interim 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: , X-List-Received-Date: Thu, 05 Feb 2009 06:51:15 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8Ailex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please review the minutes and let me know if there are any omissions or ina= ccuracies. Please DO NOT use this thread to comment on the actual issues! Thanks, Yaron Minutes from the IPsecME WG interim meeting February 3, 2009. Using TeamSpeak voice and instant messaging. Minutes by Paul Hoffman (first half) and Yaron Sheffer (second half) See for the sli= des. Text from the slides is not repeated here Agenda was accepted. A roll call was held so people could test out their TeamSpeak client A few issues with mics being too low; were fixed. About 20 people i= n attendance for most of the meeting. Session resumption update Hannes Tschofenig presented Issue #75: Make "by reference" a first class citizen Made editorial changes to give both types of tickets equal = credit Issue #74: Extend IKE_SA_INIT instead of new exchange type Paul Hoffman, wearing co-chair hat, wants more input from o= ther folks Peny Yang asked if this is an implementation or protocol is= sue. Hui Deng pointed out that this is also an operational issue= . Paul will clear this on the list Issue #73: Ticket location: prefer server-side ticket Some discussion about if this could be raised again. Paul pointed out that it was already closed on the mailing = list Issue #70: Ticket lifetime - explicit or not? (and ticket push from= gateway) Is lifetime a purely local issue? Four options listed; will be discussed on the list Option 1 also covers when you rekey Tero Kivinen points out that this is not clear in t= he current draft Visibility heuristics Tero Kivinen presented Only done at the beginning of a stream; then the results are stored Only is of value when doing deep packet inspection Normal devices don't need to do this at all Deep packet inspection devices already are doing many of these test= s in other places There are lots of good heuristics, such as "port equals zero" Ken Grewal pointed out that different parts of hardware may not be = able to maintain state Could cause congestion points in multiple places Paul said that we will discuss on the list before we decide which d= irection we will go Redirect open issues Vijay Devarapalli presented Issue #66: Redirecting during IKE_AUTH Tero asked if the SA is torn down actively with DELETE payl= oad; yes Yaron is OK closing the issue Yoav is not comfortable with having the SA come up but then= be deleted at some short time later Adding a timer is not difficult; just seemed less c= lean Further discussion of cleanliness between Vijay and= Yoav [No issue #] Non-gateway use cases Rich Graveman has a peer-to-peer use case Tero thought this is good text to add to the draft Similarly to MOBIKE, won't cover both sides moving at the s= ame time Document Roadmap Sheila Frankel presented Paul wants that the section on "not widely adopted" RFCs should not= make it that they should be implemented. Yaron wants this to be about status of documents, not individual re= quirements levels Disagreement on whether to put in RFCs that use PRF+ but not IPsec = itself Wants much more input Mandatory access control (off-charter item) Joy Latten presented the recent labeled IPsec drafts (draft-jml-ips= ec-ikev1-security-context-00 and draft-jml-ipsec-ikev2-security-context-00,= both are non-charter items). The scope of the IKEv2 draft is larger, because multilevel concepts= have been removed from RFC 4306. Implementations exist of labeled IPsec plus IKEv1. There was no dis= cussion. The chairs requested Joy to notify the group whenever a new revisio= n is published. Limited discussion of these drafts can happen on the mailing list, = as long as it doesn't overwhelm our normal business. IKEv2-bis Paul Hoffman presented Issue #36, Interaction of IKE_SA_INIT retransmissions with specific= notifies. No discussion. Issue #14: Bounding the retransmit time. Tero wants to minimize storage by closing the retransmission window= s after some reasonable amount of time. Otherwise no discussion. Issue #19: Motivation for including SPIs in the cookie. No discussi= on. Issue #62: Security considerations - implementation robustness. Yoav supports the proposed text. Issue #16 and 45: Order of IKE payloads. Paul mentioned that we want to hear from implementors what they are expecting as responders, and what they are sending as far as strict payload ordering. Yaron commented that we cannot presume to be in touch will all implementations out there, and all current implementations need to interop with any RFC 4306-compliant implementation. Paul: the defined order is not well defined, we added stuff in Clarifications (the Appendix), possibly inconsistent with RFC 4306. Tero: Clarifications certainly has more payloads than in the RFC 4306 examples. This was supposed to add examples, rather than make old implementations non-compliant. Paul: true, we cannot hear from every implementor; but we can assume everybody is following last calls. Tero: no, Clarifications is only informative, and RFC 4306 is authoritative. But once things go into Bis, they will become mandatory. Paul: but Clarifications is being rolled into Bis. Discussion should go to the list. We need to understand where Clarifications added stuff. Now what do we do about this delta? Yoav: trying to enforce payload order is a losing proposition, given the new payloads required by extension drafts. What is the relative order. We should demote the mandatory order. Tero: only Sec. 2 of RFC 4306 mandates an order. Paul: will try to deemphasize that we can hear from everybody. But we CAN make the assumption that developers are following the discussion, however we may miss some. [Later note by Yaron: I find it weird that RFC 4306 indeed says that payloads should appear in the order specified by Sec. 2, but most of the basic exchanges only appear in Sec. 1. Which in my mind makes the original statement somewhat bogus. But people probably treated Sec. 1 as mandatory too.] Issue #11: Clarify which traffic selectors to use in rekeying. Paul: [unclear]. Tero: if you have SAs that violate the new policy, you either delete them or you rekey. Prefers a rekey, even if this is narrowing the SA. Mostly useful for decorrelated policies, but people are not doing that yet [general agreement by silence]. Gives an example of a specific connection moving from one SA to another, which he says is a policy change that requires a rekey, but only if you're doing decorrelated policy. Paul: if no-one is doing decorrelated policies, then they wouldn't have thought of this issue. Tero: some user interfaces may eliminate the need to support this feature altogether. Discussion whether decorrelated support is mandatory in RFC 4301 or not. Issue #68: Counter mode ciphers in IKEv2 to protect IKE SA. General agreement that the document specifies that IV needs to be unpredictable for CBC, and gives a reference to other docs for the non-CBC modes. Paul will republish text for this issue. Paul promised a new version of the draft before the SF I-D deadline. He also promised that the IPR issue is going to be fixed (how optimistic - Yaron). Meeting adjourned close to on time (about two hours). =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8Ailex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please review the minutes and let me know if there are a= ny omissions or inaccuracies. Please DO NOT use this thread to comment on the actual iss= ues!

 

Thanks,

         &n= bsp;  Yaron

 

Minutes from the IPsecME WG interim meeting February 3, = 2009.

 

Using TeamSpeak voice and instant messaging.<= /span>

Minutes by Paul Hoffman (first half) and Yaron Sheffer (second half) See <http://tra= c.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203> for the slides. Text from the slides is not repeated here=

 

Agenda was accepted.

 

A roll call was held so people could test out their TeamSpeak client

        A few issues = with mics being too low; were fixed. About 20 people in attendance for most of the meeting.

 

Session resumption update

        Hannes Tschof= enig presented

        Issue #75: Ma= ke "by reference" a first class citizen

         &n= bsp;      Made editorial changes to give both type= s of tickets equal credit

        Issue #74: Ex= tend IKE_SA_INIT instead of new exchange type

         &n= bsp;      Paul Hoffman, wearing co-chair hat, want= s more input from other folks

         &n= bsp;      Peny Yang asked if this is an implementa= tion or protocol issue.

         &n= bsp;      Hui Deng pointed out that this is also a= n operational issue.

         &n= bsp;      Paul will clear this on the list

        Issue #73: Ti= cket location: prefer server-side ticket

         &n= bsp;      Some discussion about if this could be raised again.

         &n= bsp;      Paul pointed out that it was already clo= sed on the mailing list

        Issue #70: Ti= cket lifetime - explicit or not? (and ticket push from gateway)

         &n= bsp;      Is lifetime a purely local issue?

         &n= bsp;      Four options listed; will be discussed o= n the list

         &n= bsp;      Option 1 also covers when you rekey=

         &n= bsp;            = ;  Tero Kivinen points out that this is not clear in the current draft

 

 

Visibility heuristics

        Tero Kivinen = presented

        Only done at = the beginning of a stream; then the results are stored

        Only is of va= lue when doing deep packet inspection

         &n= bsp;      Normal devices don't need to do this at = all

        Deep packet i= nspection devices already are doing many of these tests in other places

        There are lot= s of good heuristics, such as "port equals zero"

        Ken Grewal po= inted out that different parts of hardware may not be able to maintain state

         &n= bsp;      Could cause congestion points in multipl= e places

        Paul said tha= t we will discuss on the list before we decide which direction we will go

 

Redirect open issues

        Vijay Devarap= alli presented

        Issue #66: Re= directing during IKE_AUTH

         &n= bsp;      Tero asked if the SA is torn down active= ly with DELETE payload; yes

         &n= bsp;      Yaron is OK closing the issue=

         &n= bsp;      Yoav is not comfortable with having the = SA come up but then be deleted at some short time later

         &n= bsp;            = ;  Adding a timer is not difficult; just seemed less clean

         &n= bsp;            = ;  Further discussion of cleanliness between Vijay and Yoav

        [No issue #] = Non-gateway use cases

         &n= bsp;      Rich Graveman has a peer-to-peer use cas= e

         &n= bsp;      Tero thought this is good text to add to= the draft

         &n= bsp;      Similarly to MOBIKE, won't cover both si= des moving at the same time

 

Document Roadmap

        Sheila Franke= l presented

        Paul wants th= at the section on "not widely adopted" RFCs should not make it that they should be implemented.=

        Yaron wants t= his to be about status of documents, not individual requirements levels

        Disagreement = on whether to put in RFCs that use PRF+ but not IPsec itself

        Wants much mo= re input

 

Mandatory access control (off-charter item)

        Joy Latten pr= esented the recent labeled IPsec drafts (draft-jml-ipsec-ikev1-security-context-00 and draft-jml-ipsec-ikev2-securi= ty-context-00, both are non-charter items).

        The scope of = the IKEv2 draft is larger, because multilevel concepts have been removed from RFC 4306.

        Implementatio= ns exist of labeled IPsec plus IKEv1. There was no discussion.

 

        The chairs re= quested Joy to notify the group whenever a new revision is published.

        Limited discu= ssion of these drafts can happen on the mailing list, as long as it doesn't overwhelm our normal business.

 

IKEv2-bis

        Paul Hoffman = presented

 

        Issue #36, In= teraction of IKE_SA_INIT retransmissions with specific notifies. No discussion.

 

        Issue #14: Bo= unding the retransmit time.

        Tero wants to= minimize storage by closing the retransmission windows after some reasonable amount of time. Otherwise no discussion.

 

        Issue #19: Mo= tivation for including SPIs in the cookie. No discussion.

 

        Issue #62: Se= curity considerations - implementation robustness.

        Yoav supports= the proposed text.

 

        Issue #16 and= 45: Order of IKE payloads. Paul mentioned that we

        want to hear = from implementors what they are expecting as

        responders, a= nd what they are sending as far as strict payload

        ordering. Yar= on commented that we cannot presume to be in touch

        will all impl= ementations out there, and all current

        implementatio= ns need to interop with any RFC 4306-compliant

        implementatio= n. Paul: the defined order is not well defined, we

        added stuff i= n Clarifications (the Appendix), possibly

        inconsistent = with RFC 4306. Tero: Clarifications certainly has

        more payloads= than in the RFC 4306 examples. This was supposed to

        add examples,= rather than make old implementations non-compliant.

        Paul: true, w= e cannot hear from every implementor; but we can

        assume everyb= ody is following last calls. Tero: no,

        Clarification= s is only informative, and RFC 4306 is

        authoritative= . But once things go into Bis, they will become

        mandatory. Pa= ul: but Clarifications is being rolled into Bis.

        Discussion sh= ould go to the list. We need to understand where

        Clarification= s added stuff. Now what do we do about this delta?

        Yoav: trying = to enforce payload order is a losing proposition,

        given the new= payloads required by extension drafts. What is the

        relative orde= r. We should demote the mandatory order. Tero: only

        Sec. 2 of RFC= 4306 mandates an order. Paul: will try to

        deemphasize t= hat we can hear from everybody. But we CAN make the

        assumption th= at developers are following the discussion, however

        we may miss s= ome. [Later note by Yaron: I find it weird that RFC

        4306 indeed s= ays that payloads should appear in the order

        specified by = Sec. 2, but most of the basic exchanges only appear

        in Sec. 1. Wh= ich in my mind makes the original statement somewhat

        bogus. But pe= ople probably treated Sec. 1 as mandatory too.]

 

        Issue #11: Cl= arify which traffic selectors to use in rekeying.

        Paul: [unclea= r]. Tero: if you have SAs that violate the new

        policy, you e= ither delete them or you rekey. Prefers a rekey,

        even if this = is narrowing the SA. Mostly useful for decorrelated

        policies, but= people are not doing that yet [general agreement by

        silence]. Giv= es an example of a specific connection moving from

        one SA to ano= ther, which he says is a policy change that requires

        a rekey, but = only if you're doing decorrelated policy. Paul: if

        no-one is doi= ng decorrelated policies, then they wouldn't have

        thought of th= is issue. Tero: some user interfaces may eliminate

        the need to s= upport this feature altogether. Discussion whether

        decorrelated = support is mandatory in RFC 4301 or not.

 

        Issue #68: Co= unter mode ciphers in IKEv2 to protect IKE SA.

        General agree= ment that the document specifies that IV needs to be

        unpredictable= for CBC, and gives a reference to other docs for

        the non-CBC m= odes. Paul will republish text for this issue.

 

        Paul promised= a new version of the draft before the SF I-D

        deadline. He = also promised that the IPR issue is going to be

        fixed (how op= timistic - Yaron).

 

Meeting adjourned close to on time (about two hours).

 


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8Ailex01adcheck_-- From g_e_montenegro@yahoo.com Wed Feb 4 23:38:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694783A68DD for ; Wed, 4 Feb 2009 23:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 IHFnIgUi6Np3 for ; Wed, 4 Feb 2009 23:38:20 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 8B3013A68D5 for ; Wed, 4 Feb 2009 23:38:20 -0800 (PST) Received: (qmail 47086 invoked by uid 60001); 5 Feb 2009 07:38:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=BDqXHSpQ5zZ2nIVtPry8/UF63nHC6xxdyyUXsjqghWuxSJTnTMFzDoaFbDruTyLiPqABOr5MGndmPCnKgn9j/3arsuXUHhpVu+eTONMkl6saywqi/FfBY8c4VQdz7nPZ73UapRyRLiLzOMGmUrjcQ/jWqlDywa/nvQBxJCVfgnQ=; X-YMail-OSG: jg5Jl54VM1nI1FZ40Cxq6UlLfwp3CK0jisGxYgWsTuraJOgCtMYAKoNI9bkOmJDYDKe.NOH0BPZhNOmeWJ3aVu_e3D0qJGrMfhg1Q6tXrxDigLFsUxCZqydK72.5uCmzX_yqugdXgPVU2Se6F29NoEN5x1TiH8c4c9I8PgTz1dqlbQruvL7TBPgK3QR1zWpe5KCy75SJiUf8Byt5v5kD Received: from [24.16.92.42] by web82605.mail.mud.yahoo.com via HTTP; Wed, 04 Feb 2009 23:37:59 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA4187A850F@zrtphxm2.corp.nortel.com> Date: Wed, 4 Feb 2009 23:37:59 -0800 (PST) From: gabriel montenegro To: Dragan Grebovich , Yoav Nir , ipsec@ietf.org, Paul Hoffman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1598235757-1233819479=:47042" Message-ID: <185643.47042.qm@web82605.mail.mud.yahoo.com> Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 07:38:22 -0000 --0-1598235757-1233819479=:47042 Content-Type: text/plain; charset=us-ascii I'd like to ask the chairs to comment further about something they (Paul) said during the virtual interim about Tero's heuristics draft. From the minutes: Paul said that we will discuss on the list before we decide which direction we will go What directions do you see possible? I can see the value in publishing it as an informational draft as a separate orthogonal effort to the deterministic approach. It's not that heuristics are undoable, but as this thread (and others before it) has borne: it is not a general solution applicable in all cases. ________________________________ From: Dragan Grebovich To: Yoav Nir ; ipsec@ietf.org Sent: Wednesday, February 4, 2009 11:24:20 AM Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments draft-kivinen-ipsecme-esp-null-heuristics comments Hi Yoav As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI. That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower). Who am I to tell a Checkpoint guy about both implementations? :-) I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache. Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. Also, DPI can be used for more than just AV or packet content snooping. It could be used for QoS to determine more granular traffic shaping and application-level routing. There is also LI/CALEA aspect but I will leave that alone for now. ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular inspection 3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA. Email secured by Check Point --0-1598235757-1233819479=:47042 Content-Type: text/html; charset=us-ascii
I'd like to ask the chairs to comment further about something
they (Paul) said during the virtual interim about Tero's
heuristics draft. From the minutes:

        Paul said that we will discuss on the list before we decide which direction we will go

What directions do you see possible? I can see the value in
publishing it as an informational draft as a separate orthogonal
effort to the deterministic approach.

It's not that heuristics are undoable, but as this
thread (and others before it) has borne: it is not a general
solution applicable in all cases.


From: Dragan Grebovich <dragan@nortel.com>
To: Yoav Nir <ynir@checkpoint.com>; ipsec@ietf.org
Sent: Wednesday, February 4, 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Yoav
 
As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI.  That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower).  Who am I to tell a Checkpoint guy about both implementations?  :-)
 
I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache.  Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. 
 
I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. 
 
Also, DPI can be used for more than just AV or packet content snooping.  It could be used for QoS to determine more granular traffic shaping and application-level routing.  There is also LI/CALEA aspect but I will leave that alone for now.
 
 

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Wednesday, February 04, 2009 3:04 AM
To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:
Yoav
 
I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement. 
 
I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level.  Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly.  Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter.
 
I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following has to be determined asap:
 
   1) Is the packet terminated here or am I to forward it?  Until now, forwarded packets were always forwarded and no action was performed on the content.  Now we may want to turn on a policy to inspect packet content which is not terminated here.
   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...
   3) Is it AH or ESP?  This is quick and trivial too ...
   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 
 
IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call.  I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency).  I am concerned that on large (high-end) devices this may take an unacceptably large toll.
 
Dragan 
I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted.
 
Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)
 
So for each packet, the processing is something like this:
  1. Is the protocol non-IPsec? if so, do the regular inspection
  2. Is the protocol AH? if so,  skip to the payload and do the regular inspection
  3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup
  4. Is this a new ESP SA? Do the heuristics, and then mark it in the table
Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA.


Email secured by Check Point

--0-1598235757-1233819479=:47042-- From yaronf@checkpoint.com Wed Feb 4 23:52:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB753A68D5 for ; Wed, 4 Feb 2009 23:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 IIeRJ5vLvmlU for ; Wed, 4 Feb 2009 23:52:35 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 01DDE3A6828 for ; Wed, 4 Feb 2009 23:52:33 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6BDC529C006; Thu, 5 Feb 2009 09:52:13 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CB73C29C002; Thu, 5 Feb 2009 09:52:11 +0200 (IST) X-CheckPoint: {498A97B2-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n157qAei027359; Thu, 5 Feb 2009 09:52:11 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 09:52:10 +0200 From: Yaron Sheffer To: gabriel montenegro , Dragan Grebovich , Yoav Nir , "ipsec@ietf.org" , Paul Hoffman Date: Thu, 5 Feb 2009 09:52:15 +0200 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmHZNtprgPgBNJkRXyHP61u4v8rrAAAFYuA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA4187A850F@zrtphxm2.corp.nortel.com> <185643.47042.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <185643.47042.qm@web82605.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92ilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 07:52:36 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gabriel, This thread is precisely the discussion that Paul mentions. The two alternatives I see on the table right now (Paul might have differen= t opinions) are: - Publish a modified/wrapped ESP as Standards Track, and heuristic= s as an extra Informational. - Decide that heuristics are a sufficient solution for the problem= , and publish it as the only ipsecme work item related to this charter item= . Paul and I would like to see more discussion and hopefully WG consensus bei= ng formed, now that we have a real heuristics I-D for everyone to analyze. Thanks, Yaron ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of g= abriel montenegro Sent: Thursday, February 05, 2009 9:38 To: Dragan Grebovich; Yoav Nir; ipsec@ietf.org; Paul Hoffman Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments I'd like to ask the chairs to comment further about something they (Paul) said during the virtual interim about Tero's heuristics draft. From the minutes: Paul said that we will discuss on the list before we decide which d= irection we will go What directions do you see possible? I can see the value in publishing it as an informational draft as a separate orthogonal effort to the deterministic approach. It's not that heuristics are undoable, but as this thread (and others before it) has borne: it is not a general solution applicable in all cases. ________________________________ From: Dragan Grebovich To: Yoav Nir ; ipsec@ietf.org Sent: Wednesday, February 4, 2009 11:24:20 AM Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Hi Yoav As per #4, I did not elaborate what the policy should be, because it is net= work-specific, however the goal of having ESP-NULL (in this implementation)= is to have strong authentication, while enabling thirds party (intermediat= e) equipment to perform DPI. That could be integrated in the in-line switc= h/router/firewall (for better performance, but more expensive), or could be= handed off to the side to an appliance (more inspections, cheaper, but slo= wer). Who am I to tell a Checkpoint guy about both implementations? :-) I also disagree that we should inspect just a first few packets (and keep t= heir state), and then leave it alone to be done in cache. Besides the scen= ario you outlined below, there are other applications when inspection must = be done on each packet in each flow. I am not saying that heuristics are not doable, I am just saying I know of = implementations today that require this check performed on all packets, and= I don't believe devices we are working on today or in the future would be = able to support it with heuristics turned on and meeting scalability and pe= rformance requirements.. Also, DPI can be used for more than just AV or packet content snooping. It= could be used for QoS to determine more granular traffic shaping and appli= cation-level routing. There is also LI/CALEA aspect but I will leave that = alone for now. ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/di= fferent policy enforcement. I believe/agree that traffic visibility will matter only to a subset of tra= ffic, but that is enforced at each appliance level, or on a more granular (= per interface) level. Not all devices have to be capable of doing it, howe= ver if they are tasked to do it, they have to be able to scale and perform = transparently and quickly. Therefore, if heuristics are turned on, all tra= ffic will be subject to inspection (heuristic or deterministic), and then r= esource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe yo= ur statement actually supports my point. When a packet hits a decision poi= nt, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forw= arded packets were always forwarded and no action was performed on the cont= ent. Now we may want to turn on a policy to inspect packet content which i= s not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If c= leartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't = do anything with it - pass (preferrably) or drop (if policy insists, but I = doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implemen= tation-specific choice whether it is deterministic or heuristic inspection = to make a call. I need to make a call if it would take a few instructions = or a chunk of code, potentially with some % of false-positives or false neg= atives. Again, I agree with you it may be "tweaked" to be close to 0%, ho= wever each additional discrimination requires more code, more cpu and more = time to execute (latency). I am concerned that on large (high-end) devices= this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don= 't agree with what you wrote in #4. If the appliance is willing to pass ESP= -non-NULL, then it doesn't really care about content inspection. That is fi= ne, and probably the more common case, but in that case it shouldn't care w= hether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things = it doesn't understand, such as non-NULL ESP and possibly SSL (they might ma= ke an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular ins= pection 3. Is the process ESP with an SPI and endpoints that have already determi= ned to be NULL?: If so, skip to the payload and inspect. Note that this is = a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL,= and then after the heuristics marked it as OK, begin encryption. This "att= ack" will work if all your policy says is "ESP must be NULL". But that is n= ot an interesting policy. Real policies will require deeper inspection of t= he internal flows, so the cost of the heuristics becomes negligible, as it = only requires looking at the first few packets of each ESP SA. Email secured by Check Point =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Gabriel,

 

This thread is precisely the discussio= n that Paul mentions.

 

The two alternatives I see on the tabl= e right now (Paul might have different opinions) are:

 

-      =     Publish a modified/wrapped ESP as Standards Track, and heuristi= cs as an extra Informational.

-      =     Decide that heuristics are a sufficient solution for the proble= m, and publish it as the only ipsecme work item related to this charter item.=

 

Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze.

 

Thanks,

      &n= bsp;     Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of gabriel montenegro
Sent: Thursday, February 05,= 2009 9:38
To: Dragan Grebovich; Yoav Nir; ipsec@ie= tf.org; Paul Hoffman
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

I'd like to ask the chairs to comment further ab= out something
they (Paul) said during the virtual interim about Tero's
heuristics draft. From the minutes:

        Paul said that we will discuss on the list before we decide which direction we will go


What directions do you see possible? I can see the value in
publishing it as an informational draft as a separate orthogonal
effort to the deterministic approach.

It's not that heuristics are undoable, but as this
thread (and others before it) has borne: it is not a general
solution applicable in all cases.

From:= = Dragan Grebovich <dragan@nortel.com>
To: Yoav Nir <ynir@checkpoint.com>; ipsec@ietf.org
Sent: Wednesday, February 4,= 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

Hi Yoav

 

As per #4, I did not elaborate what th= e policy should be, because it is network-specific, however the goa= l of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI.&n= bsp; That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower).  Who am I to tell a Checkpoint guy about both implementations?  :-)

 

I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to= be done in cache.  Besides the scenario you outlined below, there are oth= er applications when inspection must be done on each packet in = each flow. 

 

I am not saying that heuristics a= re not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we= are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. 

 

Also, DPI can be used for more than just AV or packet content snooping.  It could be used for QoS to determine more granular traffic shaping and application-level routing. = ; There is also LI/CALEA aspect but I will leave that alone for now.

 

 

 

From:= = Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Wednesday, February 04= , 2009 3:04 AM
To: Grebovich, Dragan (BL60:= SF00); ipsec@ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

Dragan Grebovich wrote:

Yoav

 

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement.&n= bsp;

 

I believe/agree that traffic visibilit= y will matter only to a subset of traffic, but that is enforced at each appli= ance level, or on a more granular (per interface) level.  Not all devi= ces have to be capable of doing it, however if they are tasked to do it, they h= ave to be able to scale and perform transparently and quickly.  Therefore,= if heuristics are turned on, all traffic will be subject to inspecti= on (heuristic or deterministic), and then resource consumption matter.

 

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following h= as to be determined asap:

 

   1) Is the packet terminated here or am I to forward it?  Until now, forward= ed packets were always forwarded and no action was performed on the content.&n= bsp; Now we may want to turn on a policy to inspect packet content which is= not terminated here.

   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...

   3) Is it AH or ESP?  This is quick and trivial too ...

   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 

 

IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection t= o make a call.  I need to make a call if it would take a few instru= ctions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked"= ; to be close to 0%, however each additional discrimination requires more c= ode, more cpu and more time to execute (latency).  I am concerned that on l= arge (high-end) devices this may take an unacceptably large toll.

 

Dragan <= /p>

I don't think the use case is to inspe= ct every packet like that. I also don't agree with what you wrote in #4. = If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, = but in that case it shouldn't care whether a packet is or is not encrypted.

 

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-N= ULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

 

So for each packet, the processing is something like this:

  1. Is the pr= otocol non-IPsec? if so, do the regular inspection
  2. Is the protoco= l AH? if so,  skip to the payload and do the regular inspection<= /font>
  3. Is the process= ESP with an SPI and endpoints that have already determined to be NULL?: If= so, skip to the payload and inspect. Note that this is a simple table look= up
  4. Is this a new = ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoi= nts to cheat, start of with ESP-NULL, and then after the heuristics marked it a= s OK, begin encryption. This "attack" will work if all your policy = says is "ESP must be NULL". But that is not an interesting policy. Rea= l policies will require deeper inspection of the internal flows, so the cost = of the heuristics becomes negligible, as it only requires looking at the first= few packets of each ESP SA.



Email secured by Check Point


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92ilex01adcheck_-- From yaronf@checkpoint.com Thu Feb 5 00:46:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23823A6870 for ; Thu, 5 Feb 2009 00:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 IXESiWe+MDpx for ; Thu, 5 Feb 2009 00:45:51 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 156CB3A69D4 for ; Thu, 5 Feb 2009 00:45:50 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C883329C007; Thu, 5 Feb 2009 10:45:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4023229C002; Thu, 5 Feb 2009 10:45:28 +0200 (IST) X-CheckPoint: {498AA42E-10001-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n158jQej013585; Thu, 5 Feb 2009 10:45:27 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 10:45:27 +0200 From: Yaron Sheffer To: "Grewal, Ken" , Yoav Nir , Dragan Grebovich , "ipsec@ietf.org" Date: Thu, 5 Feb 2009 10:45:19 +0200 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcAAVKchAAB4yxHA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCAB@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCABilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 08:46:01 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCABilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ken, Yoav, I agree with Ken that the policy needs not be black and white, but for a di= fferent reason. Some people will treat deep packet inspection by middleboxe= s as an optional service: you want it for most traffic, but some traffic is= too sensitive and you choose to prioritize confidentiality over malware pr= otection. This model is definitely susceptible to attacks by infected endpoints that = can control the IPsec stack, and e.g. attack a server using encrypted traff= ic. You don't really need a "colluding" peer - most peers will probably acc= ept either an ESP-null or an ESP-encrypted proposal. But admins may be will= ing to take this risk. Thanks, Yaron ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G= rewal, Ken Sent: Wednesday, February 04, 2009 20:25 To: Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Quote ... "Our use case is an edge device that inspects all traffic, and drops things= it doesn't understand, such as non-NULL ESP and possibly SSL (they might m= ake an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, dr= op ESP-encrypted), as traffic patterns will be mixed in reality (encrypted = Vs. clear) and policy will dictate how a given traffic stream in inspected = and if it is opaque then take the associated action (drop / bypass / apply = QOS rules / send a different path in the network / etc...). e.g. There may = be a secure channel to transfer highly sensitive data (e.g. payroll, compan= y secrets, etc.) which should be encrypted and it may be undesirable to cat= egorize this under a general rule - this is a simple extension of the firew= all function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a= later stage uses ESP-Encrypted may also be possible unintentionally. E.g. = Connection to a server (cluster / farm) to gain access to a 'normal' servic= e uses ESP-NULL and then at a later stage, where the previous connection wa= s torn down and a new one built, the connection is obtaining some sensitive= data and is now using ESP-Encrypted. On the outside, the connection attrib= utes look the same (same server IP, same client IP (but may be different cl= ient due to NAT), same SPI - SPIs can be reused for new connections to pres= erve fast lookups algorithms at recipients), but underneath the connection = is to access a different resource (may be using a different port or service= above the IP layer). If the intermediate device has a cached rule (based o= n the previous connection) indicating the traffic is clear, it will lead to= falsely inferring the contents of the payload and undesirable results. Thi= s goes to my point on cache eviction policy for heuristics based intermedia= te devices, as highlighted in a separate thread. Reuse of the same 'tuple' = with different traffic characteristics may be infrequent, but still plausib= le. I agree with Yoav that this attack may also be possible intentionally betwe= en two colluding parties, where the policy indicates all traffic is ESP-NUL= L. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/di= fferent policy enforcement. I believe/agree that traffic visibility will matter only to a subset of tra= ffic, but that is enforced at each appliance level, or on a more granular (= per interface) level. Not all devices have to be capable of doing it, howe= ver if they are tasked to do it, they have to be able to scale and perform = transparently and quickly. Therefore, if heuristics are turned on, all tra= ffic will be subject to inspection (heuristic or deterministic), and then r= esource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe yo= ur statement actually supports my point. When a packet hits a decision poi= nt, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forw= arded packets were always forwarded and no action was performed on the cont= ent. Now we may want to turn on a policy to inspect packet content which i= s not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If c= leartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't = do anything with it - pass (preferrably) or drop (if policy insists, but I = doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implemen= tation-specific choice whether it is deterministic or heuristic inspection = to make a call. I need to make a call if it would take a few instructions = or a chunk of code, potentially with some % of false-positives or false neg= atives. Again, I agree with you it may be "tweaked" to be close to 0%, ho= wever each additional discrimination requires more code, more cpu and more = time to execute (latency). I am concerned that on large (high-end) devices= this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don= 't agree with what you wrote in #4. If the appliance is willing to pass ESP= -non-NULL, then it doesn't really care about content inspection. That is fi= ne, and probably the more common case, but in that case it shouldn't care w= hether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things = it doesn't understand, such as non-NULL ESP and possibly SSL (they might ma= ke an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular ins= pection 3. Is the process ESP with an SPI and endpoints that have already determi= ned to be NULL?: If so, skip to the payload and inspect. Note that this is = a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL,= and then after the heuristics marked it as OK, begin encryption. This "att= ack" will work if all your policy says is "ESP must be NULL". But that is n= ot an interesting policy. Real policies will require deeper inspection of t= he internal flows, so the cost of the heuristics becomes negligible, as it = only requires looking at the first few packets of each ESP SA. Email secured by Check Point =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCABilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Ken, Yoav,=

 

I agree with Ken that the policy needs= not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for mo= st traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection.

 

This model is definitely susceptible t= o attacks by infected endpoints that can control the IPsec stack, and e.g. at= tack a server using encrypted traffic. You don’t really need a “coll= uding” peer – most peers will probably accept either an ESP-null or an ESP-e= ncrypted proposal. But admins may be willing to take this risk.

 

Thanks,

      &n= bsp;     Yaron

 

From: ipsec-bo= unces@ietf.org [mailto:ipsec-bounces@ietf.org] On Beha= lf Of Grewal, Ken
Sent: Wednesday, February 04= , 2009 20:25
To: Yoav Nir; Dragan Grebovich; ipsec@= ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Quote …=

“Our use case is an edge device that inspects all traffic, and d= rops things it doesn't understand, such as non-NULL ESP and possibly SSL (they m= ight make an exception for HTTPS, but do a MiTM attack against the SSL)

”

I do not think a typical policy will b= e black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns w= ill be mixed in reality (encrypted Vs. clear) and policy will dictate how a giv= en traffic stream in inspected and if it is opaque then take the associated ac= tion (drop / bypass / apply QOS rules / send a different path in the network / etc…). e.g. There may be a secure channel to transfer highly sensitiv= e data (e.g. payroll, company secrets, etc.) which should be encrypted and it= may be undesirable to categorize this under a general rule – this is a si= mple extension of the firewall function.

 

The ‘bait and switch’ atta= ck where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypt= ed may also be possible unintentionally. E.g. Connection to a server (cluster = / farm) to gain access to a ‘normal’ service uses ESP-NULL and th= en at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (sam= e server IP, same client IP (but may be different client due to NAT), same SP= I – SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP l= ayer). If the intermediate device has a cached rule (based on the previous connect= ion) indicating the traffic is clear, it will lead to falsely inferring the cont= ents of the payload and undesirable results. This goes to my point on cache evic= tion policy for heuristics based intermediate devices, as highlighted in a separ= ate thread. Reuse of the same ‘tuple’ with different traffic characteristics may be infrequent, but still plausible. <= /font>

 

I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the pol= icy indicates all traffic is ESP-NULL.

 

<= span style=3D'font-size:12.0pt;color:navy'>Thanks,

<= span style=3D'font-size:12.0pt;color:navy'>- Ken

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, February 04= , 2009 12:04 AM
To: Dragan Grebovich; ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Dragan Grebovich wrote:

Yoav

 

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement.&n= bsp;

 

I believe/agree that traffic visibilit= y will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level.  Not all devi= ces have to be capable of doing it, however if they are tasked to do it, they h= ave to be able to scale and perform transparently and quickly.  Therefore,= if heuristics are turned on, all traffic will be subject to inspecti= on (heuristic or deterministic), and then resource consumption matter.

 

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following h= as to be determined asap:

 

   1) Is the packet terminated here or am I to forward it?  Until now, forward= ed packets were always forwarded and no action was performed on the content.&n= bsp; Now we may want to turn on a policy to inspect packet content which is= not terminated here.

   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...

   3) Is it AH or ESP?  This is quick and trivial too ...

   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 

 

IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection t= o make a call.  I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives= or false negatives.   Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency).  I am concerned that on large (high-end) devices this may t= ake an unacceptably large toll.

 

Dragan <= /p>

I don't think the use case is to inspe= ct every packet like that. I also don't agree with what you wrote in #4. = If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, = but in that case it shouldn't care whether a packet is or is not encrypted.

 

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-N= ULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

 

So for each packet, the processing is something like this:

  1. Is the pr= otocol non-IPsec? if so, do the regular inspection
  2. Is the protoco= l AH? if so,  skip to the payload and do the regular inspection<= /font>
  3. Is the process= ESP with an SPI and endpoints that have already determined to be NULL?: If= so, skip to the payload and inspect. Note that this is a simple table look= up
  4. Is this a new = ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoi= nts to cheat, start of with ESP-NULL, and then after the heuristics marked it a= s OK, begin encryption. This "attack" will work if all your policy = says is "ESP must be NULL". But that is not an interesting policy. Rea= l policies will require deeper inspection of the internal flows, so the cost = of the heuristics becomes negligible, as it only requires looking at the first= few packets of each ESP SA.



Email secured by Check Point


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCABilex01adcheck_-- From yaronf@checkpoint.com Thu Feb 5 01:04:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C303A6A81 for ; Thu, 5 Feb 2009 01:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 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 G5MQDTwHhGxN for ; Thu, 5 Feb 2009 01:04:49 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0FF4D3A689B for ; Thu, 5 Feb 2009 01:04:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A676329C005; Thu, 5 Feb 2009 11:04:28 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A4F6A29C002; Thu, 5 Feb 2009 11:04:27 +0200 (IST) X-CheckPoint: {498AA8A2-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1594Qei019059; Thu, 5 Feb 2009 11:04:27 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 11:04:26 +0200 From: Yaron Sheffer To: Vijay Devarapalli , Richard Graveman Date: Thu, 5 Feb 2009 11:04:16 +0200 Thread-Topic: [IPsec] question about IKEv2 Re-direct Thread-Index: AcmGY8JyLIGuSbuRTkqTzUgHhiHuxgBDJG5A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCBE@il-ex01.ad.checkpoint.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> <45c8c21a0902031445y234f0227u652d4bcc261675cd@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:04:50 -0000 Also, REDIRECT_SUPPORTED needs to be sent by both peers if we want to enabl= e this case. Otherwise, when the initiator wants to redirect its peer, it c= annot know that the responder actually supports this capability. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, February 04, 2009 2:59 > To: Richard Graveman > Cc: ipsec@ietf.org > Subject: Re: [IPsec] question about IKEv2 Re-direct > > Hello, > > On Tue, Feb 3, 2009 at 2:45 PM, Richard Graveman > wrote: > > Hi, > > > >> On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman > wrote: > >>> Thanks. Your text is fine. The point was raised that we may not want > >>> both parties redirecting at once. In your use cases, is it always the > >>> IKEv2 responder that would redirect? > >> > >> Yes. It is always the responder in the client-gateway scenarios. > > > > Then, perhaps consider: "If a responder wants to redirect and receives > > a redirect request from the initiator, ignore > > the initiator's request. [The idea is that if this causes the > > initiator to fail, well then, initiate again.] > > I created a new section in the draft, since it was getting > complicated. :) Here is the text. > > 7. Use of the Redirect Mechanism between IKEv2 Peers > > The Re-direct mechanism described in this document is mainly intended > for use in client-gateway scenarios. However, the mechanism can also > be used between any two IKEv2 peers. This is especially useful for > IKEv2 sessions between two gateway peer routers. > > When used between a client and gateway, the re-direct procedure is > always initiated by the gateway. But when used between two IKEv2 > peers, either of the IKEv2 end points can initiate the re-direct > message. In order to prevent any race condition that might occur if > both decide to re-direct at the same time, the responder MUST not > respond to re-direct message from the initiator, if it has already > decided to re-direct the initiator. > > A temporary pre04 version of the draft is at > http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2= - > redirect-04.txt > > Vijay > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point From kivinen@iki.fi Thu Feb 5 03:58:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818563A6A5B for ; Thu, 5 Feb 2009 03:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 pCsOp49JtOXN for ; Thu, 5 Feb 2009 03:58:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D825F3A6927 for ; Thu, 5 Feb 2009 03:58:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n15Bvvhp003244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 13:57:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n15BvtcJ023469; Thu, 5 Feb 2009 13:57:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18826.54339.452491.244002@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2009 13:57:55 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 33 min X-Total-Time: 33 min Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 11:58:22 -0000 Grewal, Ken writes: > Cache eviction - how will this work? > We can keep adding SAs (based on heuristics), but how do we decide > when a given SA is no longer needed? This compounds the issues with > keeping state, as in the best case, cache eviction will likely be > policy based. How is the policy determined and how do we > differentiate between short and long lived SAs? As the SA cache will > be of a finite size, this WILL lead to a cache thrash (add SA, evict > SA, ...), causing further resource consumption. This is actually quite good point, and it is also implementation detail that do affect the performance. How this can be solved depends quite heavily on the environment where heuristics is used. If we are doing firewall that already keeps state of all TCP/UDP flows, then it would be natural to weakly bind IPsec SAs and TCP/UDP flows inside together. For example keep in track when there is no more TCP/UDP flows using the IPsec SA (i.e. all the TCP/UDP flows which used this SA before, have now been moved to new IPsec SA), and after that you can most likely remove the IPsec SA entry quite quickly. Another, and probably more common implementation will be just some simple LRU based mechanisms to reuse old IPsec SA entries. This kind of things are usually already done for the UDP protocols. > How about dynamic route changes for already established SAs? The > same problem will exist as the Monday morning problem, but without > the diffie-hellman overhead. Because we are caching state on one > device, a change in route where the packets take a different path > will force the new device to 'relearn' all the cached info. Yes, but heuristics is still fast operation, thus that should not be problem. Bigger problem usually is that the deep inspection state is lost too... > High availability is another one to consider, especially during > maintenance periods. One device is powered down and a backup device > takes over. This is similar to route changes in principle, where the > backup device will need to relearn all the state. As here the heuristics is run on the same device which is running the deep inspection, they do already require methods of transferring that deep inspection state from one device to another, and moving the IPsec SPI cache state at the same time should not be a problem. > Agree, but the heuristics engine may be heavily used as VOIP becomes > prevalent, especially within the Enterprise. Lots and lots of UDP > traffic that is short lived, which ties back to earlier points on > cache maintenance and frequency of exercising the heuristics engine. If we know anything about the contents of the UDP packet (i.e. recognize that it is VOIP traffic), we can most likely do heuristics based on the single packet. Even if there is only 32 bits of the known data in the packet (lets say version number and magic cookie or similar), then usually that is already enough for detecting the parameters and the probability that random ESP-encrypted packet has same content is less than 0.000000024% (1/(2^32) * 100%). So if VOIP traffic is heavily used then the heuristics most likely will have special protocol detection code for it. > Auditing / logging / sniffing / sampling are some examples of > stateless devices that do require to peek in the packets. Probably > lots more also, so look for others to provide examples... As those do not affect the forwarding of the packet, then the reliability requirements for them is much lower, meaning that they can also work without storing any state, and running heuristics for per packet basis. That of course do require implementing the heuristics on the hardware if we are talking about gigabit links or faster. My guess is that without any hardware support and only using software with modern CPU you can probably process more than 100MBit/s, but most likely not full 1GBit/s speed. Of course if you are talking about very low cost appliances, then they will not have modern CPUs, but on the other hand people do not normally expect them to keep up with 1GBit/s speeds... > The speed of deployment may or may not be true. If the stars are > aligned, then it could be deployed within one or two refresh cycles, > which is about the same for heuristics in intermediaries devices. > After all, only a handful of vendors own a large percentage of the > market for OS / intermediary devices. Adoption is obviously based on > customer pull/perceived usefulness. The difference is that heuristics can be deployed within one or two refresh cycles of the intermediate devices after customers start to ask for it. Modified ESP can be deployed within one or two refresh cycles of the slowest vendor whose devices are used in the network. Meaning that if the printer vendor used in the network does not update their IPsec to support that modified ESP, then that modified ESP cannot be used by intermediate devices. > >Heuristics can also be implemented regardless of IKEv1 or IKEv2. > >Modifying the ESP will be IKEv2 only, thus it will require end > >nodes to start using that too. It seems that quite a lot of devices > >are still using already obsoleted IKEv1 still, even when IKEv2 has > >been out for 3 years... > > This point is somewhat moot, as we are trying to address a new use > case for ubiquitous transport mode IPsec, which is not the case > today. It is a new use case, so if people want it, they will use the > correct version of IKE. To use correct version of IKE, in these use cases, do still require ALL vendors used in the network to support IKEv2 in ALL of their devices and in ALL of their operating systems before the modified ESP can be assumed by the intermediate devices. I.e. it for example requires that every single Windows Vista and Windows XP (and of course older versions) machine to be updated to Windows 7 so they get IKEv2 support. > In fact, the same argument is true for all the other changes we are > putting into IKE under the different charter items... Nope. None of the other modifications we are doing is something that requires every single IPsec implementation to be modified. You only need resumption support if you are ever going to use it. If you do not use it you do not need to know anything about it. On the other hand the modified ESP support is required by all devices talking IPsec in the enterprice network before the middle boxes can be used. -- kivinen@iki.fi From kivinen@iki.fi Thu Feb 5 04:03:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E483C3A6A67 for ; Thu, 5 Feb 2009 04:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Lk9qw1rheSFd for ; Thu, 5 Feb 2009 04:03:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D23A73A67A5 for ; Thu, 5 Feb 2009 04:03:42 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n15C3F1o029579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:03:15 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n15C3Fxm004563; Thu, 5 Feb 2009 14:03:15 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18826.54659.111116.336222@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2009 14:03:15 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" , Yoav Nir , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 12:03:44 -0000 Grewal, Ken writes: > The 'bait and switch' attack where a connection uses ESP-NULL and > then at a later stage uses ESP-Encrypted may also be possible > unintentionally. E.g. Connection to a server (cluster / farm) to > gain access to a 'normal' service uses ESP-NULL and then at a later > stage, where the previous connection was torn down and a new one > built, the connection is obtaining some sensitive data and is now > using ESP-Encrypted. On the outside, the connection attributes look > the same (same server IP, same client IP (but may be different > client due to NAT), same SPI - SPIs can be reused for new > connections to preserve fast lookups algorithms at recipients), but > underneath the connection is to access a different resource (may be > using a different port or service above the IP layer). If the > intermediate device has a cached rule (based on the previous > connection) indicating the traffic is clear, it will lead to falsely > inferring the contents of the payload and undesirable results. This was covered in the draft section 7, where it said that if deep inspection engine suddenly starts getting lots of garbage then it should rerun the heuristics. > I agree with Yoav that this attack may also be possible > intentionally between two colluding parties, where the policy > indicates all traffic is ESP-NULL. It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases. If both ends want to use encryption then the middle boxes cannot really prevent it very easily. If TLS and SSH and blocked then use IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then use IP(sec) over mail :-) -- kivinen@iki.fi From kivinen@iki.fi Thu Feb 5 04:20:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6341C3A6A4D for ; Thu, 5 Feb 2009 04:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_52=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 6vsYi7W5s8Tu for ; Thu, 5 Feb 2009 04:20:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 577873A67D2 for ; Thu, 5 Feb 2009 04:20:22 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n15CJuLX004960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:19:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n15CJueX010085; Thu, 5 Feb 2009 14:19:56 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18826.55660.517420.835024@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2009 14:19:56 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 11 min Cc: IPsecme WG Subject: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:20:23 -0000 Yaron Sheffer writes: > If you feel like going into detail, here are some things we would > like to understand: is the voice+IM format sufficient, or is > application sharing a Must? I think voice + IM is sufficient, but slide sharing would have been even better. Now it was sometimes bit hard to know what slide people were talking about, and also when I was presenting, I noticed that it was sometimes hard to remember to say that I moved to new slide. The slide sharing could be something very simple also, and it might have been better if all the slides have already been converted (or submitted) as html pages in addition to pdf. I do not know if there is any freely usable slide sharing systems, but setting up some web page using ajax or similar to fetch new page when presenter moves to next page, should not be too hard to make (it should be so simple, that I expect someone has already done that, so perhaps we should check :-) > Can we live with push-to-talk? Push-to-talk works well for normal discussion, but it was impossible to use when giving presentation, which meant that I myself changed the setting to voice activated microphone when I started my presentation, and then changed back to push-to-talk when I finished. This is something that should be instructed for the people giving presentations (there were others having problems too). > Were you able to follow the discussion clearly? Sound quality was good, and we did have less background noise than what I execpted. Most likely because everybody was instructed beforehand to use push-to-talk. The +20dB microphone boost is something that also needs to be added to the documentation. > Were you able to participate effectively? Yes. > Did you encounter any major technical problems (e.g. one person's > corporate firewall prevented him from joining)? Our corporate firewall did block teamspeak ports, but as I knew about this beforehand, I was able to get the firewall rules changed so that the teamspeak could be used. -- kivinen@iki.fi From kivinen@iki.fi Thu Feb 5 04:35:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF443A6A24 for ; Thu, 5 Feb 2009 04:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 3IC7DrdsO-CI for ; Thu, 5 Feb 2009 04:35:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2F43A6927 for ; Thu, 5 Feb 2009 04:34:58 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n15CYZlG016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:34:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n15CYZiR000154; Thu, 5 Feb 2009 14:34:35 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18826.56539.51447.845755@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2009 14:34:35 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: IPsecme WG Subject: [IPsec] Draft minutes from the interim 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: , X-List-Received-Date: Thu, 05 Feb 2009 12:35:03 -0000 > IKEv2-bis > Issue #11: Clarify which traffic selectors to use in rekeying. > Paul: [unclear]. Tero: if you have SAs that violate the new > policy, you either delete them or you rekey. Prefers a rekey, > even if this is narrowing the SA. Mostly useful for decorrelated > policies, but people are not doing that yet [general agreement by > silence]. Gives an example of a specific connection moving from > one SA to another, which he says is a policy change that requires > a rekey, but only if you're doing decorrelated policy. The example I gave was that we have IPsec SA between two hosts (or subnets) and then someone adds new SPD rule which has higher precedence and which says that port 80 between those hosts should be put on separate SA. This effectively creates hole to the old IPsec SA, thus the old IPsec SA now covers traffic selectors which it should not. > Paul: if no-one is doing decorrelated policies, then they > wouldn't have thought of this issue. Tero: some user > interfaces may eliminate the need to support this feature > altogether. There is three ways to do this: 1) Forbid overlapping selectors (i.e. make user interface so that you cannot enter overlapping traffic selectors, and require adminstrator to "decorrelate" traffic selectors manually). 2) Go through SPD entries in the precedence order and do not use any kind of caching. This requires linear scan through SPD for every single packet. 3) Do the decorrelation properly and then you can use effective datastuctures to find the correct SPD entry, i.e. no linear scan is needed as you know that there cannot be any overlapping SPD entries in the decorrelated policy. -- kivinen@iki.fi From ynir@checkpoint.com Thu Feb 5 04:52:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3723A6A87 for ; Thu, 5 Feb 2009 04:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 ZAAHI2xrjjZB for ; Thu, 5 Feb 2009 04:52:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0FE593A6927 for ; Thu, 5 Feb 2009 04:52:10 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 715A829C004; Thu, 5 Feb 2009 14:51:46 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 85F3229C002; Thu, 5 Feb 2009 14:51:45 +0200 (IST) X-CheckPoint: {498ADDE6-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n15Cpiei022577; Thu, 5 Feb 2009 14:51:45 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Feb 2009 14:51:44 +0200 From: Yoav Nir To: Tero Kivinen , Yaron Sheffer Date: Thu, 5 Feb 2009 14:52:16 +0200 Thread-Topic: [IPsec] Feedback on the interim session's format Thread-Index: AcmHjB0P2UUgoCBuQ6uc/MjGIGz0wwAA+wgg Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> In-Reply-To: <18826.55660.517420.835024@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:52:11 -0000 Tero Kivinen wrote: > > Can we live with push-to-talk? > > Push-to-talk works well for normal discussion, but it was > impossible to use when giving presentation, which meant that > I myself changed the setting to voice activated microphone > when I started my presentation, and then changed back to > push-to-talk when I finished. This is something that should > be instructed for the people giving presentations (there were > others having problems too). The problem with that solution is that when someone asks a question, your e= ver-open microphone echoes their question. This was especially noticeable i= n Sheila's presentation about the roadmap document, but also in yours. Some= mikes have a mute button (which I inadvertantly pushed), so that could sol= ve it. > > Did you encounter any major technical problems (e.g. one person's > > corporate firewall prevented him from joining)? > > Our corporate firewall did block teamspeak ports, but as I > knew about this beforehand, I was able to get the firewall > rules changed so that the teamspeak could be used. Not everyone has that kind of clout. Email secured by Check Point From paul.hoffman@vpnc.org Thu Feb 5 05:02:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8D43A6AFE for ; Thu, 5 Feb 2009 05:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX6eQfRfi82L for ; Thu, 5 Feb 2009 05:02:31 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5D0CF3A6909 for ; Thu, 5 Feb 2009 05:02:31 -0800 (PST) Received: from [172.17.139.184] ([12.46.252.162]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n15D1vpN063908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 06:02:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA4187A850F@zrtphxm2.corp.nortel.com> <185643.47042.qm@web82605.mail.mud.yahoo.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92@il-ex01.ad.checkpoint.com> Date: Thu, 5 Feb 2009 08:00:20 -0500 To: Yaron Sheffer , gabriel montenegro , Dragan Grebovich , Yoav Nir , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 13:02:32 -0000 At 9:52 AM +0200 2/5/09, Yaron Sheffer wrote: >Hi Gabriel, > >This thread is precisely the discussion that Paul mentions. > >The two alternatives I see on the table right now (Paul might have different opinions) are: > >- Publish a modified/wrapped ESP as Standards Track, and heuristics as an extra Informational. >- Decide that heuristics are a sufficient solution for the problem, and publish it as the only ipsecme work item related to this charter item. > >Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze. I fully agree with Yaron on all counts. If the WG thinks that heuristics is sufficient, we should not publish a protocol change. If the WG doesn't think heuristics are sufficient, the authors can publish it as an individual submission or an independent submission. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Feb 5 05:06:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2AF3A6AFE for ; Thu, 5 Feb 2009 05:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWboyZovbvcH for ; Thu, 5 Feb 2009 05:06:08 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BBF363A6909 for ; Thu, 5 Feb 2009 05:06:07 -0800 (PST) Received: from [172.17.139.184] ([12.46.252.162]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n15D5h7T064144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Feb 2009 06:05:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18826.56539.51447.845755@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8A@il-ex01.ad.checkpoint.com> <18826.56539.51447.845755@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2009 08:05:41 -0500 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:06:09 -0000 [[ Changed the subject line because Tero didn't. No other changes. ]] At 2:34 PM +0200 2/5/09, Tero Kivinen wrote: > > IKEv2-bis >> Issue #11: Clarify which traffic selectors to use in rekeying. >> Paul: [unclear]. Tero: if you have SAs that violate the new >> policy, you either delete them or you rekey. Prefers a rekey, >> even if this is narrowing the SA. Mostly useful for decorrelated >> policies, but people are not doing that yet [general agreement by >> silence]. Gives an example of a specific connection moving from >> one SA to another, which he says is a policy change that requires >> a rekey, but only if you're doing decorrelated policy. > >The example I gave was that we have IPsec SA between two hosts (or >subnets) and then someone adds new SPD rule which has higher >precedence and which says that port 80 between those hosts should be >put on separate SA. This effectively creates hole to the old IPsec SA, >thus the old IPsec SA now covers traffic selectors which it should >not. > >> Paul: if no-one is doing decorrelated policies, then they >> wouldn't have thought of this issue. Tero: some user >> interfaces may eliminate the need to support this feature >> altogether. > >There is three ways to do this: > >1) Forbid overlapping selectors (i.e. make user interface so that you > cannot enter overlapping traffic selectors, and require > adminstrator to "decorrelate" traffic selectors manually). > >2) Go through SPD entries in the precedence order and do not use any > kind of caching. This requires linear scan through SPD for every > single packet. > >3) Do the decorrelation properly and then you can use effective > datastuctures to find the correct SPD entry, i.e. no linear scan is > needed as you know that there cannot be any overlapping SPD entries > in the decorrelated policy. >-- >kivinen@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From Paul_Koning@Dell.com Thu Feb 5 08:22:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5133A6AFE for ; Thu, 5 Feb 2009 08:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Cp+8vNOXM9B for ; Thu, 5 Feb 2009 08:22:28 -0800 (PST) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by core3.amsl.com (Postfix) with ESMTP id 1567B3A69FF for ; Thu, 5 Feb 2009 08:22:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,386,1231135200"; d="scan'208";a="371007034" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 05 Feb 2009 10:22:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18827.4652.53691.761109@gargle.gargle.HOWL> Date: Thu, 5 Feb 2009 11:22:04 -0500 From: Paul Koning To: ynir@checkpoint.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 05 Feb 2009 16:22:06.0013 (UTC) FILETIME=[E2C086D0:01C987AD] Cc: ipsec@ietf.org, kivinen@iki.fi Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:22:29 -0000 >>>>> "Yoav" == Yoav Nir writes: >> > Did you encounter any major technical problems (e.g. one >> person's > corporate firewall prevented him from joining)? >> >> Our corporate firewall did block teamspeak ports, but as I knew >> about this beforehand, I was able to get the firewall rules >> changed so that the teamspeak could be used. Yoav> Not everyone has that kind of clout. Agreed. A good assumption is "if it's not port 80 it is blocked and that block is not subject to debate or negotiation". That way you will accommodate participants from companies where the security procedures are either too strict or too slow to "get the firewall rules changed". paul From ken.grewal@intel.com Thu Feb 5 08:38:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE803A6867 for ; Thu, 5 Feb 2009 08:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ph1vF18Z6S6C for ; Thu, 5 Feb 2009 08:37:49 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id F14AF3A6826 for ; Thu, 5 Feb 2009 08:37:48 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 05 Feb 2009 08:31:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,386,1231142400"; d="scan'208,217";a="428466375" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by fmsmga002.fm.intel.com with ESMTP; 05 Feb 2009 08:33:42 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Thu, 5 Feb 2009 09:37:25 -0700 From: "Grewal, Ken" To: Yaron Sheffer , Yoav Nir , Dragan Grebovich , "ipsec@ietf.org" Date: Thu, 5 Feb 2009 09:37:00 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcAAVKchAAB4yxHAAEUTTwA== Message-ID: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCAB@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCAB@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF2C73rrsmsx505amrcor_" MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 16:38:00 -0000 --_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF2C73rrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By a 'colluding peer', I meant that both sides need to negotiate the same p= olicy (e.g. this is sensitive data, so only allow encrypted traffic or vice= versa). I think this boils down to how tight the admin policy is and also whether i= t is desirable to allow encrypted/clear policies for different services to = the same server/cluster, which could result in the unintentionally attack I= described below. Thanks, - Ken ________________________________ From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Thursday, February 05, 2009 12:45 AM To: Grewal, Ken; Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Hi Ken, Yoav, I agree with Ken that the policy needs not be black and white, but for a di= fferent reason. Some people will treat deep packet inspection by middleboxe= s as an optional service: you want it for most traffic, but some traffic is= too sensitive and you choose to prioritize confidentiality over malware pr= otection. This model is definitely susceptible to attacks by infected endpoints that = can control the IPsec stack, and e.g. attack a server using encrypted traff= ic. You don't really need a "colluding" peer - most peers will probably acc= ept either an ESP-null or an ESP-encrypted proposal. But admins may be will= ing to take this risk. Thanks, Yaron ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G= rewal, Ken Sent: Wednesday, February 04, 2009 20:25 To: Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Quote ... "Our use case is an edge device that inspects all traffic, and drops things= it doesn't understand, such as non-NULL ESP and possibly SSL (they might m= ake an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, dr= op ESP-encrypted), as traffic patterns will be mixed in reality (encrypted = Vs. clear) and policy will dictate how a given traffic stream in inspected = and if it is opaque then take the associated action (drop / bypass / apply = QOS rules / send a different path in the network / etc...). e.g. There may = be a secure channel to transfer highly sensitive data (e.g. payroll, compan= y secrets, etc.) which should be encrypted and it may be undesirable to cat= egorize this under a general rule - this is a simple extension of the firew= all function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a= later stage uses ESP-Encrypted may also be possible unintentionally. E.g. = Connection to a server (cluster / farm) to gain access to a 'normal' servic= e uses ESP-NULL and then at a later stage, where the previous connection wa= s torn down and a new one built, the connection is obtaining some sensitive= data and is now using ESP-Encrypted. On the outside, the connection attrib= utes look the same (same server IP, same client IP (but may be different cl= ient due to NAT), same SPI - SPIs can be reused for new connections to pres= erve fast lookups algorithms at recipients), but underneath the connection = is to access a different resource (may be using a different port or service= above the IP layer). If the intermediate device has a cached rule (based o= n the previous connection) indicating the traffic is clear, it will lead to= falsely inferring the contents of the payload and undesirable results. Thi= s goes to my point on cache eviction policy for heuristics based intermedia= te devices, as highlighted in a separate thread. Reuse of the same 'tuple' = with different traffic characteristics may be infrequent, but still plausib= le. I agree with Yoav that this attack may also be possible intentionally betwe= en two colluding parties, where the policy indicates all traffic is ESP-NUL= L. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/di= fferent policy enforcement. I believe/agree that traffic visibility will matter only to a subset of tra= ffic, but that is enforced at each appliance level, or on a more granular (= per interface) level. Not all devices have to be capable of doing it, howe= ver if they are tasked to do it, they have to be able to scale and perform = transparently and quickly. Therefore, if heuristics are turned on, all tra= ffic will be subject to inspection (heuristic or deterministic), and then r= esource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe yo= ur statement actually supports my point. When a packet hits a decision poi= nt, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forw= arded packets were always forwarded and no action was performed on the cont= ent. Now we may want to turn on a policy to inspect packet content which i= s not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If c= leartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't = do anything with it - pass (preferrably) or drop (if policy insists, but I = doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implemen= tation-specific choice whether it is deterministic or heuristic inspection = to make a call. I need to make a call if it would take a few instructions = or a chunk of code, potentially with some % of false-positives or false neg= atives. Again, I agree with you it may be "tweaked" to be close to 0%, ho= wever each additional discrimination requires more code, more cpu and more = time to execute (latency). I am concerned that on large (high-end) devices= this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don= 't agree with what you wrote in #4. If the appliance is willing to pass ESP= -non-NULL, then it doesn't really care about content inspection. That is fi= ne, and probably the more common case, but in that case it shouldn't care w= hether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things = it doesn't understand, such as non-NULL ESP and possibly SSL (they might ma= ke an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular ins= pection 3. Is the process ESP with an SPI and endpoints that have already determi= ned to be NULL?: If so, skip to the payload and inspect. Note that this is = a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL,= and then after the heuristics marked it as OK, begin encryption. This "att= ack" will work if all your policy says is "ESP must be NULL". But that is n= ot an interesting policy. Real policies will require deeper inspection of t= he internal flows, so the cost of the heuristics becomes negligible, as it = only requires looking at the first few packets of each ESP SA. Email secured by Check Point Email secured by Check Point --_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF2C73rrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-esp-null-heuristics comments

By a ‘colluding peer’, I m= eant that both sides need to negotiate the same policy (e.g. this is sensitive data, so on= ly allow encrypted traffic or vice versa).

I think this boils down to how tight t= he admin policy is and also whether it is desirable to allow encrypted/clear policies for different services to the same server/cluster, which could res= ult in the unintentionally attack I described below.  

 

<= span style=3D'font-size:12.0pt;color:navy'>Thanks,

<= span style=3D'font-size:12.0pt;color:navy'>- Ken

 

From: Yaron Sh= effer [mailto:yaronf@checkpoint.com]
Sent: Thursday, February 05,= 2009 12:45 AM
To: Grewal, Ken; Yoav Nir; Dragan Grebovich; ipsec@ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Hi Ken, Yoav,=

 

I agree with Ken that the policy needs= not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for mo= st traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection.

 

This model is definitely susceptible t= o attacks by infected endpoints that can control the IPsec stack, and e.g. at= tack a server using encrypted traffic. You don’t really need a “coll= uding” peer – most peers will probably accept either an ESP-null or an ESP-encrypted proposal. But admins may be willing to take this risk.

 

Thanks,

      &n= bsp;     Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Grewal, Ken
Sent: Wednesday, February 04= , 2009 20:25
To: Yoav Nir; Dragan Grebovich; ipsec@= ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Quote …=

“= Our use case is an edge device that inspects all traffic, and drops things it doesn= 't understand, such as non-NULL ESP and possibly SSL (they might make an excep= tion for HTTPS, but do a MiTM attack against the SSL)

”

I do not think a typical policy will b= e black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns w= ill be mixed in reality (encrypted Vs. clear) and policy will dictate how a giv= en traffic stream in inspected and if it is opaque then take the associated ac= tion (drop / bypass / apply QOS rules / send a different path in the network / etc…). e.g. There may be a secure channel to transfer highly sensitiv= e data (e.g. payroll, company secrets, etc.) which should be encrypted and it may = be undesirable to categorize this under a general rule – this is a simpl= e extension of the firewall function.

 

The ‘bait and switch’ atta= ck where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may a= lso be possible unintentionally. E.g. Connection to a server (cluster / farm) t= o gain access to a ‘normal’ service uses ESP-NULL and then at a l= ater stage, where the previous connection was torn down and a new one built, the connec= tion is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same clie= nt IP (but may be different client due to NAT), same SPI – SPIs can be r= eused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device h= as a cached rule (based on the previous connection) indicating the traffic is cl= ear, it will lead to falsely inferring the contents of the payload and undesirab= le results. This goes to my point on cache eviction policy for heuristics base= d intermediate devices, as highlighted in a separate thread. Reuse of the sam= e ‘tuple’ with different traffic characteristics may be infrequen= t, but still plausible.

 

I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the pol= icy indicates all traffic is ESP-NULL.

 

<= span style=3D'font-size:12.0pt;color:navy'>Thanks,

<= span style=3D'font-size:12.0pt;color:navy'>- Ken

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, February 04= , 2009 12:04 AM
To: Dragan Grebovich; ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments=

 

Dragan Grebovich wrote:

Yoav

 

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement.&n= bsp;

 

I believe/agree that traffic visibilit= y will matter only to a subset of traffic, but that is enforced at each appli= ance level, or on a more granular (per interface) level.  Not all devi= ces have to be capable of doing it, however if they are tasked to do it, they h= ave to be able to scale and perform transparently and quickly.  Therefore,= if heuristics are turned on, all traffic will be subject to inspecti= on (heuristic or deterministic), and then resource consumption matter.

 

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following h= as to be determined asap:

 

   1) Is the packet terminated here or am I to forward it?  Until now, forward= ed packets were always forwarded and no action was performed on the content.&n= bsp; Now we may want to turn on a policy to inspect packet content which is= not terminated here.

   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...

   3) Is it AH or ESP?  This is quick and trivial too ...

   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). 

 

IMHO for each packet we have to perfor= m the four steps.  It is the implementation-specific choice whether it = is deterministic or heuristic inspection to make a call.  = I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cp= u and more time to execute (latency).  I am concerned that on large (hig= h-end) devices this may take an unacceptably large toll.

 

Dragan <= /p>

I don't think the use case is to inspe= ct every packet like that. I also don't agree with what you wrote in #4. = If the appliance is willing to pass ESP-non-NULL, then it doesn't really care = about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted.=

 

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-N= ULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

 

So for each packet, the processing is something like this:

  1. Is the pr= otocol non-IPsec? if so, do the regular inspection
  2. Is the protoco= l AH? if so,  skip to the payload and do the regular inspection<= /font>
  3. Is the process= ESP with an SPI and endpoints that have already determined to be NULL?: If= so, skip to the payload and inspect. Note that this is a simple table look= up
  4. Is this a new = ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoi= nts to cheat, start of with ESP-NULL, and then after the heuristics marked it a= s OK, begin encryption. This "attack" will work if all your policy = says is "ESP must be NULL". But that is not an interesting policy. Rea= l policies will require deeper inspection of the internal flows, so the cost = of the heuristics becomes negligible, as it only requires looking at the first= few packets of each ESP SA.



Email secured by Check Point



Email secured by Check Point

--_000_C49B4B6450D9AA48AB99694D2EB0A4830CDF2C73rrsmsx505amrcor_-- From ken.grewal@intel.com Thu Feb 5 08:44:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B8B3A69BD for ; Thu, 5 Feb 2009 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 krKSH4EDVhmG for ; Thu, 5 Feb 2009 08:44:07 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 94A973A6990 for ; Thu, 5 Feb 2009 08:44:07 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 05 Feb 2009 08:38:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,386,1231142400"; d="scan'208";a="428468197" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga002.fm.intel.com with ESMTP; 05 Feb 2009 08:39:51 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Thu, 5 Feb 2009 09:43:37 -0700 From: "Grewal, Ken" To: Paul Koning , "ynir@checkpoint.com" Date: Thu, 5 Feb 2009 09:43:13 -0700 Thread-Topic: [IPsec] Feedback on the interim session's format Thread-Index: AcmHreuZfef+dHJdT8qEEOgAtAja0wAApeaQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> <18827.4652.53691.761109@gargle.gargle.HOWL> In-Reply-To: <18827.4652.53691.761109@gargle.gargle.HOWL> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "kivinen@iki.fi" Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:44:08 -0000 I had the same problem with our corporate firewall and had to take the call= from home and then cut off early to allow for travel time back to office b= efore the next meeting.=20 If there are alternatives that would allow operation over 'well known' port= s such as 80, then those would be preferable. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Paul Koning >Sent: Thursday, February 05, 2009 8:22 AM >To: ynir@checkpoint.com >Cc: ipsec@ietf.org; kivinen@iki.fi >Subject: Re: [IPsec] Feedback on the interim session's format > >>>>>> "Yoav" =3D=3D Yoav Nir writes: > > >> > Did you encounter any major technical problems (e.g. one > >> person's > corporate firewall prevented him from joining)? > >> > >> Our corporate firewall did block teamspeak ports, but as I knew > >> about this beforehand, I was able to get the firewall rules > >> changed so that the teamspeak could be used. > > Yoav> Not everyone has that kind of clout. > >Agreed. A good assumption is "if it's not port 80 it is blocked and >that block is not subject to debate or negotiation". > >That way you will accommodate participants from companies where the >security procedures are either too strict or too slow to "get the >firewall rules changed". > > paul > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From DRAGAN@nortel.com Thu Feb 5 09:45:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C593A69F9 for ; Thu, 5 Feb 2009 09:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JixeAgKGEEUy for ; Thu, 5 Feb 2009 09:45:48 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 4C8873A6B24 for ; Thu, 5 Feb 2009 09:45:47 -0800 (PST) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n15HjO615618; Thu, 5 Feb 2009 17:45:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C987B9.7D066E86" Date: Thu, 5 Feb 2009 12:45:08 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4187EE433@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmFq7RIiu+UzqsPQJGQ3MCPrFmJ8wAOhlRQAAVDsuAAKILMcAAVKchAAB4yxHAAEUTTwAAB9AqQ References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com><9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com><34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com><9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCAB@il-ex01.ad.checkpoint.com> From: "Dragan Grebovich" To: "Grewal, Ken" , "Yaron Sheffer" , "Yoav Nir" , Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Thu, 05 Feb 2009 17:45:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C987B9.7D066E86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I looked for some traffic stats in a real, large enterprise network and I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The stats were measured on multiple places in the network, and multiple samples were taken over the past 6 weeks. Also, there is a slow but consistent growth of UDP traffic over the past couple of years, pointing to a long term trend. =20 IMHO heuristics would require more frequent inspections than just the first few packets in a flow, and would require more heuristics rules on a per app basis, instead of relying on fixed TCP immutable fields. =20 =20 ------_=_NextPart_001_01C987B9.7D066E86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-kivinen-i= psecme-esp-null-heuristics comments
I looked for some traffic stats in = a real,=20 large enterprise network and I found that UDP comprises = 25-30% vs. TCP 70-75% of all traffic.  The stats = were measured on=20 multiple places in the network, and multiple samples were taken over the = past 6=20 weeks.  Also, there is a slow but consistent growth of = UDP=20 traffic over the past couple of years, pointing to a long term=20 trend.
 
IMHO heuristics would require more = frequent=20 inspections than just the first few packets in a flow, and would require = more=20 heuristics rules on a per app basis, instead of relying on fixed TCP = immutable=20 fields.
 
 
------_=_NextPart_001_01C987B9.7D066E86-- From paul.hoffman@vpnc.org Thu Feb 5 17:40:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FC43A6987 for ; Thu, 5 Feb 2009 17:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keVazqTtNwHD for ; Thu, 5 Feb 2009 17:40:10 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D5F993A6A2C for ; Thu, 5 Feb 2009 17:40:09 -0800 (PST) Received: from [172.17.139.184] ([12.46.252.162]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n161e0a9008458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 18:40:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> <18827.4652.53691.761109@gargle.gargle.HOWL> Date: Thu, 5 Feb 2009 20:39:59 -0500 To: "Grewal, Ken" , Paul Koning , "ynir@checkpoint.com" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , "kivinen@iki.fi" Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 01:40:11 -0000 At 9:43 AM -0700 2/5/09, Grewal, Ken wrote: >If there are alternatives that would allow operation over 'well known' ports such as 80, then those would be preferable. Not necessarily. There are likely to be folks who have firewalls that inspect what goes on port 80 and, seeing non-HTTP gibberish, will block the connection. For a future meeting, we have the option of going to a dial-in number, but that will be quite expensive for people outside the US, as well as for many people inside the US. We do not know how to make the tradeoff between that and the port-blocked issue. Please feel free to continue this thread with discussion of how onerous it would be to make an occasional two-hour call to a local number in the US. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Fri Feb 6 03:15:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881683A6A77 for ; Fri, 6 Feb 2009 03:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 CGCtP6gcFGp1 for ; Fri, 6 Feb 2009 03:15:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 856683A685D for ; Fri, 6 Feb 2009 03:15:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n16BFYvC006338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 13:15:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n16BFWBG016162; Fri, 6 Feb 2009 13:15:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18828.7124.253137.851977@fireball.kivinen.iki.fi> Date: Fri, 6 Feb 2009 13:15:32 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> <18827.4652.53691.761109@gargle.gargle.HOWL> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: "ipsec@ietf.org" , Paul Koning , "ynir@checkpoint.com" Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 11:15:45 -0000 Grewal, Ken writes: > If there are alternatives that would allow operation over 'well > known' ports such as 80, then those would be preferable. As most of those voice systems do use UDP, even using well known port 80 does not help as it is only open for TCP traffic. Running voice over tcp gets quite poor results, especially if your connection might drop few packets. -- kivinen@iki.fi From kivinen@iki.fi Fri Feb 6 03:19:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695273A6A8C for ; Fri, 6 Feb 2009 03:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 uEM1JJ0-ij8g for ; Fri, 6 Feb 2009 03:19:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 384E63A6A55 for ; Fri, 6 Feb 2009 03:19:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n16BJHWc000963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 13:19:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n16BJHkB021440; Fri, 6 Feb 2009 13:19:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18828.7349.35249.95374@fireball.kivinen.iki.fi> Date: Fri, 6 Feb 2009 13:19:17 +0200 From: Tero Kivinen To: "Dragan Grebovich" In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4187EE433@zrtphxm2.corp.nortel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCAB@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA4187EE433@zrtphxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org, Yoav Nir , "Grewal, Ken" Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:19:20 -0000 Dragan Grebovich writes: > I looked for some traffic stats in a real, large enterprise network and > I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The > stats were measured on multiple places in the network, and multiple > samples were taken over the past 6 weeks. Also, there is a slow but > consistent growth of UDP traffic over the past couple of years, pointing > to a long term trend. Can you provide information what kind of UDP traffic that was? I would except DNS, and different voip protocols, but what else? > IMHO heuristics would require more frequent inspections than just the > first few packets in a flow, and would require more heuristics rules on > a per app basis, instead of relying on fixed TCP immutable fields. For heuristics it is enough to do just to inspect first few packets. After we have found out the parameters, then we just use them. The deep inspection that is using the results of the heuristics (i.e. to find the actual protocol data) will of course need to inspect every packet. -- kivinen@iki.fi From ken.grewal@intel.com Fri Feb 6 14:54:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BE43A6A00 for ; Fri, 6 Feb 2009 14:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJW9Mwgjb8fq for ; Fri, 6 Feb 2009 14:54:35 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 234BA3A6C3A for ; Fri, 6 Feb 2009 14:54:35 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 06 Feb 2009 14:50:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,394,1231142400"; d="scan'208";a="384773699" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by orsmga002.jf.intel.com with ESMTP; 06 Feb 2009 15:03:34 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 6 Feb 2009 15:54:37 -0700 From: "Grewal, Ken" To: Tero Kivinen Date: Fri, 6 Feb 2009 15:54:20 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmHiQSCCUVMXQehT8KjtIl/rquMeABIUBMw Message-ID: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> In-Reply-To: <18826.54339.452491.244002@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 06 Feb 2009 22:54:36 -0000 Additional comment below... ...Snip... >> Cache eviction - how will this work? >> We can keep adding SAs (based on heuristics), but how do we decide >> when a given SA is no longer needed? This compounds the issues with >> keeping state, as in the best case, cache eviction will likely be >> policy based. How is the policy determined and how do we >> differentiate between short and long lived SAs? As the SA cache will >> be of a finite size, this WILL lead to a cache thrash (add SA, evict >> SA, ...), causing further resource consumption. > >This is actually quite good point, and it is also implementation >detail that do affect the performance. > >How this can be solved depends quite heavily on the environment where >heuristics is used. If we are doing firewall that already keeps state >of all TCP/UDP flows, then it would be natural to weakly bind IPsec >SAs and TCP/UDP flows inside together. For example keep in track when >there is no more TCP/UDP flows using the IPsec SA (i.e. all the >TCP/UDP flows which used this SA before, have now been moved to new >IPsec SA), and after that you can most likely remove the IPsec SA >entry quite quickly. [Ken] This may be feasible for stateful devices, but does not work for stat= eless devices (QOS/Statistics/auditing functions). Even in stateful devices= , it requires coupling between observation on flows and the associated heur= istics cache engine, which creates an additional overhead.=20 > >Another, and probably more common implementation will be just some >simple LRU based mechanisms to reuse old IPsec SA entries. This kind >of things are usually already done for the UDP protocols. [Ken] These require timestamps (or other ordering / metric based approaches= ) and monitoring to ensure the cache is up to date. Furthermore, it may als= o provide opportunities for adversaries to use periodic replays to provide = cache thrash and associated overhead in re-executing heuristics engines.=20 I am not convinced that SW based solutions will scale 10Gbps solutions, let= alone future 40/100Gbps bandwidth requirements, especially at these networ= k 'choke' points, so a HW orientated solution may be desirable...which brin= gs us back to cost/complexity... > >> How about dynamic route changes for already established SAs? The >> same problem will exist as the Monday morning problem, but without >> the diffie-hellman overhead. Because we are caching state on one >> device, a change in route where the packets take a different path >> will force the new device to 'relearn' all the cached info. > >Yes, but heuristics is still fast operation, thus that should not be >problem. Bigger problem usually is that the deep inspection state is >lost too... [Ken] But not for stateless devices, which will carry the 'resync/Monday mo= rning problem' each time. > >> High availability is another one to consider, especially during >> maintenance periods. One device is powered down and a backup device >> takes over. This is similar to route changes in principle, where the >> backup device will need to relearn all the state. > >As here the heuristics is run on the same device which is running the >deep inspection, they do already require methods of transferring that >deep inspection state from one device to another, and moving the IPsec >SPI cache state at the same time should not be a problem. [Ken] But again, this is additional work, which can be avoided if we have n= o state. > >> Agree, but the heuristics engine may be heavily used as VOIP becomes >> prevalent, especially within the Enterprise. Lots and lots of UDP >> traffic that is short lived, which ties back to earlier points on >> cache maintenance and frequency of exercising the heuristics engine. > >If we know anything about the contents of the UDP packet (i.e. >recognize that it is VOIP traffic), we can most likely do heuristics >based on the single packet. Even if there is only 32 bits of the known >data in the packet (lets say version number and magic cookie or >similar), then usually that is already enough for detecting the >parameters and the probability that random ESP-encrypted packet has >same content is less than 0.000000024% (1/(2^32) * 100%). > >So if VOIP traffic is heavily used then the heuristics most likely >will have special protocol detection code for it. [Ken] The point being that this traffic may be short lived, smaller packet,= hence more packet per bandwidth, which will exercise the heuristics engine= / cache issues much more then, say long lived TCP sessions (which are rare= ).=20 > >> Auditing / logging / sniffing / sampling are some examples of >> stateless devices that do require to peek in the packets. Probably >> lots more also, so look for others to provide examples... > >As those do not affect the forwarding of the packet, then the >reliability requirements for them is much lower, meaning that they can >also work without storing any state, and running heuristics for per >packet basis. That of course do require implementing the heuristics on >the hardware if we are talking about gigabit links or faster. My guess >is that without any hardware support and only using software with >modern CPU you can probably process more than 100MBit/s, but most >likely not full 1GBit/s speed. [Ken] Agreed on the need to implementing heuristics in HW, but this contrad= icts the original 'benefit' of heuristics, where heuristics engine can be r= un in SW and a resultant cache entry stored in HW. Adding an ever changing = set of rules + heuristics engine is a non-starter - at least that is the fe= edback I am getting from the HW engineers I have spoken with - mucho comple= xity + cost! > >Of course if you are talking about very low cost appliances, then they >will not have modern CPUs, but on the other hand people do not >normally expect them to keep up with 1GBit/s speeds... > >> The speed of deployment may or may not be true. If the stars are >> aligned, then it could be deployed within one or two refresh cycles, >> which is about the same for heuristics in intermediaries devices. >> After all, only a handful of vendors own a large percentage of the >> market for OS / intermediary devices. Adoption is obviously based on >> customer pull/perceived usefulness. > >The difference is that heuristics can be deployed within one or two >refresh cycles of the intermediate devices after customers start to >ask for it. > >Modified ESP can be deployed within one or two refresh cycles of the >slowest vendor whose devices are used in the network. > >Meaning that if the printer vendor used in the network does not update >their IPsec to support that modified ESP, then that modified ESP >cannot be used by intermediate devices. [Ken] There will always be a migration path, as well as exception cases. It= is much easier to add a static rule for a fixed printer, then to have dyna= mic rules to allowing encrypted data to pass through the network. Additiona= lly, some of the legacy devices may not even support a secure connection, s= o the traffic will be in the clear anyway. E.g. How many printers support I= Psec today? If they need to support this in the future, then it is just as = easy for them to support WESP, instead of ESP-NULL... > ...snip... [Ken] I think we need to consider all these issues in determining if a heur= istics solution will work and scale under ALL circumstances. By contrast, W= ESP does not have any of these issues (bar adoption), as it is being design= ed for efficiency, cost effectiveness and scalability. From yaronf@checkpoint.com Sat Feb 7 10:56:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739E13A6CD4 for ; Sat, 7 Feb 2009 10:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 DI9k4qPZFjDM for ; Sat, 7 Feb 2009 10:56:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 18E2E3A6CF2 for ; Sat, 7 Feb 2009 10:56:09 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7FB4729C006; Sat, 7 Feb 2009 20:56:12 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 52DEB29C004; Sat, 7 Feb 2009 20:56:10 +0200 (IST) X-CheckPoint: {498DD90E-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n17Iu9ei017194; Sat, 7 Feb 2009 20:56:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 7 Feb 2009 20:56:09 +0200 From: Yaron Sheffer To: gabriel montenegro , Paul Hoffman , Dragan Grebovich , Yoav Nir , "ipsec@ietf.org" Date: Sat, 7 Feb 2009 20:56:50 +0200 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmItho25lDK1fqPRC+wkMyDuQYCgwAnciUw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FE05@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B597@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA418762175@zrtphxm2.corp.nortel.com> <9FB7C7CE79B84449B52622B506C78036130846B6BC@il-ex01.ad.checkpoint.com> <34B3EAA5B3066A42914D28C5ECF5FEA4187A850F@zrtphxm2.corp.nortel.com> <185643.47042.qm@web82605.mail.mud.yahoo.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC92@il-ex01.ad.checkpoint.com> <956627.7735.qm@web82604.mail.mud.yahoo.com> In-Reply-To: <956627.7735.qm@web82604.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Sat, 07 Feb 2009 18:56:11 -0000 Hi Gabriel, Since we are still in the midst of technical discussion, I am perfectly wil= ling to wait a few more days and then directly ask Tero and Dan, as well as= other supporters of the heuristics approach, for their opinion in the matt= er. I believe this would be more fruitful than interpreting the wording of = their draft. In the meantime, I'd like to focus on this technical discussio= n and ensure that we've explored as many issues as we can. Thanks, Yaron > -----Original Message----- > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > Sent: Saturday, February 07, 2009 1:53 > To: Paul Hoffman; Yaron Sheffer; Dragan Grebovich; Yoav Nir; > ipsec@ietf.org > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > Thanks for the clarification. If I could ask for further clarification > here: is there much support > for the claim that heuristics is sufficient for ALL scenarios now and in > the future > (approach #2 as noted by the chairs below)? > > The reason I ask is that Tero/Dan themselves don't seem to espouse this > view. > At least that is what their draft says in the introduction: > > To make sure that any solution does not break in the > future it would be best if such heuristics are documented, i.e. we > need to publish an RFC for what to do now even when there might be a > new protocol coming in the future that will solve the same problem > better. > This talks about co-existence of heuristics with another approach > (presumably deterministic), > which is the approach #1 as noted by the chairs below. > > I agree with approach #1, of course, so was glad to see that in Tero's > draft, but > would like to be corrected if somehow I'm misreading the above text. > > thanks, > > Gabriel > > > > ----- Original Message ---- > > From: Paul Hoffman > > To: Yaron Sheffer ; gabriel montenegro > ; Dragan Grebovich ; Yoav Ni= r > ; "ipsec@ietf.org" > > Sent: Thursday, February 5, 2009 5:00:20 AM > > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > > > At 9:52 AM +0200 2/5/09, Yaron Sheffer wrote: > > >Hi Gabriel, > > > > > >This thread is precisely the discussion that Paul mentions. > > > > > >The two alternatives I see on the table right now (Paul might have > different > > opinions) are: > > > > > >- Publish a modified/wrapped ESP as Standards Track, and > heuristics as > > an extra Informational. > > >- Decide that heuristics are a sufficient solution for the > problem, > > and publish it as the only ipsecme work item related to this charter > item. > > > > > >Paul and I would like to see more discussion and hopefully WG consensu= s > being > > formed, now that we have a real heuristics I-D for everyone to analyze. > > > > I fully agree with Yaron on all counts. If the WG thinks that heuristic= s > is > > sufficient, we should not publish a protocol change. If the WG doesn't > think > > heuristics are sufficient, the authors can publish it as an individual > > submission or an independent submission. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point From jeanmichel.combes@gmail.com Mon Feb 9 02:32:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E6A3A6B68 for ; Mon, 9 Feb 2009 02:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f14la46sidmf for ; Mon, 9 Feb 2009 02:32:11 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id D5FE73A6A66 for ; Mon, 9 Feb 2009 02:32:10 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so1021388fgb.41 for ; Mon, 09 Feb 2009 02:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gp9Hjtz0zDj/wAMLEEUzDN4aoOLCP2oa2JUPXX54bXM=; b=UBn07T2ZUtBT9Z8hxICuxcmrvBEMkMd/I7QB2/fbHGbSTWF42EM8WTskMz5v2JVxc7 XZC58+zhBIXfMX+OH2WGO+yVXz48kRTf8ebv/hr2gpIg+uNK7r1EPj5GlEUJgm8G/Z4p 0v5IhWD9+FhDCAQPvVGwzsND7BP1rYSByK5rY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X1IQUedSIKvLRTpsz10L87/pDPizXqCzqVMGWeiC1hVTcYgcM1u9lwbRTtT5tpKbDv BZGVeqAatpbL8xR7jcQhD9wMIzBsZl3E8ECNNfSsqV5z6bCIEcSpMrGTqivnV60a+vu6 ERk1uct0brqxkwXKC5UrYPZ4lnpXklKwsqv3E= MIME-Version: 1.0 Received: by 10.86.95.20 with SMTP id s20mr2604312fgb.43.1234175534657; Mon, 09 Feb 2009 02:32:14 -0800 (PST) In-Reply-To: <18828.7124.253137.851977@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC7A@il-ex01.ad.checkpoint.com> <18826.55660.517420.835024@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B87F@il-ex01.ad.checkpoint.com> <18827.4652.53691.761109@gargle.gargle.HOWL> <18828.7124.253137.851977@fireball.kivinen.iki.fi> Date: Mon, 9 Feb 2009 11:32:14 +0100 Message-ID: <729b68be0902090232w17377122uf7c07d0d2dcb8f5e@mail.gmail.com> From: Jean-Michel Combes To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Paul Koning , "ynir@checkpoint.com" , "Grewal, Ken" Subject: Re: [IPsec] Feedback on the interim session's format X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 10:32:12 -0000 Hi, Maybe, an alternative solution could be Mumble (http://mumble.sourceforge.net/Main_Page) which I use generally now (from my point of view, the sound on Mumble is clearer than on TS). BTW, it seems that it is possible to use Mumble with TCP (cf. FAQ). Hope that helps. Best regards. JMC. 2009/2/6 Tero Kivinen : > Grewal, Ken writes: >> If there are alternatives that would allow operation over 'well >> known' ports such as 80, then those would be preferable. > > As most of those voice systems do use UDP, even using well known port > 80 does not help as it is only open for TCP traffic. Running voice > over tcp gets quite poor results, especially if your connection might > drop few packets. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Mon Feb 9 06:19:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293DC3A6C17 for ; Mon, 9 Feb 2009 06:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 IDaHwNRrnnCN for ; Mon, 9 Feb 2009 06:19:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A4C313A6C11 for ; Mon, 9 Feb 2009 06:19:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n19EJtcY006175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 16:19:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n19EJsbx029064; Mon, 9 Feb 2009 16:19:54 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18832.15242.707313.57888@fireball.kivinen.iki.fi> Date: Mon, 9 Feb 2009 16:19:54 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 79 min X-Total-Time: 110 min Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Mon, 09 Feb 2009 14:19:56 -0000 Grewal, Ken writes: > [Ken] This may be feasible for stateful devices, but does not work > for stateless devices (QOS/Statistics/auditing functions). Even in > stateful devices, it requires coupling between observation on flows > and the associated heuristics cache engine, which creates an > additional overhead. As the draft says this is mostly meant for stateful devices, and that has been the main goal for the document. The charter says: "A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system ..." I.e. the main goal was set to be on the devices doing deeper inspection i.e. firewalls and intrusion detection systems. At least my conclusion on the list when we discussed on the usage cases were for that kind of stateful devices. Are QOS and auditing devices really stateless? I would expect QOS devices to have all kind of reservation systems and so on and for those I would expect them to be keeping state? For the auditing I have been using I have usually enabled auditing of new connections, not all packets, thus all my auditing systems I have set up have been keeping state. What kind of usage is completely stateless auditing devices used for your example of 10Gbps links? Statistics devices could even be stateless, but is that really something we should aim for? I.e. to wait for 5-10 years before we can use our stateless statistics devices, compared to use stateful statistics devices for doing the thing this or next year. > [Ken] These require timestamps (or other ordering / metric based > approaches) and monitoring to ensure the cache is up to date. Stateful devices do already have all that. > Furthermore, it may also provide opportunities for adversaries to > use periodic replays to provide cache thrash and associated overhead > in re-executing heuristics engines. As far as I have understood we are still talking about the inside one enterprice network, not internet as whole. If they do have untrusted users inside (i.e. attackers), they should enable encryption, thus all this is not really a point. As ESP-NULL does not offer confidentiality it can only be used in trusted environments, where the denial-of-service attacks against the device in the middle should not be big problem. > I am not convinced that SW based solutions will scale 10Gbps > solutions, let alone future 40/100Gbps bandwidth requirements, > especially at these network 'choke' points, so a HW orientated > solution may be desirable...which brings us back to > cost/complexity... Limits for software based heuristics are not really related to the line speed, but number of new IPsec connections per second going through the device. The line speed do affect the HW based flow cache lookup (i.e. the appendix A.1 fastpath part of the processing), but that is doable even at 10Gbps speed, as it basically does same thing as normal stateful firewall rules (i.e. fetch flow information based on IP address pair, protocol and in this SPI number instead of port numbers). > >As here the heuristics is run on the same device which is running the > >deep inspection, they do already require methods of transferring that > >deep inspection state from one device to another, and moving the IPsec > >SPI cache state at the same time should not be a problem. > > [Ken] But again, this is additional work, which can be avoided if we have no state. Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV len and IV len) per flow more when you transfer the whole deep inspection state from device to other (which might include whole TCP transmission window, which is around 64kB or so), so the increase of additional work is about 0.009% (actually it is normally even less, as TCP state is per TCP flow, and usually one IPsec flow has multiple TCP flows inside, but in this case I took the worst case scenario, where each IPsec flow have exactly one TCP flow inside). I do not really consider that to really be matter. (Doing deep inspection on TCP streams usually do require reconstructing TCP stream in fully including dropped and retransmitted packets. Otherwise there are attacks where you only inspect packet which never reaches the end node (attacker causes it to be dropped), and the retransmission packet is different than the first packet and if you let that pass to the end node, attacker managed to get uninspected packet through. Solution is that you either do the retransmissions from your internal data or you verify that retransmissions sent by the original node contains same data than original packet, both of them do require you keep the TCP transmission window data. This text is here just to explain that doing deep inspection (for IDS or IPS) on TCP stream is very costly operation and heuristics do have minimal cost compared to them.) > >> Auditing / logging / sniffing / sampling are some examples of > >> stateless devices that do require to peek in the packets. Probably > >> lots more also, so look for others to provide examples... > > > >As those do not affect the forwarding of the packet, then the > >reliability requirements for them is much lower, meaning that they can > >also work without storing any state, and running heuristics for per > >packet basis. That of course do require implementing the heuristics on > >the hardware if we are talking about gigabit links or faster. My guess > >is that without any hardware support and only using software with > >modern CPU you can probably process more than 100MBit/s, but most > >likely not full 1GBit/s speed. > > [Ken] Agreed on the need to implementing heuristics in HW, but this > contradicts the original 'benefit' of heuristics, where heuristics > engine can be run in SW and a resultant cache entry stored in HW. > Adding an ever changing set of rules + heuristics engine is a > non-starter - at least that is the feedback I am getting from the HW > engineers I have spoken with - mucho complexity + cost! I explained that IF you REQUIRE heuristics to run without state, then you most likely need to implement them on hardware if you need high speeds. I didn't mean to say anybody should try that, because I think it is cheaper to do it by adding state. I think doing heuristics on the software is completely ok and doable, for even very high speeds, when you do it in the smart way, i.e. use state. I would expect following implementations to be usable: 1) Keep state of the SPI information, doing slowpath heuristics on SW, and doing fastpath part on HW (any speed). 2) Keep state of the SPI information, doing slowpath heuristics on SW, and doing fastpath part on SW (most likely up to 1 GBit/s). If you insist on not using state, then you can most likely do full slowpath and fastpath on SW up to 100MBit/s speeds, and I do not really see any point of doing any hardware version as making versions 1 or 2 above make much more sense. If you really require very high new connection rate, i.e. for example you have 10Gbit/s link and it consists fully at IKEv2 creation (4 packets), TCP session creation (3 packets), 2 data packets, TCP session finish (4 packets), IKEv2 SA delete (2 packets), i.e. each IPsec SA only contains one TCP session, which only exchange one data packet. This means there is 15 packets in total 8 in one direction 7 in other. IKE packets around 236 + 236 + 208 + 208 (with minimal packet sizes for AES-SHA1, 1024 bit MODP, pre shared key) and 100 bytes for IKEv2 deletes, TCP SYN/FIN packets are 40 bytes, and data packets 40+64 bytes of data. So in total that means 1576 bytes and using ethernet framing that makes 2146 octets -> 17168 bits. Using 10Gbit/s link that means we can do 582479 such exchanges per second. For software implementation using 2GHz CPU that gives about 3400 cycles for doing the heuristics for the packet. That should be plenty for doing heuristics, as they do not really have any loops or other complicated operations. The one packet verification is around 10 loads from packet, and around 15-20 compares, and we might need to do that 6 times (for differet ICV/IV lengths), so in total we have at about max 60 loads and 90-120 compares plus some basic arithmetics. I would expect that 2GHz CPU should keep up to that speed. 2GHz CPU cannot keep up to the 10GBit/s line speed or do routing lookups for that speeds, but if routing and non-heuristics packets are processed by other hardware, one cpu should take care of the worst case heuristics. So even at 10Gbit/s line speeds I do not think you need hardware implementation of the slowpath heuristics part. > [Ken] There will always be a migration path, as well as exception > cases. It is much easier to add a static rule for a fixed printer, > then to have dynamic rules to allowing encrypted data to pass > through the network. Additionally, some of the legacy devices may > not even support a secure connection, so the traffic will be in the > clear anyway. All of the traffic is in the clear, as we are talking about ESP-NULL here. My draft offers even simplier solution if you are accepting that kind of solutions. It is mandated by policy option, then you do not need to run heuristics at all, you simply assume all packets are ESP-NULL, as that is mandated by policy, and those exception cases where this is not true, you handle by adding rules... > E.g. How many printers support IPsec today? Not sure, but I do know there are such out there, and even more will be (at least kyocera has announced their printers supporting IPsec and IPv6 http://www.fishers-boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_Combine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm). > If they need to support this in the future, then it is just as easy > for them to support WESP, instead of ESP-NULL... Might be but for PCs you normally do this by updating the operating system, how often have you updated the OS of your printer? And note that they already support ESP-NULL and with heuristics they do not need to update anything. With WESP they need to update their software. Most of those vendors do not have their own IPsec, but it might either come with the embedded operating system or it might be OEM toolkit, which requires them to get new version of that, and new features usually only comes with new versions (i.e. they are not part of the bug fixes provided for old versions), thus they would need to update to newer version of operating system or toolkit. As we do make IPsec OEM toolkit I can say that our customers have been very reluctant to update to latest versions after they get their pruducts out. there are still customers using 4 years old version. Some of them are luckily now looking for updating to latest versions for new products. I do not expect them to ever update their old devices for new versions. So if we make WESP it will come out most likely during 2010 (and we most likely do not make it unless there is customer demand for it (or for heuristics), which mean that it might get pushed forward by year or two), which will mean that some of our customers might delay up to 2015 before they update to that version, and after that it takes year or so before they get their devices out. > [Ken] I think we need to consider all these issues in determining if > a heuristics solution will work and scale under ALL circumstances. I do not think heuristics need to work in ALL circumstances. I think it needs to work in the circumstances we are aiming for, and by charter that is "an intermediary device, such as a firewall or intrusion detection system". Do you really consider stateless versions of those intermediary devices something that will be common in the future? > By contrast, WESP does not have any of these issues (bar adoption), > as it is being designed for efficiency, cost effectiveness and > scalability. The adoptation is big issue there. As my draft says even if we go for WESP, I think the intermediary device vendors still want to have some solution they can use now, thus they will still need to implement heuristics. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Feb 9 09:00:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2AF3A6944 for ; Mon, 9 Feb 2009 09:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZUvarU9oXhd for ; Mon, 9 Feb 2009 09:00:51 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0B1743A6857 for ; Mon, 9 Feb 2009 09:00:51 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8B34829C004; Mon, 9 Feb 2009 19:00:12 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5E48329C002 for ; Mon, 9 Feb 2009 18:59:11 +0200 (IST) X-CheckPoint: {49906092-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n19GxAv3021381 for ; Mon, 9 Feb 2009 18:59:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 9 Feb 2009 18:59:10 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 9 Feb 2009 18:59:26 +0200 Thread-Topic: Meeting minutes posted Thread-Index: AcmK18QdjZdZNcYsTYqy0sL0vW2A1A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD4F@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD4Filex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Meeting minutes posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:00:53 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD4Filex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have posted the interim meeting minutes (with Tero's corrections) on the = wiki: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203Minute= s Thanks, Yaron =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD4Filex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have posted the interim meeting minutes (with TeroR= 17;s corrections) on the wiki: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203Minutes=

 

Thanks,

         &n= bsp;  Yaron


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD4Filex01adcheck_-- From dvijay@gmail.com Mon Feb 9 10:16:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFE63A6B8D for ; Mon, 9 Feb 2009 10:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 9v3HVai82-9k for ; Mon, 9 Feb 2009 10:16:58 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id AA0423A6AFE for ; Mon, 9 Feb 2009 10:16:58 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1036650ana.4 for ; Mon, 09 Feb 2009 10:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=r2x+Su8CZrMpTq2fAbZC8SgNE4hwCy7FK1CqMEZt/Bo=; b=BrGeBbvLHmo8qe59pLlFThdGgaFDZeokJZ5bIYxUHfgdQTdvYNfdzwge8PDKhsVerc qTAJQBPbVuergmjPdGZ0T7iRxHythntGVIoYhkJQmYywII1qpcXEMcZS0O7LlkWCKe5/ 8JqeFYsHHydlB2CHF7D+TiI/msmn7isotdKAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HcTs4Vs62okjGdb8bCPJ4VmSlzGRvZaSbc9hNwQ2CU8WsDzE6lySsvrC6QcYr9DOmS WLoIx6w2/iVQNTlJQrqG66CrsFJW6CnfolsYuXRYK8R4tKQI8/hjUN0EyE0Cq61FdBj4 RrIZIF93L0AnbEaxTHra/M+CvPDvkEDpRCf/g= MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr178688wfe.248.1234203419455; Mon, 09 Feb 2009 10:16:59 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCBE@il-ex01.ad.checkpoint.com> References: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> <45c8c21a0902022220v894f1ald80de02cc53d7b54@mail.gmail.com> <45c8c21a0902030906p7fe6143aubbf951899a4d0689@mail.gmail.com> <45c8c21a0902031445y234f0227u652d4bcc261675cd@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FCBE@il-ex01.ad.checkpoint.com> Date: Mon, 9 Feb 2009 10:16:59 -0800 Message-ID: From: Vijay Devarapalli To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Richard Graveman Subject: Re: [IPsec] question about IKEv2 Re-direct X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:17:00 -0000 Hi, On Thu, Feb 5, 2009 at 1:04 AM, Yaron Sheffer wrote: > Also, REDIRECT_SUPPORTED needs to be sent by both peers if we want to enable this case. Otherwise, when the initiator wants to redirect its peer, it cannot know that the responder actually supports this capability. Agreed. Vijay > > Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Vijay Devarapalli >> Sent: Wednesday, February 04, 2009 2:59 >> To: Richard Graveman >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] question about IKEv2 Re-direct >> >> Hello, >> >> On Tue, Feb 3, 2009 at 2:45 PM, Richard Graveman >> wrote: >> > Hi, >> > >> >> On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman >> wrote: >> >>> Thanks. Your text is fine. The point was raised that we may not want >> >>> both parties redirecting at once. In your use cases, is it always the >> >>> IKEv2 responder that would redirect? >> >> >> >> Yes. It is always the responder in the client-gateway scenarios. >> > >> > Then, perhaps consider: "If a responder wants to redirect and receives >> > a redirect request from the initiator, ignore >> > the initiator's request. [The idea is that if this causes the >> > initiator to fail, well then, initiate again.] >> >> I created a new section in the draft, since it was getting >> complicated. :) Here is the text. >> >> 7. Use of the Redirect Mechanism between IKEv2 Peers >> >> The Re-direct mechanism described in this document is mainly intended >> for use in client-gateway scenarios. However, the mechanism can also >> be used between any two IKEv2 peers. This is especially useful for >> IKEv2 sessions between two gateway peer routers. >> >> When used between a client and gateway, the re-direct procedure is >> always initiated by the gateway. But when used between two IKEv2 >> peers, either of the IKEv2 end points can initiate the re-direct >> message. In order to prevent any race condition that might occur if >> both decide to re-direct at the same time, the responder MUST not >> respond to re-direct message from the initiator, if it has already >> decided to re-direct the initiator. >> >> A temporary pre04 version of the draft is at >> http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2- >> redirect-04.txt >> >> Vijay >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. > > Email secured by Check Point > From root@core3.amsl.com Mon Feb 9 10:30:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9805E3A6AEC; Mon, 9 Feb 2009 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090209183001.9805E3A6AEC@core3.amsl.com> Date: Mon, 9 Feb 2009 10:30:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-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: , X-List-Received-Date: Mon, 09 Feb 2009 18:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-04.txt Pages : 12 Date : 2009-02-09 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to re-direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-09102228.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Mon Feb 9 12:16:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0E43A6A5D for ; Mon, 9 Feb 2009 12:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 n-vTmLKEzvKT for ; Mon, 9 Feb 2009 12:16:40 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A310C3A67D6 for ; Mon, 9 Feb 2009 12:16:39 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5887529C004; Mon, 9 Feb 2009 22:16:40 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 508F329C002 for ; Mon, 9 Feb 2009 22:16:39 +0200 (IST) X-CheckPoint: {49908ED8-10001-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n19KGcv3009399 for ; Mon, 9 Feb 2009 22:16:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 9 Feb 2009 22:16:38 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 9 Feb 2009 22:16:32 +0200 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-04.txt Thread-Index: AcmK5HxeolNFBYMMTB6oaFB6dZ+WAwADjrxQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DD7D@il-ex01.ad.checkpoint.com> References: <20090209183001.9805E3A6AEC@core3.amsl.com> In-Reply-To: <20090209183001.9805E3A6AEC@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-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: , X-List-Received-Date: Mon, 09 Feb 2009 20:16:41 -0000 Hi, The following paragraph was added following my comments to the previous ver= sion: Both IKEv2 peers SHOULD indicate support for the re-direct mechanism if they support it and are willing to process REDIRECT notification messages. This is done by including the REDIRECT_SUPPORTED payload in the IKE_SA_INIT exchange by both peers. REDIRECT Notification messages MUST NOT be sent unless the peer has indicated support for it. But this should always apply, whenever the responder does not send a REDIRE= CT. So it needs be shown in the new exchange on Sec. 5. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, February 09, 2009 20:30 > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > > Title : Re-direct Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-04.txt > Pages : 12 > Date : 2009-02-09 > > IKEv2 is a protocol for setting up VPN tunnels from a remote location > to a gateway so that the VPN client can access services in the > network behind the gateway. Currently there is no standard mechanism > specified that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to re-direct the VPN client to > attach to another gateway. This document proposes a re-direct > mechanism for IKEv2. The proposed mechanism can also be used in > Mobile IPv6 to enable the home agent to re-direct the mobile node to > another home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect- > 04.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. Email secured by Check Point From yaronf@checkpoint.com Tue Feb 10 07:16:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5ADB28C1BA for ; Tue, 10 Feb 2009 07:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 38iZcZLVK31N for ; Tue, 10 Feb 2009 07:16:06 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B308928C202 for ; Tue, 10 Feb 2009 07:16:05 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2D91329C005; Tue, 10 Feb 2009 17:16:08 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 19F1229C002 for ; Tue, 10 Feb 2009 17:16:07 +0200 (IST) X-CheckPoint: {499199E1-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1AFG6v3000205 for ; Tue, 10 Feb 2009 17:16:06 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 10 Feb 2009 17:16:05 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 10 Feb 2009 17:16:00 +0200 Thread-Topic: Last Call: draft-ietf-btns-connection-latching (IPsec Channels: Connection Latching) to Proposed Standard Thread-Index: AcmLkHLqUnDJJUzhQQ+jFyZSqOX7egAAecaw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DDA7@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] FW: Last Call: draft-ietf-btns-connection-latching (IPsec Channels: Connection Latching) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:16:07 -0000 This is of interest to ipsecme WG participants, too. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: Tuesday, February 10, 2009 17:00 To: IETF-Announce Cc: btns@ietf.org Subject: Last Call: draft-ietf-btns-connection-latching (IPsec Channels: Co= nnection Latching) to Proposed Standard The IESG has received a request from the Better-Than-Nothing Security WG (btns) to consider the following document: - 'IPsec Channels: Connection Latching ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-08.= txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D14310&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Email secured by Check Point From g_e_montenegro@yahoo.com Tue Feb 10 11:16:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A633A69A2 for ; Tue, 10 Feb 2009 11:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm7cVHj7fHp7 for ; Tue, 10 Feb 2009 11:16:16 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 2A4D23A6936 for ; Tue, 10 Feb 2009 11:16:16 -0800 (PST) Received: (qmail 28770 invoked by uid 60001); 10 Feb 2009 19:16:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=DVqHjqu8djfQlZdRmSrnPhQ1zrXO2aVItn8YfIm9opBBhgZwqc75RWdcSyaJhgS5WXq2FpfR+lV6u7WQIQ2zUSF7WCJ6LI+7pSWt2psECUDbISRhvxB4un7d2Xx5MY+xJIQxXmFghdZ7fRLYfOyrSl0lwsb4PyIcdevZ+MFeAeU=; X-YMail-OSG: TB_i.WwVM1krKptLllUcrgEqh57.NIBRwy0GgAQE5ey_rBX3VGwE2Id0NsrrdvnNKg-- Received: from [131.107.0.69] by web82605.mail.mud.yahoo.com via HTTP; Tue, 10 Feb 2009 11:16:18 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> Date: Tue, 10 Feb 2009 11:16:18 -0800 (PST) From: gabriel montenegro To: Tero Kivinen , "Grewal, Ken" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <27014.28749.qm@web82605.mail.mud.yahoo.com> Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Tue, 10 Feb 2009 19:16:18 -0000 I'll just comment on one item below: > As the draft says this is mostly meant for stateful devices, and that > has been the main goal for the document. The charter says: > > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system ..." > > I.e. the main goal was set to be on the devices doing deeper > inspection i.e. firewalls and intrusion detection systems. Disagree completely. The charter item is a general one for intermediary devices (some of which are and are expected to continue being stateless). The above was just an example. Gabriel ----- Original Message ---- > From: Tero Kivinen > To: "Grewal, Ken" > Cc: "ipsec@ietf.org" ; Dragan Grebovich > Sent: Monday, February 9, 2009 6:19:54 AM > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > Grewal, Ken writes: > > [Ken] This may be feasible for stateful devices, but does not work > > for stateless devices (QOS/Statistics/auditing functions). Even in > > stateful devices, it requires coupling between observation on flows > > and the associated heuristics cache engine, which creates an > > additional overhead. > > As the draft says this is mostly meant for stateful devices, and that > has been the main goal for the document. The charter says: > > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system ..." > > I.e. the main goal was set to be on the devices doing deeper > inspection i.e. firewalls and intrusion detection systems. > > At least my conclusion on the list when we discussed on the usage > cases were for that kind of stateful devices. > > Are QOS and auditing devices really stateless? > > I would expect QOS devices to have all kind of reservation systems and > so on and for those I would expect them to be keeping state? > > For the auditing I have been using I have usually enabled auditing of > new connections, not all packets, thus all my auditing systems I have > set up have been keeping state. What kind of usage is completely > stateless auditing devices used for your example of 10Gbps links? > > Statistics devices could even be stateless, but is that really > something we should aim for? I.e. to wait for 5-10 years before we can > use our stateless statistics devices, compared to use stateful > statistics devices for doing the thing this or next year. > > > > [Ken] These require timestamps (or other ordering / metric based > > approaches) and monitoring to ensure the cache is up to date. > > Stateful devices do already have all that. > > > Furthermore, it may also provide opportunities for adversaries to > > use periodic replays to provide cache thrash and associated overhead > > in re-executing heuristics engines. > > As far as I have understood we are still talking about the inside one > enterprice network, not internet as whole. If they do have untrusted > users inside (i.e. attackers), they should enable encryption, thus all > this is not really a point. > > As ESP-NULL does not offer confidentiality it can only be used in > trusted environments, where the denial-of-service attacks against the > device in the middle should not be big problem. > > > I am not convinced that SW based solutions will scale 10Gbps > > solutions, let alone future 40/100Gbps bandwidth requirements, > > especially at these network 'choke' points, so a HW orientated > > solution may be desirable...which brings us back to > > cost/complexity... > > Limits for software based heuristics are not really related to the > line speed, but number of new IPsec connections per second going > through the device. > > The line speed do affect the HW based flow cache lookup (i.e. the > appendix A.1 fastpath part of the processing), but that is doable even > at 10Gbps speed, as it basically does same thing as normal stateful > firewall rules (i.e. fetch flow information based on IP address pair, > protocol and in this SPI number instead of port numbers). > > > >As here the heuristics is run on the same device which is running the > > >deep inspection, they do already require methods of transferring that > > >deep inspection state from one device to another, and moving the IPsec > > >SPI cache state at the same time should not be a problem. > > > > [Ken] But again, this is additional work, which can be avoided if we have no > state. > > Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV > len and IV len) per flow more when you transfer the whole deep > inspection state from device to other (which might include whole TCP > transmission window, which is around 64kB or so), so the increase of > additional work is about 0.009% (actually it is normally even less, as > TCP state is per TCP flow, and usually one IPsec flow has multiple TCP > flows inside, but in this case I took the worst case scenario, where > each IPsec flow have exactly one TCP flow inside). > > I do not really consider that to really be matter. > > (Doing deep inspection on TCP streams usually do require > reconstructing TCP stream in fully including dropped and retransmitted > packets. Otherwise there are attacks where you only inspect packet > which never reaches the end node (attacker causes it to be dropped), > and the retransmission packet is different than the first packet and > if you let that pass to the end node, attacker managed to get > uninspected packet through. Solution is that you either do the > retransmissions from your internal data or you verify that > retransmissions sent by the original node contains same data than > original packet, both of them do require you keep the TCP transmission > window data. This text is here just to explain that doing deep > inspection (for IDS or IPS) on TCP stream is very costly operation and > heuristics do have minimal cost compared to them.) > > > >> Auditing / logging / sniffing / sampling are some examples of > > >> stateless devices that do require to peek in the packets. Probably > > >> lots more also, so look for others to provide examples... > > > > > >As those do not affect the forwarding of the packet, then the > > >reliability requirements for them is much lower, meaning that they can > > >also work without storing any state, and running heuristics for per > > >packet basis. That of course do require implementing the heuristics on > > >the hardware if we are talking about gigabit links or faster. My guess > > >is that without any hardware support and only using software with > > >modern CPU you can probably process more than 100MBit/s, but most > > >likely not full 1GBit/s speed. > > > > [Ken] Agreed on the need to implementing heuristics in HW, but this > > contradicts the original 'benefit' of heuristics, where heuristics > > engine can be run in SW and a resultant cache entry stored in HW. > > Adding an ever changing set of rules + heuristics engine is a > > non-starter - at least that is the feedback I am getting from the HW > > engineers I have spoken with - mucho complexity + cost! > > I explained that IF you REQUIRE heuristics to run without state, then > you most likely need to implement them on hardware if you need high > speeds. I didn't mean to say anybody should try that, because I think > it is cheaper to do it by adding state. > > I think doing heuristics on the software is completely ok and doable, > for even very high speeds, when you do it in the smart way, i.e. use > state. I would expect following implementations to be usable: > > 1) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on HW (any speed). > > 2) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on SW (most likely up to 1 GBit/s). > > If you insist on not using state, then you can most likely do full > slowpath and fastpath on SW up to 100MBit/s speeds, and I do not > really see any point of doing any hardware version as making versions > 1 or 2 above make much more sense. > > If you really require very high new connection rate, i.e. for example > you have 10Gbit/s link and it consists fully at IKEv2 creation (4 > packets), TCP session creation (3 packets), 2 data packets, TCP > session finish (4 packets), IKEv2 SA delete (2 packets), i.e. each > IPsec SA only contains one TCP session, which only exchange one data > packet. This means there is 15 packets in total 8 in one direction 7 > in other. IKE packets around 236 + 236 + 208 + 208 (with minimal > packet sizes for AES-SHA1, 1024 bit MODP, pre shared key) and 100 > bytes for IKEv2 deletes, TCP SYN/FIN packets are 40 bytes, and data > packets 40+64 bytes of data. So in total that means 1576 bytes and > using ethernet framing that makes 2146 octets -> 17168 bits. > > Using 10Gbit/s link that means we can do 582479 such exchanges per > second. For software implementation using 2GHz CPU that gives about > 3400 cycles for doing the heuristics for the packet. That should be > plenty for doing heuristics, as they do not really have any loops or > other complicated operations. The one packet verification is around 10 > loads from packet, and around 15-20 compares, and we might need to do > that 6 times (for differet ICV/IV lengths), so in total we have at > about max 60 loads and 90-120 compares plus some basic arithmetics. > > I would expect that 2GHz CPU should keep up to that speed. 2GHz CPU > cannot keep up to the 10GBit/s line speed or do routing lookups for > that speeds, but if routing and non-heuristics packets are processed > by other hardware, one cpu should take care of the worst case > heuristics. > > So even at 10Gbit/s line speeds I do not think you need hardware > implementation of the slowpath heuristics part. > > > [Ken] There will always be a migration path, as well as exception > > cases. It is much easier to add a static rule for a fixed printer, > > then to have dynamic rules to allowing encrypted data to pass > > through the network. Additionally, some of the legacy devices may > > not even support a secure connection, so the traffic will be in the > > clear anyway. > > All of the traffic is in the clear, as we are talking about ESP-NULL > here. > > My draft offers even simplier solution if you are accepting that kind > of solutions. It is mandated by policy option, then you do not need to > run heuristics at all, you simply assume all packets are ESP-NULL, as > that is mandated by policy, and those exception cases where this is > not true, you handle by adding rules... > > > E.g. How many printers support IPsec today? > > Not sure, but I do know there are such out there, and even more will > be (at least kyocera has announced their printers supporting IPsec and > IPv6 > http://www.fishers-boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_Combine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm). > > > If they need to support this in the future, then it is just as easy > > for them to support WESP, instead of ESP-NULL... > > Might be but for PCs you normally do this by updating the operating > system, how often have you updated the OS of your printer? And note > that they already support ESP-NULL and with heuristics they do not > need to update anything. With WESP they need to update their software. > > Most of those vendors do not have their own IPsec, but it might either > come with the embedded operating system or it might be OEM toolkit, > which requires them to get new version of that, and new features > usually only comes with new versions (i.e. they are not part of the > bug fixes provided for old versions), thus they would need to update > to newer version of operating system or toolkit. > > As we do make IPsec OEM toolkit I can say that our customers have been > very reluctant to update to latest versions after they get their > pruducts out. there are still customers using 4 years old version. > Some of them are luckily now looking for updating to latest versions > for new products. I do not expect them to ever update their old > devices for new versions. > > So if we make WESP it will come out most likely during 2010 (and we > most likely do not make it unless there is customer demand for it (or > for heuristics), which mean that it might get pushed forward by year > or two), which will mean that some of our customers might delay up to > 2015 before they update to that version, and after that it takes year > or so before they get their devices out. > > > [Ken] I think we need to consider all these issues in determining if > > a heuristics solution will work and scale under ALL circumstances. > > I do not think heuristics need to work in ALL circumstances. I think > it needs to work in the circumstances we are aiming for, and by > charter that is "an intermediary device, such as a firewall or > intrusion detection system". > > Do you really consider stateless versions of those intermediary > devices something that will be common in the future? > > > By contrast, WESP does not have any of these issues (bar adoption), > > as it is being designed for efficiency, cost effectiveness and > > scalability. > > The adoptation is big issue there. > > As my draft says even if we go for WESP, I think the intermediary > device vendors still want to have some solution they can use now, thus > they will still need to implement heuristics. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue Feb 10 11:55:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666B43A6C1F for ; Tue, 10 Feb 2009 11:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 wUVSqKDu+t1I for ; Tue, 10 Feb 2009 11:55:23 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F03453A6BEB for ; Tue, 10 Feb 2009 11:55:22 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E336829C005; Tue, 10 Feb 2009 21:55:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BD88829C002; Tue, 10 Feb 2009 21:55:20 +0200 (IST) X-CheckPoint: {4991DB51-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1AJtJv3007405; Tue, 10 Feb 2009 21:55:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 10 Feb 2009 21:55:19 +0200 From: Yoav Nir To: gabriel montenegro , Tero Kivinen , "Grewal, Ken" Date: Tue, 10 Feb 2009 21:51:31 +0200 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmLtBkaaAcjn1BDRc+uWLeknCrm0QABN9oI Message-ID: <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi>, <27014.28749.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <27014.28749.qm@web82605.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Tue, 10 Feb 2009 19:55:24 -0000 gabriel montenegro wrote: >I'll just comment on one item below: > >> As the draft says this is mostly meant for stateful devices, and that >> has been the main goal for the document. The charter says: >> >> "A standards-track mechanism that allows an intermediary device, such >> as a firewall or intrusion detection system ..." >> >> I.e. the main goal was set to be on the devices doing deeper >> inspection i.e. firewalls and intrusion detection systems. > >Disagree completely. The charter item is a general one for intermediary de= vices >(some of which are and are expected to continue being stateless). > >The above was just an example. OK, so give us a counter-example. Why would a stateless device want to be a= ble to tell the difference between ESP-AES-CBC and ESP-NULL. What policy i= s it trying to enforce? Email secured by Check Point From ken.grewal@intel.com Tue Feb 10 13:33:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA333A6D22 for ; Tue, 10 Feb 2009 13:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 MhP7POib8UFd for ; Tue, 10 Feb 2009 13:33:35 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 3C7E53A6852 for ; Tue, 10 Feb 2009 13:33:35 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 10 Feb 2009 13:32:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,188,1233561600"; d="scan'208";a="664505805" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga001.fm.intel.com with ESMTP; 10 Feb 2009 13:37:33 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 10 Feb 2009 14:33:39 -0700 From: "Grewal, Ken" To: Yoav Nir , gabriel montenegro , Tero Kivinen Date: Tue, 10 Feb 2009 14:33:35 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmLtBkaaAcjn1BDRc+uWLeknCrm0QABN9oIAAIKFxA= Message-ID: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi>, <27014.28749.qm@web82605.mail.mud.yahoo.com> <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Tue, 10 Feb 2009 21:33:36 -0000 Stateless firewalls are commonly employed for efficiency and as a crude met= hod for cutting off access to certain services - these are useful for basic= access control in cost effective, high bandwidth, network scenarios. E.g. = Corporations may not want to allow various P2P protocols, discovery of reso= urces, access to certain services (especially if using UDP as the underlyin= g protocol), remote access/management to certain resources from outside wel= l established network boundaries, etc., etc.. There are thousands of well d= efined ports providing different services from legacy, experimental, to the= 'latest, greatest, service of the day' - and someone just found an exploit= for and there is no fix available! How do you ensure that your network doe= sn't get inundated with unwanted traffic or exploited? Block that port!! Stateless firewalls can and do provide the fundamental building blocks for = basic access control. In these scenarios, the need to differentiate between= encrypted / NULL ESP traffic is required to enforce these policies, withou= t the need or burden of keeping state on 'connections' or 'security session= s'. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Yoav Nir >Sent: Tuesday, February 10, 2009 11:52 AM >To: gabriel montenegro; Tero Kivinen; Grewal, Ken >Cc: ipsec@ietf.org; Dragan Grebovich >Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > >gabriel montenegro wrote: > >>I'll just comment on one item below: >> >>> As the draft says this is mostly meant for stateful devices, and that >>> has been the main goal for the document. The charter says: >>> >>> "A standards-track mechanism that allows an intermediary device, such >>> as a firewall or intrusion detection system ..." >>> >>> I.e. the main goal was set to be on the devices doing deeper >>> inspection i.e. firewalls and intrusion detection systems. >> >>Disagree completely. The charter item is a general one for intermediary >devices >>(some of which are and are expected to continue being stateless). >> >>The above was just an example. > >OK, so give us a counter-example. Why would a stateless device want to be >able to tell the difference between ESP-AES-CBC and ESP-NULL. What policy >is it trying to enforce? > > > > >Email secured by Check Point >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Tue Feb 10 14:36:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3409E3A6A3B for ; Tue, 10 Feb 2009 14:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKw9FIypYq4Y for ; Tue, 10 Feb 2009 14:36:20 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 17BAF3A6765 for ; Tue, 10 Feb 2009 14:36:19 -0800 (PST) Received: from [165.227.249.206] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AMaKJr002618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2009 15:36:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi>, <27014.28749.qm@web82605.mail.mud.yahoo.com> <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> Date: Tue, 10 Feb 2009 14:36:19 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Tue, 10 Feb 2009 22:36:21 -0000 At 2:33 PM -0700 2/10/09, Grewal, Ken wrote: >Stateless firewalls are commonly employed for efficiency and as a crude method for cutting off access to certain services - these are useful for basic access control in cost effective, high bandwidth, network scenarios. E.g. Corporations may not want to allow various P2P protocols, discovery of resources, access to certain services (especially if using UDP as the underlying protocol), remote access/management to certain resources from outside well established network boundaries, etc., etc.. There are thousands of well defined ports providing different services from legacy, experimental, to the 'latest, greatest, service of the day' - and someone just found an exploit for and there is no fix available! How do you ensure that your network doesn't get inundated with unwanted traffic or exploited? Block that port!! > >Stateless firewalls can and do provide the fundamental building blocks for basic access control. In these scenarios, the need to differentiate between encrypted / NULL ESP traffic is required to enforce these policies, without the need or burden of keeping state on 'connections' or 'security sessions'. (Not wearing any hat) What level of assuredness do stateless firewalls need? That is, a stateless firewall can easily look inside what it is passing to get a simple guess about what is in the packet; this happens all the time on port 80. There are well known but imperfect heuristics for inspecting content on port 80; some of those could be used on ESP as well. People commenting on this thread should state what level of certainty they think the middleboxes need to have, in addition to saying what properties they think those middleboxes have (such as ability to retain state, how much state, how long, and so on). --Paul Hoffman, Director --VPN Consortium From ken.grewal@intel.com Tue Feb 10 15:00:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB6A3A69E5 for ; Tue, 10 Feb 2009 15:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBg2O5Cp8zkw for ; Tue, 10 Feb 2009 15:00:50 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 7816E3A697F for ; Tue, 10 Feb 2009 15:00:50 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 10 Feb 2009 14:56:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,188,1233561600"; d="scan'208";a="488944945" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga001.jf.intel.com with ESMTP; 10 Feb 2009 15:00:26 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 10 Feb 2009 16:00:38 -0700 From: "Grewal, Ken" To: Paul Hoffman , "ipsec@ietf.org" Date: Tue, 10 Feb 2009 16:00:35 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmL0BEAXThhJ2smRfq3VMZR4COYxAAAbs2A Message-ID: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi>, <27014.28749.qm@web82605.mail.mud.yahoo.com> <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Tue, 10 Feb 2009 23:00:51 -0000 >At 2:33 PM -0700 2/10/09, Grewal, Ken wrote: >>Stateless firewalls are commonly employed for efficiency and as a crude >method for cutting off access to certain services - these are useful for >basic access control in cost effective, high bandwidth, network scenarios. >E.g. Corporations may not want to allow various P2P protocols, discovery o= f >resources, access to certain services (especially if using UDP as the >underlying protocol), remote access/management to certain resources from >outside well established network boundaries, etc., etc.. There are >thousands of well defined ports providing different services from legacy, >experimental, to the 'latest, greatest, service of the day' - and someone >just found an exploit for and there is no fix available! How do you ensure >that your network doesn't get inundated with unwanted traffic or exploited= ? >Block that port!! >> >>Stateless firewalls can and do provide the fundamental building blocks fo= r >basic access control. In these scenarios, the need to differentiate betwee= n >encrypted / NULL ESP traffic is required to enforce these policies, withou= t >the need or burden of keeping state on 'connections' or 'security >sessions'. > >(Not wearing any hat) [Ken] Wearing a basketball hat - 'go blazers!' :-) > >What level of assuredness do stateless firewalls need? That is, a stateles= s >firewall can easily look inside what it is passing to get a simple guess >about what is in the packet; this happens all the time on port 80. There >are well known but imperfect heuristics for inspecting content on port 80; >some of those could be used on ESP as well. > >People commenting on this thread should state what level of certainty they >think the middleboxes need to have, in addition to saying what properties >they think those middleboxes have (such as ability to retain state, how >much state, how long, and so on). [Ken] In some cases, the certainty must be 100%, otherwise there is no cont= rol. E.g. A new exploit has just been published for certain types of traffi= c - published vulnerability where a virus/worm can exploit a 'buffer overru= n/stack overflow' condition for a given piece of software providing a given= service, which subsequently allows a hijacker to take control of the machi= ne/server. That service MUST be shut down to ensure that the vulnerability = cannot be exploited and spread. This may or may not result in shut down of = the server hosting the service, as you may want to allow remote patching, e= tc. Easiest way to do this is to block the port over which the vulnerabilit= y is being exploited.=20 Just one example and I am sure there are numerous others... From ken.grewal@intel.com Tue Feb 10 17:36:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D0E3A6D8E for ; Tue, 10 Feb 2009 17:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV59v0Tmkt3g for ; Tue, 10 Feb 2009 17:36:37 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 53CB23A6CFE for ; Tue, 10 Feb 2009 17:36:36 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 10 Feb 2009 17:36:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,188,1233561600"; d="scan'208";a="109370513" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 10 Feb 2009 17:36:39 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 10 Feb 2009 18:36:38 -0700 From: "Grewal, Ken" To: Tero Kivinen Date: Tue, 10 Feb 2009 18:36:34 -0700 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmKwYL2ZO79YZuqSoiiIJlo3jkr9gBBc8JA Message-ID: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> In-Reply-To: <18832.15242.707313.57888@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Wed, 11 Feb 2009 01:36:40 -0000 >> [Ken] This may be feasible for stateful devices, but does not work >> for stateless devices (QOS/Statistics/auditing functions). Even in >> stateful devices, it requires coupling between observation on flows >> and the associated heuristics cache engine, which creates an >> additional overhead. > >As the draft says this is mostly meant for stateful devices, and that >has been the main goal for the document. The charter says: > >"A standards-track mechanism that allows an intermediary device, such >as a firewall or intrusion detection system ..." > >I.e. the main goal was set to be on the devices doing deeper >inspection i.e. firewalls and intrusion detection systems. > >At least my conclusion on the list when we discussed on the usage >cases were for that kind of stateful devices. [Ken] I think the charter is device independent and needs to accommodate an= y type of device that requires access to the data - stateless or stateful. = Otherwise, we have a partial solution. I was under the impression that this= charter was to provide intermediate device traffic visibility, irrespectiv= e of the type of device that needs this visibility - or am I missing someth= ing? > >Are QOS and auditing devices really stateless? > >I would expect QOS devices to have all kind of reservation systems and >so on and for those I would expect them to be keeping state? [Ken] QoS may be applied on the need of the underlying service. E.g. A stat= ic rule that indicates that I place voice traffic in a priority queue over = data traffic may be sufficient as a basic stateless rule. Auditing (logging) is another example where you may want to capture all TCP= or UDP traffic - e.g. for diagnostics or other analysis. There is no need = for any state correlation between connections / flows - this is just a dumb= filter based on protocols / ports. > >For the auditing I have been using I have usually enabled auditing of >new connections, not all packets, thus all my auditing systems I have >set up have been keeping state. What kind of usage is completely >stateless auditing devices used for your example of 10Gbps links? [Ken] Stateless firewall is one example to filter unwanted network traffic.= Please see separate message on this topic on the ML. > >Statistics devices could even be stateless, but is that really >something we should aim for? I.e. to wait for 5-10 years before we can >use our stateless statistics devices, compared to use stateful >statistics devices for doing the thing this or next year. [Ken] We have been through the deployment timeframe arguments before and it= looks like we are going in circles here. It is speculative to say how long= one solution will take to be adopted instead of another. This depends on a= number of factors - e.g. some network appliance vendors have indicated tha= t they will not employ heuristics in their network devices due the cost / c= omplexity, but prefer a more deterministic approach, whereas others may be = more willing to add this support and charge a premium for the appliances. > > >> [Ken] These require timestamps (or other ordering / metric based >> approaches) and monitoring to ensure the cache is up to date. > >Stateful devices do already have all that. [Ken] Stateless devices may not! > >> Furthermore, it may also provide opportunities for adversaries to >> use periodic replays to provide cache thrash and associated overhead >> in re-executing heuristics engines. > >As far as I have understood we are still talking about the inside one >enterprice network, not internet as whole. If they do have untrusted >users inside (i.e. attackers), they should enable encryption, thus all >this is not really a point. > >As ESP-NULL does not offer confidentiality it can only be used in >trusted environments, where the denial-of-service attacks against the >device in the middle should not be big problem. [Ken] Why is DoS not a big problem, especially if we generate a new DoS opp= ortunity on a new 'cache' in the network device? BTW, insider threats are on the rise according to various public reports, s= o should not be discounted. This is one of the motivations of employing sec= urity, even within the Enterprise. > >> I am not convinced that SW based solutions will scale 10Gbps >> solutions, let alone future 40/100Gbps bandwidth requirements, >> especially at these network 'choke' points, so a HW orientated >> solution may be desirable...which brings us back to >> cost/complexity... > >Limits for software based heuristics are not really related to the >line speed, but number of new IPsec connections per second going >through the device. [Ken] My point was that based on a large # of connections (and potentially = cache thrashing, resulting in cache evictions), the SW burden for executing= the heuristics engines may still be large. Also, cache will be of a finite= size and will not scale to larger and larger connections / loads. > >The line speed do affect the HW based flow cache lookup (i.e. the >appendix A.1 fastpath part of the processing), but that is doable even >at 10Gbps speed, as it basically does same thing as normal stateful >firewall rules (i.e. fetch flow information based on IP address pair, >protocol and in this SPI number instead of port numbers). > >> >As here the heuristics is run on the same device which is running the >> >deep inspection, they do already require methods of transferring that >> >deep inspection state from one device to another, and moving the IPsec >> >SPI cache state at the same time should not be a problem. >> >> [Ken] But again, this is additional work, which can be avoided if we hav= e >no state. > >Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV >len and IV len) per flow more when you transfer the whole deep >inspection state from device to other (which might include whole TCP >transmission window, which is around 64kB or so), so the increase of >additional work is about 0.009% (actually it is normally even less, as >TCP state is per TCP flow, and usually one IPsec flow has multiple TCP >flows inside, but in this case I took the worst case scenario, where >each IPsec flow have exactly one TCP flow inside). > [Ken] This may be acceptable on some stateful devices, especially those tha= t maintain TCP based flows, but may not be acceptable for stateless or UDP = based flows. >I do not really consider that to really be matter. > >(Doing deep inspection on TCP streams usually do require >reconstructing TCP stream in fully including dropped and retransmitted >packets. Otherwise there are attacks where you only inspect packet >which never reaches the end node (attacker causes it to be dropped), >and the retransmission packet is different than the first packet and >if you let that pass to the end node, attacker managed to get >uninspected packet through. Solution is that you either do the >retransmissions from your internal data or you verify that >retransmissions sent by the original node contains same data than >original packet, both of them do require you keep the TCP transmission >window data. This text is here just to explain that doing deep >inspection (for IDS or IPS) on TCP stream is very costly operation and >heuristics do have minimal cost compared to them.) > >> >> Auditing / logging / sniffing / sampling are some examples of >> >> stateless devices that do require to peek in the packets. Probably >> >> lots more also, so look for others to provide examples... >> > >> >As those do not affect the forwarding of the packet, then the >> >reliability requirements for them is much lower, meaning that they can >> >also work without storing any state, and running heuristics for per >> >packet basis. That of course do require implementing the heuristics on >> >the hardware if we are talking about gigabit links or faster. My guess >> >is that without any hardware support and only using software with >> >modern CPU you can probably process more than 100MBit/s, but most >> >likely not full 1GBit/s speed. >> >> [Ken] Agreed on the need to implementing heuristics in HW, but this >> contradicts the original 'benefit' of heuristics, where heuristics >> engine can be run in SW and a resultant cache entry stored in HW. >> Adding an ever changing set of rules + heuristics engine is a >> non-starter - at least that is the feedback I am getting from the HW >> engineers I have spoken with - mucho complexity + cost! > >I explained that IF you REQUIRE heuristics to run without state, then >you most likely need to implement them on hardware if you need high >speeds. I didn't mean to say anybody should try that, because I think >it is cheaper to do it by adding state. [Ken] This choice is vendor/device/architecture dependent and one approach = may not fit all models. > >I think doing heuristics on the software is completely ok and doable, >for even very high speeds, when you do it in the smart way, i.e. use >state. I would expect following implementations to be usable: > >1) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on HW (any speed). > >2) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on SW (most likely up to 1 GBit/s). > >If you insist on not using state, then you can most likely do full >slowpath and fastpath on SW up to 100MBit/s speeds, and I do not >really see any point of doing any hardware version as making versions >1 or 2 above make much more sense. [Ken] If you are implementing all (or even part of the solution) in softwar= e, then I agree that this will not scale beyond a few 100Mbps - hence a HW = approach is needed to support larger bandwidths. So, it depends on your HW = architecture, what services are being supported by the device and the perce= ived cost/complexity/value in adding support for additional capabilities (e= .g. Heuristics Vs. WESP). > >If you really require very high new connection rate, i.e. for example >you have 10Gbit/s link and it consists fully at IKEv2 creation (4 >packets), TCP session creation (3 packets), 2 data packets, TCP >session finish (4 packets), IKEv2 SA delete (2 packets), i.e. each >IPsec SA only contains one TCP session, which only exchange one data >packet. This means there is 15 packets in total 8 in one direction 7 >in other. IKE packets around 236 + 236 + 208 + 208 (with minimal >packet sizes for AES-SHA1, 1024 bit MODP, pre shared key) and 100 >bytes for IKEv2 deletes, TCP SYN/FIN packets are 40 bytes, and data >packets 40+64 bytes of data. So in total that means 1576 bytes and >using ethernet framing that makes 2146 octets -> 17168 bits. > >Using 10Gbit/s link that means we can do 582479 such exchanges per >second. For software implementation using 2GHz CPU that gives about >3400 cycles for doing the heuristics for the packet. That should be >plenty for doing heuristics, as they do not really have any loops or >other complicated operations. The one packet verification is around 10 >loads from packet, and around 15-20 compares, and we might need to do >that 6 times (for differet ICV/IV lengths), so in total we have at >about max 60 loads and 90-120 compares plus some basic arithmetics. > >I would expect that 2GHz CPU should keep up to that speed. 2GHz CPU >cannot keep up to the 10GBit/s line speed or do routing lookups for >that speeds, but if routing and non-heuristics packets are processed >by other hardware, one cpu should take care of the worst case >heuristics. [Ken] Are you saying that a 2GHz CPU is needed to run a heuristics engine? = If so, then the question begs - is an intermediate device vendor willing to= allocate a whole CPU for this task, or would this be better utilized for p= rocessing the packet payloads? If we can do this in a deterministic manner = in HW, then the CPU cycles can be 'recovered' and better utilized for other= tasks. > >So even at 10Gbit/s line speeds I do not think you need hardware >implementation of the slowpath heuristics part. > >> [Ken] There will always be a migration path, as well as exception >> cases. It is much easier to add a static rule for a fixed printer, >> then to have dynamic rules to allowing encrypted data to pass >> through the network. Additionally, some of the legacy devices may >> not even support a secure connection, so the traffic will be in the >> clear anyway. > >All of the traffic is in the clear, as we are talking about ESP-NULL >here. [Ken] By 'in the clear', I meant non-IPsec/ESP (traditional clear text) tra= ffic; By encrypted, I meant 'wrapped in ESP' - i.e. ESP-NULL traffic - apol= ogies for any confusion. > >My draft offers even simplier solution if you are accepting that kind >of solutions. It is mandated by policy option, then you do not need to >run heuristics at all, you simply assume all packets are ESP-NULL, as >that is mandated by policy, and those exception cases where this is >not true, you handle by adding rules... [Ken] I agree with this for 'fixed' devices such as printers, where it can = have a well defined/known IP and there can be an 'exception rule' to accomm= odate these devices (e.g. allow traffic to/from this IP, irrespective of tr= affic type). Obviously these types of rules cannot be employed for other de= vices containing dynamic addresses. > >> E.g. How many printers support IPsec today? > >Not sure, but I do know there are such out there, and even more will >be (at least kyocera has announced their printers supporting IPsec and >IPv6 http://www.fishers- >boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_= C >ombine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm). > [Ken] Thanks - this is good to know and I was not aware of it. >> If they need to support this in the future, then it is just as easy >> for them to support WESP, instead of ESP-NULL... > >Might be but for PCs you normally do this by updating the operating >system, how often have you updated the OS of your printer? And note >that they already support ESP-NULL and with heuristics they do not >need to update anything. With WESP they need to update their software. [Ken] Again, thanks - I was not aware that printers already support ESP-NUL= L. My comment was specifically for these devices that do not support ANY IP= sec and future iterations can support the appropriate protocol, as needed. = Having said that, as you indicated above, these type of devices are more am= enable to exception rules, as they are fixed function and can have fixed ad= dresses and are typically not expected to be the source / destination of th= reats, so in these cases, static rules will work just fine. > >Most of those vendors do not have their own IPsec, but it might either >come with the embedded operating system or it might be OEM toolkit, >which requires them to get new version of that, and new features >usually only comes with new versions (i.e. they are not part of the >bug fixes provided for old versions), thus they would need to update >to newer version of operating system or toolkit. > >As we do make IPsec OEM toolkit I can say that our customers have been >very reluctant to update to latest versions after they get their >pruducts out. there are still customers using 4 years old version. >Some of them are luckily now looking for updating to latest versions >for new products. I do not expect them to ever update their old >devices for new versions. > >So if we make WESP it will come out most likely during 2010 (and we >most likely do not make it unless there is customer demand for it (or >for heuristics), which mean that it might get pushed forward by year >or two), which will mean that some of our customers might delay up to >2015 before they update to that version, and after that it takes year >or so before they get their devices out. [Ken] Again, if we are talking about 'fixed function/fixed OS' devices, the= n these are static in nature and can be catered for as exceptions. IT depar= tments are not too concerned with running Intrusion detection algorithms on= data going to a printer, although it may end up being the norm at some tim= e in the future. > >> [Ken] I think we need to consider all these issues in determining if >> a heuristics solution will work and scale under ALL circumstances. > >I do not think heuristics need to work in ALL circumstances. I think >it needs to work in the circumstances we are aiming for, and by >charter that is "an intermediary device, such as a firewall or >intrusion detection system". [Ken] I think we need to consider ALL devices that currently operate within= the network and perform any data examination. A Firewall and an IDS are bu= t two examples of such devices. > >Do you really consider stateless versions of those intermediary >devices something that will be common in the future? [Ken] No - I think they are common today! > >> By contrast, WESP does not have any of these issues (bar adoption), >> as it is being designed for efficiency, cost effectiveness and >> scalability. > >The adoptation is big issue there. > >As my draft says even if we go for WESP, I think the intermediary >device vendors still want to have some solution they can use now, thus >they will still need to implement heuristics. [Ken] Perhaps there is a migration path consideration, where heuristics can= offer interim benefits until a more deterministic solution is adopted. Ado= ption of either / both / neither will be ultimately based on numerous facto= rs, including value, customer demand, etc. From kivinen@iki.fi Wed Feb 11 03:34:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AFF3A6C75 for ; Wed, 11 Feb 2009 03:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 fO1PBKFa+0N4 for ; Wed, 11 Feb 2009 03:34:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 377513A694E for ; Wed, 11 Feb 2009 03:34:25 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1BBYRwk017464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 13:34:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1BBYP58015643; Wed, 11 Feb 2009 13:34:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18834.47041.419083.437226@fireball.kivinen.iki.fi> Date: Wed, 11 Feb 2009 13:34:25 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> <27014.28749.qm@web82605.mail.mud.yahoo.com> <9FB7C7CE79B84449B52622B506C78036130B76C899@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 95 min Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Wed, 11 Feb 2009 11:34:28 -0000 Grewal, Ken writes: > [Ken] In some cases, the certainty must be 100%, otherwise there is > no control. E.g. A new exploit has just been published for certain > types of traffic - published vulnerability where a virus/worm can > exploit a 'buffer overrun/stack overflow' condition for a given > piece of software providing a given service, which subsequently > allows a hijacker to take control of the machine/server. That > service MUST be shut down to ensure that the vulnerability cannot be > exploited and spread. This may or may not result in shut down of the > server hosting the service, as you may want to allow remote > patching, etc. Easiest way to do this is to block the port over > which the vulnerability is being exploited. Which does not help if you allow any encrypted ESP traffic to the host, as the attacker will then just use encrypted ESP to make the attack. On the other hand if you do not allow any encrypted ESP packets, you KNOW that all packets are ESP-NULL, which makes the packet checks much easier even for stateless devices. -- kivinen@iki.fi From kivinen@iki.fi Wed Feb 11 04:06:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CF33A67B4 for ; Wed, 11 Feb 2009 04:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 9flqEQ9Q4H51 for ; Wed, 11 Feb 2009 04:06:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B93113A63D3 for ; Wed, 11 Feb 2009 04:06:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1BC6JBl000740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 14:06:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1BC6Iiv016512; Wed, 11 Feb 2009 14:06:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18834.48954.47580.62256@fireball.kivinen.iki.fi> Date: Wed, 11 Feb 2009 14:06:18 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 30 min X-Total-Time: 31 min Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Wed, 11 Feb 2009 12:06:19 -0000 Grewal, Ken writes: > >Are QOS and auditing devices really stateless? > > > >I would expect QOS devices to have all kind of reservation systems and > >so on and for those I would expect them to be keeping state? > > [Ken] QoS may be applied on the need of the underlying service. E.g. > A static rule that indicates that I place voice traffic in a > priority queue over data traffic may be sufficient as a basic > stateless rule. Note that you cannot do QoS without the co-operation of the sending IPsec site. The sending IPsec node needs to put packets getting separate QoS handling to separate SAs as otherwise the receiving IPsec node will drop packets if they get out of the replay window. Because of this there is no need to inspect the content of the ESP packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and SPI number. So for QoS there is no need to inspect the data inside the ESP-NULL packet, as you cannot give different handling to different packets, as if you do so, then those ESP-NULL packets getting slower path might get dropped by the receiving IPsec node, as those packets getting faster path have already moved replay window so that those slower packets do not fit in to it anymore. > [Ken] We have been through the deployment timeframe arguments before > and it looks like we are going in circles here. It is speculative to > say how long one solution will take to be adopted instead of > another. This depends on a number of factors - e.g. some network > appliance vendors have indicated that they will not employ > heuristics in their network devices due the cost / complexity, but > prefer a more deterministic approach, whereas others may be more > willing to add this support and charge a premium for the appliances. My guess is that regardless what we do, at least some middle box vendors will implement heuristics in their high-end boxes, and after one vendor supports it, others need to support it too to be able to offer similar features than their competitors do. After a while even more low-end devices will support it and soon most middle boxes do support it. After that the requirements for supporting WESP will drop, as middle-boxes work without it, so general support for it will stay even lower. But that is just my guess... > [Ken] Why is DoS not a big problem, especially if we generate a new > DoS opportunity on a new 'cache' in the network device? DoS opportunities is a problem, but I do not think SPI cache will create that much new opportunities. I.e. I claim that the SPI cache can be implemented in such way that it does not offer any major DoS opportunity. > BTW, insider threats are on the rise according to various public > reports, so should not be discounted. This is one of the motivations > of employing security, even within the Enterprise. Yes, but I do not really think people are going to solve those using ESP-NULL. I think they must move to encrypted ESP to provide confidentiality also, and that makes the need for ESP-NULL visibility even less. For example most of the insider information (insider trading, leaking trade secrets, espionage) problems cannot be solved by using ESP-NULL. > [Ken] Perhaps there is a migration path consideration, where > heuristics can offer interim benefits until a more deterministic > solution is adopted. Adoption of either / both / neither will be > ultimately based on numerous factors, including value, customer > demand, etc. This I agree and I have even tried to bring this up in my draft (see last paragraph in the introduction section). -- kivinen@iki.fi From Pasi.Eronen@nokia.com Wed Feb 11 04:38:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BBE3A6CCF for ; Wed, 11 Feb 2009 04:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 a6jMyA1X4ueI for ; Wed, 11 Feb 2009 04:38:37 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 446BF3A6AEE for ; Wed, 11 Feb 2009 04:38:37 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1BCcKKq028369; Wed, 11 Feb 2009 14:38:35 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 14:38:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 14:38:25 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 11 Feb 2009 13:38:24 +0100 From: To: , Date: Wed, 11 Feb 2009 13:38:25 +0100 Thread-Topic: Bis issue #14: Bounding the retransmit time Thread-Index: AcmAzcIBxkaPjM7vSp6FcaJolJCsIQAVICYQAsh3s5A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E79A74BB@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B100@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B100@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2009 12:38:25.0541 (UTC) FILETIME=[A2018350:01C98C45] X-Nokia-AV: Clean Subject: Re: [IPsec] Bis issue #14: Bounding the retransmit time X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:38:38 -0000 Yoav Nir wrote: > On the other hand, even with a window size of 1, the current text > seems to suggest that the last packet should be retained > indefinitely. This doesn't make sense, as the initiator of that > packet is also bound by the "at least a dozen times over a period of > at least several minutes", so four hours later, the initiator has > either given up on the IKE SA, or has received the response. > > So I'm with Tero on this one. Hmm... this assumes that the *only* reason for seeing a retransmitted request is that the sender has not seen the response yet. I remember that when we specified the MOBIKE extension, we did talk about possible need to retransmit a request (to test whether a path works) even when you've already seen the response... but I think the outcome was that this probably is not needed (and I can't find text in 4555 or 4621 saying anything about this). So probably Tero's suggestion is safe to do. Best regards, Pasi From welterk@us.ibm.com Wed Feb 11 14:56:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB063A6BBE for ; Wed, 11 Feb 2009 14:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxzlYfDfXlI8 for ; Wed, 11 Feb 2009 14:56:22 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id DF86F3A6BAA for ; Wed, 11 Feb 2009 14:56:21 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e39.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1BMs2xB008470 for ; Wed, 11 Feb 2009 15:54:02 -0700 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.1) with ESMTP id n1BMuOo3203162 for ; Wed, 11 Feb 2009 15:56:24 -0700 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 n1BMuNec022540 for ; Wed, 11 Feb 2009 15:56:23 -0700 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 n1BMuNdd022537 for ; Wed, 11 Feb 2009 15:56:23 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 02/11/2009 02:56:20 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 02/11/2009 02:56:20 PM, Serialize complete at 02/11/2009 02:56:20 PM, S/MIME Sign failed at 02/11/2009 02:56:20 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 02/11/2009 15:56:23, Serialize complete at 02/11/2009 15:56:23 Message-ID: Date: Wed, 11 Feb 2009 14:56:23 -0800 Content-Type: multipart/alternative; boundary="=_alternative 007E02248825755A_=" Subject: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:56:22 -0000 This is a multipart message in MIME format. --=_alternative 007E02248825755A_= Content-Type: text/plain; charset="US-ASCII" RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says: The case where CHILD_SAs are being closed is even worse. Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-closed" state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host receives a request to close a CHILD_SA after it has started rekeying the IKE_SA, it should reply with an empty Informational response. This ensures that at least the other peer will eventually notice that the CHILD_SA is still in "half-closed" state and will start a new IKE_SA from scratch. Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B receives it. What should host B do next? Host B was attempting to rekey the IKE SA and needs to retry that operation. Is it acceptable for host B to retransmit the CCSA request with the same message ID even though it has received a response? Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 007E02248825755A_= Content-Type: text/html; charset="US-ASCII"
RFC 4718 section 5.11.8.  Collisions with IKE_SA Rekeying says:
   The case where CHILD_SAs are being closed is even worse.  Our
  recommendation is that if a host receives a request to rekey the
  IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
  closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
  receives a request to close a CHILD_SA after it has started rekeying
  the IKE_SA, it should reply with an empty Informational response.
  This ensures that at least the other peer will eventually notice that
  the CHILD_SA is still in "half-closed" state and will start a new
  IKE_SA from scratch.
Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B receives it.  What should host B do next?  Host B was attempting to rekey the IKE SA and needs to retry that operation.  Is it acceptable for host B to retransmit the CCSA request with the same message ID even though it has received a response?  

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 007E02248825755A_=-- From kivinen@iki.fi Thu Feb 12 05:30:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6163A6B68 for ; Thu, 12 Feb 2009 05:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9ZzEpHnHd2E for ; Thu, 12 Feb 2009 05:30:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E426D3A6B35 for ; Thu, 12 Feb 2009 05:30:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1CDUqG6018011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 15:30:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1CDUqCc018995; Thu, 12 Feb 2009 15:30:52 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18836.9356.41857.765122@fireball.kivinen.iki.fi> Date: Thu, 12 Feb 2009 15:30:52 +0200 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 25 min Cc: ipsec@ietf.org Subject: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:30:52 -0000 Keith Welter writes: > RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says: > The case where CHILD_SAs are being closed is even worse. Our > recommendation is that if a host receives a request to rekey the > IKE_SA when it has CHILD_SAs in "half-closed" state (currently being > closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host > receives a request to close a CHILD_SA after it has started rekeying > the IKE_SA, it should reply with an empty Informational response. > This ensures that at least the other peer will eventually notice that > the CHILD_SA is still in "half-closed" state and will start a new > IKE_SA from scratch. > > Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B > receives it. What should host B do next? Host B was attempting to rekey > the IKE SA and needs to retry that operation. Is it acceptable for host B > to retransmit the CCSA request with the same message ID even though it has > received a response? If B retransmits the CCSA request with same message ID, then host A will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of retransmitting old CCSA request with same message ID. If IKE SA is in half-closed state and B does not know that yet, then it means that A has already sent out delete notification for the IKE SA, and then B sent CCSA before receiving that delete notification, and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does not really need to do anything, it should receive delete notification very soon. It can install timer (for example 60 seconds or so), and retry the operation after that (or it can wait until the hard lifetime is reached, and delete the old child SA then and then next packet will trigger new child sa creation). If it still fails, it knows there is something wrong with the syncronization of the both ends, and in that case it should delete the IKE SA and start from the scratch. -- kivinen@iki.fi From welterk@us.ibm.com Thu Feb 12 07:58:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BE93A69BD for ; Thu, 12 Feb 2009 07:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, 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 UupOqJa1FcXT for ; Thu, 12 Feb 2009 07:58:30 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 0B7523A6848 for ; Thu, 12 Feb 2009 07:58:29 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1CFuxF0001731 for ; Thu, 12 Feb 2009 08:56:59 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1CFwWoR206380 for ; Thu, 12 Feb 2009 08:58:33 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1CFwWGe010161 for ; Thu, 12 Feb 2009 08:58:32 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1CFwWPu010156 for ; Thu, 12 Feb 2009 08:58:32 -0700 In-Reply-To: <18836.9356.41857.765122@fireball.kivinen.iki.fi> To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 02/12/2009 07:58:28 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 02/12/2009 07:58:28 AM, Serialize complete at 02/12/2009 07:58:28 AM, S/MIME Sign failed at 02/12/2009 07:58:28 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 02/12/2009 08:58:31, Serialize complete at 02/12/2009 08:58:31 Message-ID: Date: Thu, 12 Feb 2009 07:58:29 -0800 Content-Type: multipart/alternative; boundary="=_alternative 0057C0358825755B_=" Cc: Thomas McSweeney Subject: Re: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:58:31 -0000 This is a multipart message in MIME format. --=_alternative 0057C0358825755B_= Content-Type: text/plain; charset="US-ASCII" Thanks Tero. Some more specifics on my scenario and a couple more questions are included below. > Tero Kivinen wrote on 02/12/2009 05:30:52 AM: > > Keith Welter writes: > > RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says: > > The case where CHILD_SAs are being closed is even worse. Our > > recommendation is that if a host receives a request to rekey the > > IKE_SA when it has CHILD_SAs in "half-closed" state (currently being > > closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host > > receives a request to close a CHILD_SA after it has started rekeying > > the IKE_SA, it should reply with an empty Informational response. > > This ensures that at least the other peer will eventually notice that > > the CHILD_SA is still in "half-closed" state and will start a new > > IKE_SA from scratch. > > > > Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B > > receives it. What should host B do next? Host B was attempting to rekey > > the IKE SA and needs to retry that operation. Is it acceptable for host B > > to retransmit the CCSA request with the same message ID even though it has > > received a response? > > If B retransmits the CCSA request with same message ID, then host A > will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of > retransmitting old CCSA request with same message ID. > > If IKE SA is in half-closed state and B does not know that yet, then > it means that A has already sent out delete notification for the IKE > SA, and then B sent CCSA before receiving that delete notification, > and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does > not really need to do anything, it should receive delete notification > very soon. Actually the IKE SA is open. Host A sent NO_PROPOSAL_CHOSEN because it received a request to rekey the IKE SA when it had a child SA in half-closed state. Here is the specific scenario I'm interested in: 1) Host A initiates rekey of a child SA. 2) Host B processing of CCSA request triggers rekey of IKE SA due to local lifesize policy. 3) Host B sends CCSA response for child SA. 4) Host B sends CCSA request to rekey IKE SA. 5) Host A receives CCSA response for child SA. 6) Host A sends delete for prior child SA. 7) Host A receives CCSA request to rekey IKE SA but child SA is half-closed. Host A sends NO_PROPOSAL_CHOSEN in CCSA response. 8) Host B receives delete for prior child SA. And responds with empty informational message since it is rekeying the IKE SA. 9) Host B receives CCSA response with NO_PROPOSAL_CHOSEN. 10) Host A receives empty informational message. Should host A do something special when it receives the empty informational message? Is there any reason why it shouldn't close it's child SA since it got a response? > > It can install timer (for example 60 seconds or so), and retry the > operation after that (or it can wait until the hard lifetime is > reached, and delete the old child SA then and then next packet will > trigger new child sa creation). Since this sort of retry isn't a retransmit I suppose an exponential back-off of any subsequent retries isn't required but might be nice. > > If it still fails, it knows there is something wrong with the > syncronization of the both ends, and in that case it should delete the > IKE SA and start from the scratch. > -- > kivinen@iki.fi --=_alternative 0057C0358825755B_= Content-Type: text/html; charset="US-ASCII"
Thanks Tero.  Some more specifics on my scenario and a couple more questions
are included below.

> Tero Kivinen <kivinen@iki.fi> wrote on 02/12/2009 05:30:52 AM:
>
> Keith Welter writes:
> > RFC 4718 section 5.11.8.  Collisions with IKE_SA Rekeying says:
> >    The case where CHILD_SAs are being closed is even worse.  Our
> >    recommendation is that if a host receives a request to rekey the
> >    IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
> >    closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
> >    receives a request to close a CHILD_SA after it has started rekeying
> >    the IKE_SA, it should reply with an empty Informational response.
> >    This ensures that at least the other peer will eventually notice that
> >    the CHILD_SA is still in "half-closed" state and will start a new
> >    IKE_SA from scratch.
> >
> > Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B
> > receives it.  What should host B do next?  Host B was attempting to rekey
> > the IKE SA and needs to retry that operation.  Is it acceptable for host B
> > to retransmit the CCSA request with the same message ID even though it has
> > received a response?
>
> If B retransmits the CCSA request with same message ID, then host A
> will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of
> retransmitting old CCSA request with same message ID.
>
> If IKE SA is in half-closed state and B does not know that yet, then
> it means that A has already sent out delete notification for the IKE
> SA, and then B sent CCSA before receiving that delete notification,
> and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does
> not really need to do anything, it should receive delete notification
> very soon.
Actually the IKE SA is open.  Host A sent NO_PROPOSAL_CHOSEN because it
received a request to rekey the IKE SA when it had a child SA in
half-closed state.  Here is the specific scenario I'm interested in:
1) Host A initiates rekey of a child SA.
2) Host B processing of CCSA request triggers rekey of IKE SA due to
local lifesize policy.
3) Host B sends CCSA response for child SA.
4) Host B sends CCSA request to rekey IKE SA.
5) Host A receives CCSA response for child SA.
6) Host A sends delete for prior child SA.
7) Host A receives CCSA request to rekey IKE SA but child SA is
half-closed.  Host A sends NO_PROPOSAL_CHOSEN in CCSA response.
8) Host B receives delete for prior child SA.  And responds with
empty informational message since it is rekeying the IKE SA.
9) Host B receives CCSA response with NO_PROPOSAL_CHOSEN.
10) Host A receives empty informational message.

Should host A do something special when it receives the empty informational
message?  Is there any reason why it shouldn't close it's child SA since it
got a response?

>
> It can install timer (for example 60 seconds or so), and retry the
> operation after that (or it can wait until the hard lifetime is
> reached, and delete the old child SA then and then next packet will
> trigger new child sa creation).

Since this sort of retry isn't a retransmit I suppose an exponential
back-off of any subsequent retries isn't required but might be nice.

>
> If it still fails, it knows there is something wrong with the
> syncronization of the both ends, and in that case it should delete the
> IKE SA and start from the scratch.
> --
> kivinen@iki.fi
 --=_alternative 0057C0358825755B_=-- From guy.snyder@icsalabs.com Thu Feb 12 14:06:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE4D28C137 for ; Thu, 12 Feb 2009 14:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWKHonVZuwTu for ; Thu, 12 Feb 2009 14:06:17 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 30A853A672F for ; Thu, 12 Feb 2009 14:06:17 -0800 (PST) Received: from pdcismtp02.vzbi.com ([166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEZ000383VQPT00@firewall.verizonbusiness.com> for ipsec@ietf.org; Thu, 12 Feb 2009 22:02:14 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEZ00EA03VQ3700@pdcismtp02.vzbi.com> for ipsec@ietf.org; Thu, 12 Feb 2009 22:02:14 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEZ00D503VQZ500@pdcismtp02.vzbi.com> for ipsec@ietf.org; Thu, 12 Feb 2009 22:02:14 +0000 (GMT) Received: from ASHEVS011.mcilink.com ([153.39.69.138]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 22:02:13 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C98D5D.8F3D248F" Date: Thu, 12 Feb 2009 22:02:13 +0000 Message-id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: IKEv2 Bakeoff V Event - April 6-10 Thread-index: AcmNXY9BEekPdQc0RJ6vEVwpKxgFdA== From: "Snyder, Guy" To: ipsec@ietf.org X-OriginalArrivalTime: 12 Feb 2009 22:02:13.0482 (UTC) FILETIME=[8F716CA0:01C98D5D] Subject: [IPsec] IKEv2 Bakeoff V Event - April 6-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:06:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98D5D.8F3D248F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable To All, =20 Juniper Networks and ICSA Labs are co-hosting the next IKEv2 Bakeoff Event. =20 Tests would be similar to those conducted at the previous bakeoff. These included IPv4, IPv6 and MOBIKE. Your suggestions are always welcome to additions/changes to the suggested tests. The date will be April 6-10 in Sunnyvale, CA. Juniper Networks will be co-hosting this event at their facility. =20 If you are interested in participating please contact me with your level of interest. guy.snyder@icsalabs.com Thank you for your prompt replies. Contact Harry Brittain for pricing and registration. hbrittain@icsalabs.com =20 Last year's results can be found at this location: https://www.icsalabs.com/icsa/docs/html/communities/ipsec/bakeoff/IKEv2_ Interop_Workshop_4_Test_Results_Final.pdf =20 Regards, =20 Guy Snyder Secure Communications Programs Manager ICSA Labs =20 ------_=_NextPart_001_01C98D5D.8F3D248F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

To All,

 

Juniper Networks and ICSA Labs are co-hosting the = next IKEv2 Bakeoff Event.

 

Tests would be similar to those conducted at the = previous bakeoff.  These included IPv4, IPv6 and MOBIKE.  Your = suggestions are always welcome to additions/changes to the suggested tests. The date = will be April 6-10 in Sunnyvale, CA.  Juniper Networks will be co-hosting this event at their facility.

 

If you are interested in participating please contact = me with your level of interest. guy.snyder@icsalabs.com Thank you for your prompt replies.  Contact Harry Brittain for pricing = and registration.  hbrittain@icsalabs.com

 

Last year’s results can be found at this = location:

https://www.icsalabs.c= om/icsa/docs/html/communities/ipsec/bakeoff/IKEv2_Interop_Workshop_4_Test= _Results_Final.pdf

 

Regards,

 

Guy Snyder

Secure Communications Programs = Manager

ICSA Labs

 

------_=_NextPart_001_01C98D5D.8F3D248F-- From wierbows@us.ibm.com Thu Feb 12 20:09:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1613A6BBC for ; Thu, 12 Feb 2009 20:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-1bmIu4eoWj for ; Thu, 12 Feb 2009 20:09:45 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 3D7533A6B1E for ; Thu, 12 Feb 2009 20:09:45 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1D42QXk027722 for ; Thu, 12 Feb 2009 23:02:26 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1D49oBj192862 for ; Thu, 12 Feb 2009 23:09:50 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n1D49nUi030585 for ; Thu, 12 Feb 2009 23:09:49 -0500 Received: from d01mc084.pok.ibm.com (d01mc084.pok.ibm.com [9.63.9.226]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n1D49mMc030578 for ; Thu, 12 Feb 2009 23:09:48 -0500 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Thu, 12 Feb 2009 23:09:46 -0500 X-MIMETrack: Serialize by Router on D01MC084/01/M/IBM(Release 8.0.1|February 07, 2008) at 02/12/2009 23:09:47 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFFCFDF87DD808f9e8a93df938690918c0ABBFFCFDF87DD80" Content-Disposition: inline Subject: [IPsec] Is an empty CertRequest payload valid in 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: , X-List-Received-Date: Fri, 13 Feb 2009 04:09:46 -0000 --0__=0ABBFFCFDF87DD808f9e8a93df938690918c0ABBFFCFDF87DD80 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable In IKEv1 sending empty certificate request was agreed to mean "give me = your cert, any cert". Does this same concept apply to IKEv2? RFC 4306 does= not mention the notion of an empty cert request payload. Section 3.6 of RF= C 4306 implies that one may not need to send a certificate request in ord= er to receive a certificate payload by saying: The Certificate Payload, denoted CERT in this memo, provides a means= to transport certificates or other authentication-related informatio= n via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Likewise, RFC 4945 only mentions the notion of an empty certificate req= uest in Section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) and appendix B which is only referenced by Section 3. If there is no concept of an empty certificate request in IKEv2 why is = the text in section 3.6 a SHOULD and not a MUST? It seems to me that in or= der to ensure interoperability the text in Section 3.6 should read, "Certificate payloads MUST be included in an exchange if certificates a= re available to the sender. An encoding type of Hash and URL of X.509 certificate or Hash and URL of X.509 bundle MAY be used if the peer has= indicated an ability to retrieve this information using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." Dave Wierbowski z/OS Comm Server Developer = --0__=0ABBFFCFDF87DD808f9e8a93df938690918c0ABBFFCFDF87DD80 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

In IKEv1 sending empty certificate request was agreed to mean "= give me your cert, any cert". Does this same concept apply to IKE= v2? RFC 4306 does not mention the notion of an empty cert request payl= oad. Section 3.6 of RFC 4306 implies that one may not need to send a c= ertificate request in order to receive a certificate payload by saying:=

   The Certificate Payload, denoted CERT= in this memo, provides a means
  to transport certificates or other authentication-related infor= mation
  via IKE.  Certificate payloads SHOULD be included in an ex= change if
  certificates are available to the sender unless the peer has   indicated an ability to retrieve this information from elsewher= e
  using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

Likewise, RFC 4945 only mentions the notion of an empty certificate req= uest in Section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) an= d appendix B which is only referenced by Section 3.

If there is no concept of an empty certificate request in IKEv2 why is = the text in section 3.6 a SHOULD and not a MUST? It seems to me that i= n order to ensure interoperability the text in Section 3.6 should read,= "Certificate payloads MUST be included in an exchange if certific= ates are available to the sender. An encoding type of Hash and URL of = X.509 certificate or Hash and URL of X.509 bundle MAY be used if the pe= er has indicated an ability to retrieve this information using an HTTP_= CERT_LOOKUP_SUPPORTED Notify payload."

Dave Wierbowski


z/OS Comm Server Developer


= --0__=0ABBFFCFDF87DD808f9e8a93df938690918c0ABBFFCFDF87DD80-- From manav@alcatel-lucent.com Thu Feb 12 23:04:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD7F3A6836 for ; Thu, 12 Feb 2009 23:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 c92-j8EI0bjL for ; Thu, 12 Feb 2009 23:04:49 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 30EB53A6784 for ; Thu, 12 Feb 2009 23:04:48 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1D74gaL027166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Feb 2009 08:04:51 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 13 Feb 2009 08:04:44 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 13 Feb 2009 12:31:00 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen , "Grewal, Ken" Date: Fri, 13 Feb 2009 12:30:59 +0530 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmMQTGZOIAIkkwrTHqbvFLdTMV7wABYhIXw Message-ID: <7C362EEF9C7896468B36C9B79200D8357901AFF1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> <18834.48954.47580.62256@fireball.kivinen.iki.fi> In-Reply-To: <18834.48954.47580.62256@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "ipsec@ietf.org" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 13 Feb 2009 07:04:50 -0000 >=20 > > BTW, insider threats are on the rise according to various public > > reports, so should not be discounted. This is one of the motivations > > of employing security, even within the Enterprise. >=20 > Yes, but I do not really think people are going to solve those using > ESP-NULL. I think they must move to encrypted ESP to provide > confidentiality also, and that makes the need for ESP-NULL visibility > even less. I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors will im= plement ESP (besides the problem of AH being NAT unfriendly). All applicati= ons (OSPFv3, RIPng, etc), and there are many, which don't care about confid= entiality, but are only concerned with authentication and integrity assuran= ce, will continue using ESP-NULL.=20 Thus there is a need for ESP-NULL visibility.=20 Cheers, Manav > > For example most of the insider information (insider trading, leaking > trade secrets, espionage) problems cannot be solved by using ESP-NULL. >=20 > > [Ken] Perhaps there is a migration path consideration, where > > heuristics can offer interim benefits until a more deterministic > > solution is adopted. Adoption of either / both / neither will be > > ultimately based on numerous factors, including value, customer > > demand, etc. >=20 > This I agree and I have even tried to bring this up in my draft (see > last paragraph in the introduction section). > --=20 From kivinen@iki.fi Fri Feb 13 04:03:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DB13A68C4 for ; Fri, 13 Feb 2009 04:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKCRyxbSVpx2 for ; Fri, 13 Feb 2009 04:03:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 516743A6B36 for ; Fri, 13 Feb 2009 04:03:42 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1DC3kvh018910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 14:03:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1DC3jhb023490; Fri, 13 Feb 2009 14:03:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.24993.189637.815037@fireball.kivinen.iki.fi> Date: Fri, 13 Feb 2009 14:03:45 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: [IPsec] Is an empty CertRequest payload valid in 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: , X-List-Received-Date: Fri, 13 Feb 2009 12:03:44 -0000 David Wierbowski writes: > If there is no concept of an empty certificate request in IKEv2 why is the > text in section 3.6 a SHOULD and not a MUST? It seems to me that in order > to ensure interoperability the text in Section 3.6 should read, > "Certificate payloads MUST be included in an exchange if certificates are > available to the sender. An encoding type of Hash and URL of X.509 > certificate or Hash and URL of X.509 bundle MAY be used if the peer has > indicated an ability to retrieve this information using an > HTTP_CERT_LOOKUP_SUPPORTED Notify payload." There are good reasons not to send certificates in some cases. For example if you use certificate infrastructure where you know each end do have ability to fetch the certificates based on the ID (for example there is LDAP/HTTP/DB access that all certificates users are using for getting certificates), then it would not be beneficial to send certificates every time you make IKE SA. In normal cases you SHOULD send them (perhaps in HASH and URL form if that is supported). In some cases you might know you do not need to so, so in that cases you can ignore that SHOULD and not send them. So the default for IKEv2 is the same as if in IKEv1 you had sent empty certificate request. If you have certificates then you should send them. -- kivinen@iki.fi From kivinen@iki.fi Fri Feb 13 04:05:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD293A683E for ; Fri, 13 Feb 2009 04:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0wiWozi7zZBq for ; Fri, 13 Feb 2009 04:05:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B91D33A67B1 for ; Fri, 13 Feb 2009 04:05:33 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1DC5Vq8019055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 14:05:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1DC5Uij010349; Fri, 13 Feb 2009 14:05:30 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.25098.49974.508923@fireball.kivinen.iki.fi> Date: Fri, 13 Feb 2009 14:05:30 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8357901AFF1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> <18834.48954.47580.62256@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8357901AFF1@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: "ipsec@ietf.org" , "Grewal, Ken" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 13 Feb 2009 12:05:35 -0000 Bhatia, Manav (Manav) writes: > > > > > BTW, insider threats are on the rise according to various public > > > reports, so should not be discounted. This is one of the motivations > > > of employing security, even within the Enterprise. > > > > Yes, but I do not really think people are going to solve those using > > ESP-NULL. I think they must move to encrypted ESP to provide > > confidentiality also, and that makes the need for ESP-NULL visibility > > even less. > > I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors > will implement ESP (besides the problem of AH being NAT unfriendly). > All applications (OSPFv3, RIPng, etc), and there are many, which > don't care about confidentiality, but are only concerned with > authentication and integrity assurance, will continue using > ESP-NULL. > > Thus there is a need for ESP-NULL visibility. What kind of deep inspection you are doing on the OSPFv3 and RIPng in the middle boxes? I.e. why does middle boxes need to know anything about the actual data contents of those protocols? You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility is needed. -- kivinen@iki.fi From manav@alcatel-lucent.com Fri Feb 13 05:23:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A1528C250 for ; Fri, 13 Feb 2009 05:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 5krystmV+LBK for ; Fri, 13 Feb 2009 05:23:25 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id DC1F628C24B for ; Fri, 13 Feb 2009 05:23:24 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1DDNTO9031324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Feb 2009 14:23:29 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 13 Feb 2009 14:23:28 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 13 Feb 2009 18:52:06 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Fri, 13 Feb 2009 18:52:04 +0530 Thread-Topic: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Thread-Index: AcmN02U3j3N09pRrRfqJMba2W5QwUQACcv1g Message-ID: <7C362EEF9C7896468B36C9B79200D8357901B1EA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> <18834.48954.47580.62256@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8357901AFF1@INBANSXCHMBSA1.in.alcatel-lucent.com> <18837.25098.49974.508923@fireball.kivinen.iki.fi> In-Reply-To: <18837.25098.49974.508923@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "ipsec@ietf.org" , "Grewal, Ken" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 13 Feb 2009 13:23:26 -0000 > > > Yes, but I do not really think people are going to solve=20 > those using > > > ESP-NULL. I think they must move to encrypted ESP to provide > > > confidentiality also, and that makes the need for=20 > ESP-NULL visibility > > > even less. > >=20 > > I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors > > will implement ESP (besides the problem of AH being NAT unfriendly). > > All applications (OSPFv3, RIPng, etc), and there are many, which > > don't care about confidentiality, but are only concerned with > > authentication and integrity assurance, will continue using > > ESP-NULL. =20 > >=20 > > Thus there is a need for ESP-NULL visibility.=20 >=20 > What kind of deep inspection you are doing on the OSPFv3 and RIPng in > the middle boxes? I.e. why does middle boxes need to know anything > about the actual data contents of those protocols? >=20 > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility > is needed.=20 One might want to filter OSPFv3 packets coming from outside the domain. Then when you're the end node, you might want to prioritize some OSPF packe= ts over the others. I understand that the latter is an implementation speci= fic issue, but it helps if the underlying protocol is amenable for deep ins= pection. Cheers, Manav= From kivinen@iki.fi Fri Feb 13 05:37:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2031F3A698F for ; Fri, 13 Feb 2009 05:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCf7j969u3yD for ; Fri, 13 Feb 2009 05:37:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 25F293A67B0 for ; Fri, 13 Feb 2009 05:37:16 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1DDbK18011904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 15:37:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1DDbJWm023990; Fri, 13 Feb 2009 15:37:19 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.30607.702502.588750@fireball.kivinen.iki.fi> Date: Fri, 13 Feb 2009 15:37:19 +0200 From: Tero Kivinen To: Keith Welter In-Reply-To: References: <18836.9356.41857.765122@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 8 min Cc: ipsec@ietf.org, Thomas McSweeney Subject: Re: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:37:20 -0000 Keith Welter writes: > Actually the IKE SA is open. Host A sent NO_PROPOSAL_CHOSEN because it > received a request to rekey the IKE SA when it had a child SA in > half-closed state. Here is the specific scenario I'm interested in: > 1) Host A initiates rekey of a child SA. > 2) Host B processing of CCSA request triggers rekey of IKE SA due to > local lifesize policy. > 3) Host B sends CCSA response for child SA. > 4) Host B sends CCSA request to rekey IKE SA. > 5) Host A receives CCSA response for child SA. > 6) Host A sends delete for prior child SA. > 7) Host A receives CCSA request to rekey IKE SA but child SA is > half-closed. Host A sends NO_PROPOSAL_CHOSEN in CCSA response. > 8) Host B receives delete for prior child SA. And responds with > empty informational message since it is rekeying the IKE SA. > 9) Host B receives CCSA response with NO_PROPOSAL_CHOSEN. > 10) Host A receives empty informational message. I think B should send delete for the old child SA immediately when the IKE SA failed, i.e. when A replied with NO_PROPOSAL_CHOSEN, as after that it is no longer rekeying IKE SA. When host A receives that the old child SA has been deleted completely, and after that host B can restart IKE SA rekey. > Should host A do something special when it receives the empty > informational message? Yes, it should mark down it has half-closed child SA, and if the situation is not fixed in next few minutes, then it should delete whole IKE SA and start over. > Is there any reason why it shouldn't close it's child SA since it > got a response? It got response, but other end didn't close his end of the child SA. It should wait for the other end to close down the child SA. If the other end closes it, then it will return back to normal. If other end does not close it in few minutes (say 5 minutes), then it should delete IKE SA and start over. See section 1.4 of RFC4306: A node SHOULD regard half-closed connections as anomalous and audit their existence should they persist. Note that this specification nowhere specifies time periods, so it is up to individual endpoints to decide how long to wait. A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs. If connection state becomes sufficiently messed up, a node MAY close the IKE_SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE_SA. I.e. MUST NOT unilaterally close, and if state beecomse sufficiently messed up, MAY close IKE SA. > > It can install timer (for example 60 seconds or so), and retry the > > operation after that (or it can wait until the hard lifetime is > > reached, and delete the old child SA then and then next packet will > > trigger new child sa creation). > > Since this sort of retry isn't a retransmit I suppose an exponential > back-off of any subsequent retries isn't required but might be nice. I do not think there will be that many retries. If the second try fails again, it usually means there is something messed up, so it might be better to delete old IKE SA and start over as I said here: > > If it still fails, it knows there is something wrong with the > > syncronization of the both ends, and in that case it should delete the > > IKE SA and start from the scratch. -- kivinen@iki.fi From kivinen@iki.fi Fri Feb 13 05:41:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D1E3A6B44 for ; Fri, 13 Feb 2009 05:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emAZDzM4bNoU for ; Fri, 13 Feb 2009 05:41:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C88B13A67B0 for ; Fri, 13 Feb 2009 05:41:21 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1DDfKWW009952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 15:41:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1DDfIb2027482; Fri, 13 Feb 2009 15:41:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.30846.818937.947289@fireball.kivinen.iki.fi> Date: Fri, 13 Feb 2009 15:41:18 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8357901B1EA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA418762035@zrtphxm2.corp.nortel.com> <18824.17079.363126.331101@fireball.kivinen.iki.fi> <18826.54339.452491.244002@fireball.kivinen.iki.fi> <18832.15242.707313.57888@fireball.kivinen.iki.fi> <18834.48954.47580.62256@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8357901AFF1@INBANSXCHMBSA1.in.alcatel-lucent.com> <18837.25098.49974.508923@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8357901B1EA@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" , "Grewal, Ken" , Dragan Grebovich Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics 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: , X-List-Received-Date: Fri, 13 Feb 2009 13:41:23 -0000 Bhatia, Manav (Manav) writes: > > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility > > is needed. > > One might want to filter OSPFv3 packets coming from outside the domain. It is much better to do that check on the OSPFv3 receiver end where the packet is actually authenticated by ESP-NULL, and which has much better knowledge who is authorized to send what. I do not know OSPFv3 that well, so I do not know how you tell which packets are coiming outside of domain (as IP-addresses are not authenticated in ESP-NULL, so those cannot be checked), so I cannot really tell whether that check is doable or not. So what are the exact checks you are doing and where inside the OSFPv3 packet content are those fields, and what do they gain compared of doing the same checks on the final OSPFv3 receiver? > Then when you're the end node, you might want to prioritize some > OSPF packets over the others. I understand that the latter is an > implementation specific issue, but it helps if the underlying > protocol is amenable for deep inspection. End node already has all ESP-NULL related information, there is no need for ESP-NULL visibility there. -- kivinen@iki.fi From paul.hoffman@vpnc.org Sat Feb 14 17:05:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621803A68E5 for ; Sat, 14 Feb 2009 17:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmq5yVZPngHN for ; Sat, 14 Feb 2009 17:05:49 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5D6BC3A6B44 for ; Sat, 14 Feb 2009 17:05:13 -0800 (PST) Received: from [10.20.30.158] (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 n1F15HjV050191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Feb 2009 18:05:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 14 Feb 2009 17:05:15 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] First cut of the IETF 74 agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 01:05:50 -0000 ... is at . The IPsecME WG is scheduled to meet Friday morning, March 27. This slot could change, but we do not have any indication at this time that it will. If you are making travel arrangements and want to attend the WG meeting, please plan accordingly. We will put together the agenda for the WG meeting in the coming weeks. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Feb 15 10:23:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D33F3A6ACD for ; Sun, 15 Feb 2009 10:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z94jEMq2H-gT for ; Sun, 15 Feb 2009 10:23:48 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 225283A6AC1 for ; Sun, 15 Feb 2009 10:23:47 -0800 (PST) Received: from [10.20.30.158] (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 n1FINs1G081276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Feb 2009 11:23:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 15 Feb 2009 10:23:52 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Closing more IKEv2bis issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:23:49 -0000 Here is the status of the open issues that we discussed at the interim WG meeting in early February. If you want to discuss any of them, please do not reply to this message but instead start a thread with the issue number in the subject. --Paul Hoffman Issue #36, Interaction of IKE_SA_INIT retransmissions with specific notifies. No comments, but it seems like a valid minor addition; accepted. Issue #14: Bounding the retransmit time. Small amount of discussion; accepted. Wording will indicate that this is optional for the one closing the window but should be anticipated by the party waiting a long time. Issue #19: Motivation for including SPIs in the cookie. No comments, but seems harmless. Accepted. Issue #62: Security considerations - implementation robustness. Accepted. Issue #16 and #45: Order of IKE payloads. Agreement that we cannot change the requirement in RFC 4306, but disagreement on what that means, particularly because RFC 4306 requires a small subset of the required ordering. Paul will propose some new text. Issue #11: Clarify which traffic selectors to use in rekeying. Not accepted because some people may be doing decorrelating, but others might not be doing it. Issue #68: Counter mode ciphers in IKEv2 to protect IKE SA. General agreement that the document specifies that IV needs to be unpredictable for CBC, and gives a reference to other docs for the non-CBC modes. Paul will republish text for this issue. From paul.hoffman@vpnc.org Sun Feb 15 12:10:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BDC3A6925 for ; Sun, 15 Feb 2009 12:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lB1IFIRCtP5H for ; Sun, 15 Feb 2009 12:10:44 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CF2C83A699F for ; Sun, 15 Feb 2009 12:10:43 -0800 (PST) Received: from [10.20.30.158] (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 n1FKAnXP084367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Feb 2009 13:10:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 15 Feb 2009 12:10:48 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:10:45 -0000 Greetings again. We have not come to resolution on this topic, and we should make another attempt before we give up. RFC 4306 says: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. There are a few problems with this. For one, there are payloads that are only a few figures in section 2; there are many more figures in section 1. Another problem is that there are plenty of payloads that are defined in RFC 4306 that are not shown in any figure in section 2; these are not "future" but current payloads. I see three options: a) Downgrade the MUST to a SHOULD without other changes. b) Remove this altogether because the paragraph is insufficient for implementation and, in part, wrong. c) Do nothing. Both (a) and (b) will cause implementations that follow the MUST and SHOULD in the paragraph to not interoperate with implementations that do not follow the given order. (a) is not completely clear. (c) leaves insufficient and unclear mandates in the document. So far, no one has said that their implementation will fail if it gets payloads that it thinks are not in the order shown in section 2. On the other hand, not all implementers of IKEv2 are reading the drafts or following this list, so that is far from definitive. Thoughts? Other ways forwards? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Feb 15 12:12:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3523A6AAA for ; Sun, 15 Feb 2009 12:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLv2PLo2c63v for ; Sun, 15 Feb 2009 12:12:51 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 56FAB3A6925 for ; Sun, 15 Feb 2009 12:12:51 -0800 (PST) Received: from [10.20.30.158] (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 n1FKCvbJ084520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Feb 2009 13:12:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> Date: Sun, 15 Feb 2009 12:12:56 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:12:52 -0000 This issue is still open and does not appear to be moving towards consensus. Please speak up with your opinions about the topic. Also say whether or not you care if this gets reflected in IKEv2bis. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Sun Feb 15 22:15:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E3E3A6783 for ; Sun, 15 Feb 2009 22:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tgqb8vvGzyC for ; Sun, 15 Feb 2009 22:15:49 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9302B3A67A8 for ; Sun, 15 Feb 2009 22:15:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B550C29C004; Mon, 16 Feb 2009 08:15:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 90F0829C002; Mon, 16 Feb 2009 08:15:55 +0200 (IST) X-CheckPoint: {49990413-10001-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1G6Fsv3028540; Mon, 16 Feb 2009 08:15:55 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 16 Feb 2009 08:15:54 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Mon, 16 Feb 2009 08:15:53 +0200 Thread-Topic: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) Thread-Index: AcmPrHAqhT6Zl4ShShOE6JYPJFtnsAAUJtsw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BEC9E0@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 06:15:49 -0000 Hi Paul, Thanks for the lucid analysis. To muddy the water some more, http://tools.i= etf.org/html/draft-ietf-ipsec-ikev2-04 has this same paragraph refer to wha= t is today Sec. 1 of the RFC, the "right" section, the one that describes a= ll the base exchanges. However in -05, this was already changed (but with n= o mention in the change log). Clearly 6 years ago, someone intended IKEv2 p= ayloads to be in order. This does not obligate us today though. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Sunday, February 15, 2009 22:11 > To: IPsecme WG > Subject: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) >=20 > Greetings again. We have not come to resolution on this topic, and we > should make another attempt before we give up. >=20 > RFC 4306 says: > Although new payload types may be added in the future and may appear > interleaved with the fields defined in this specification, > implementations MUST send the payloads defined in this specification > in the order shown in the figures in section 2 and implementations > SHOULD reject as invalid a message with those payloads in any other > order. >=20 > There are a few problems with this. For one, there are payloads that are > only a few figures in section 2; there are many more figures in section 1= . > Another problem is that there are plenty of payloads that are defined in > RFC 4306 that are not shown in any figure in section 2; these are not > "future" but current payloads. >=20 > I see three options: >=20 > a) Downgrade the MUST to a SHOULD without other changes. >=20 > b) Remove this altogether because the paragraph is insufficient for > implementation and, in part, wrong. >=20 > c) Do nothing. >=20 > Both (a) and (b) will cause implementations that follow the MUST and > SHOULD in the paragraph to not interoperate with implementations that do > not follow the given order. (a) is not completely clear. (c) leaves > insufficient and unclear mandates in the document. >=20 > So far, no one has said that their implementation will fail if it gets > payloads that it thinks are not in the order shown in section 2. On the > other hand, not all implementers of IKEv2 are reading the drafts or > following this list, so that is far from definitive. >=20 > Thoughts? Other ways forwards? >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From yaronf@checkpoint.com Mon Feb 16 01:46:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1501B3A67C0 for ; Mon, 16 Feb 2009 01:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OlTZO4l0e09x for ; Mon, 16 Feb 2009 01:46:49 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 280F43A6B70 for ; Mon, 16 Feb 2009 01:46:49 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 08FBD29C004; Mon, 16 Feb 2009 11:46:58 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 93C6029C002 for ; Mon, 16 Feb 2009 11:46:00 +0200 (IST) X-CheckPoint: {4999354F-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1G9jxv3022222 for ; Mon, 16 Feb 2009 11:46:00 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 16 Feb 2009 11:45:59 +0200 From: Yaron Sheffer To: IPsecme WG Date: Mon, 16 Feb 2009 11:45:56 +0200 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 09:46:50 -0000 This is a 2 week working group last call for draft-ietf-ipsecme-ikev2-redir= ect-04. The target status for this document is Proposed Standard. =20 Please send your comments to the ipsec list by March 2, 2009, as follow-ups= to this message. Please clearly indicate the position of any issue in the Internet Draft, an= d if possible provide alternative text. Please also indicate the nature or = severity of the error or correction, e.g. major technical, minor technical,= nit, so that we can quickly judge the extent of problems with the document= . The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ip= secme-ikev2-redirect-04. Please note that one issue is currently open against this draft: http://too= ls.ietf.org/wg/ipsecme/trac/ticket/82. Thanks, Yaron Email secured by Check Point From A.Hoenes@tr-sys.de Sun Feb 15 13:52:02 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3603A6988 for ; Sun, 15 Feb 2009 13:52:02 -0800 (PST) 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=1.100, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl1fE4atCVSq for ; Sun, 15 Feb 2009 13:52:01 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C86893A6781 for ; Sun, 15 Feb 2009 13:52:00 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA132224619; Sun, 15 Feb 2009 22:50:19 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA20165; Sun, 15 Feb 2009 22:50:18 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902152150.WAA20165@TR-Sys.de> To: paul.hoffman@vpnc.org, ipsec@ietf.org Date: Sun, 15 Feb 2009 22:50:17 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 16 Feb 2009 08:02:34 -0800 Subject: Re: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 21:52:02 -0000 At Sun, 15 Feb 2009 12:10:48 -0800, Paul Hoffman wrote: > Greetings again. We have not come to resolution on this topic, and we > should make another attempt before we give up. > > RFC 4306 says: >| Although new payload types may be added in the future and may appear >| interleaved with the fields defined in this specification, >| implementations MUST send the payloads defined in this specification >| in the order shown in the figures in section 2 and implementations >| SHOULD reject as invalid a message with those payloads in any other >| order. > > There are a few problems with this. For one, there are payloads that > are only a few figures in section 2; there are many more figures in > section 1. Another problem is that there are plenty of payloads that > are defined in RFC 4306 that are not shown in any figure in section 2; > these are not "future" but current payloads. > > I see three options: > > a) Downgrade the MUST to a SHOULD without other changes. > > b) Remove this altogether because the paragraph is insufficient for > implementation and, in part, wrong. > > c) Do nothing. > > Both (a) and (b) will cause implementations that follow the MUST and > SHOULD in the paragraph to not interoperate with implementations that > do not follow the given order. (a) is not completely clear. > (c) leaves insufficient and unclear mandates in the document. > > So far, no one has said that their implementation will fail if it gets > payloads that it thinks are not in the order shown in section 2. On > the other hand, not all implementers of IKEv2 are reading the drafts > or following this list, so that is far from definitive. > > Thoughts? Other ways forwards? > > --Paul Hoffman, Director > --VPN Consortium The issue clearly extends to sequencing requirements in extension specifications, and such requirements can also be stated in the prose. Therefore, I would prefer to revert to Postel's Principle, and describe the guiding principles more precisely and more general. Changing the MUST to a SHOULD for the sender will add some amount of flexibility; IMO, the requirement for the receiver could be dropped. Thus, unless existing implementations indeed insist on the original order rules at the receiver side, I suggest the following text: | New payload types may be added in the future and may appear | interleaved with the fields defined in this specification. | Implementations SHOULD send payloads in the order specified in the | text and the figures of this document and extension documents -- with | priority to text and to this document -- unless specified explicitely | in a different or more stringent manner. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From paul.hoffman@vpnc.org Mon Feb 16 16:35:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188CA3A6852 for ; Mon, 16 Feb 2009 16:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU59rOte2pZB for ; Mon, 16 Feb 2009 16:35:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 647543A6842 for ; Mon, 16 Feb 2009 16:35:52 -0800 (PST) Received: from [10.20.30.158] (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 n1H0ZxYh053005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Feb 2009 17:36:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> Date: Mon, 16 Feb 2009 16:35:57 -0800 To: From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:35:54 -0000 At 12:48 PM -0800 1/25/09, Paul Hoffman wrote: >Yes, definitely. At this point, we have heard from two groups of authors; hearing from the wider implementers community would be valuable. We still have not heard from many. During the interim meeting, a good question was raised: are we making this decision based on implementation desires vs. protocol cleanliness vs. deployment ability. We don't have enough input at this point to pick between those. So, let me get this thread going again. If you have an opinion about the core issue of how session resumption is done (extend the IKE_SA_INIT or create a new exchange type), please state it again and say what draws you to this conclusion. This is *not* a vote: it is a request to get the discussion going with some hopefully better metrics. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Tue Feb 17 02:03:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AFD28C148 for ; Tue, 17 Feb 2009 02:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=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 bae0LRcjdWBc for ; Tue, 17 Feb 2009 02:03:00 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1C3CB28C147 for ; Tue, 17 Feb 2009 02:03:00 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 07A3B29C004; Tue, 17 Feb 2009 12:03:01 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D6A9729C002 for ; Tue, 17 Feb 2009 12:02:59 +0200 (IST) X-CheckPoint: {499A8AC1-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1HA2xsZ015481 for ; Tue, 17 Feb 2009 12:02:59 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 17 Feb 2009 12:02:59 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Tue, 17 Feb 2009 12:03:32 +0200 Thread-Topic: Issue #22: simultaneous IKE SA rekeys Thread-Index: AcmQl7tzWnmrD5UMQMKJjKJHB2nQlgAPlCLg Message-ID: <9FB7C7CE79B84449B52622B506C7803613328A03D5@il-ex01.ad.checkpoint.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #22: simultaneous IKE SA rekeys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:03:01 -0000 =20 Hi all. Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed = simultaneously by both peers. Issue #22 asks to clarify the same thing for = simultaneous rekeying of IKE SAs. We've written a proposed additional section, that should be labeled 2.8.2. = Since this specifies new behavior that was not specified before, we want yo= ur comments before putting this into the draft. Thanks Yoav 2.8.2. Simultaneous IKE SA rekeying If the two ends have the same key lifetime policies for IKE SAs, it is possible that both will initiate a rekeying at the same time. This is unacceptable for IKE SAs, because the IKE SAs own the child SAs, and deleting the IKE SA leeds to deletion of all child SAs. To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed). To avoid the case of two IKE SAs created by simultaneous CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the initiator nonces is silently discarded, and the dependent child SAs are transferred only to the IKE SA with the higher of the two initiator nonces. Here "higher" and "lower" refer to octet-by-octet, lexicographical comparison of the nonces as large integers. The rules are as follows: 1. If a rekey request is received before this host has sent a rekey request of its own, this host MUST NOT send a rekey request. Instead, it MUST reply to the rekey request it has received. 2. If a rekey request is received after this host has sent a rekey request, then this host MUST compare the two initiator nonce values. If the received nonce is higher than its own, it MUST reply to the received request, and SHOULD stop retransmissions of its own request. If the received nonce is lower, it MUST ignore the received request. 3. If a rekey request is received after this host has sent a rekey request, and the peer has already replied, the new received request MUST be ignored. Following these rules should prevent any case of multiple successful rekeys of an IKE SA. The only case where the 2nd rule would be needed is if both requests were sent before either of them was processed. The implementation whose rekey request was answered SHOULD delete the old IKE SA soon after. The other implementation SHOULD wait at least one minute before deleting the IKE SA unless its peer requests the deletion earlier. The following is an explanation of the impact this has on implementations. Assume that hosts A and B have an existing IKE SA, and both start rekeying it at the same time: Host A Host B ----------------------------------------------------------------- send req1: SK{SA, Ni1, [KEi]} --> <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- At this point, host A knows there is a simultaneous rekeying going on. Assume that Ni2 recv req1 Now host B also knows that simultaneous rekeying is going on. It has also figured out that req1 is the one to respond to, so it does so. <-- send resp1: SK {SA, Nr,[KEr]} recv resp1 <-- Now let's look at the other case, namely where Ni1 <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- Host A knows that req1 is the one to ignore, because req2 has a higher nonce. It replies to req2, and will not re-transmit req1. send resp2: SK {SA, Nr,[KEr]} --> recv req1 Now host B is in exactly the same position as host A was in the first example. It compares nonces, and ignores req1. --> recv resp2 Host B now knows that the rekey is complete. To demonstrate the third rule, let's assume again that Ni1 <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- --> recv resp2 Now host B knows nothing about req1, and assumes that its rekey request was the only one. Host A, however, is aware of the simultaneous rekey, and has decided that only req2 is to proceed. --> recv req1 Host B now knows about req1, but since it has already received a response, it ignores req1. There is no need to compare nonces. Email secured by Check Point From kivinen@iki.fi Tue Feb 17 04:45:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D359A3A6A3B for ; Tue, 17 Feb 2009 04:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9wYwQR1uW-2 for ; Tue, 17 Feb 2009 04:45:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C43E13A697F for ; Tue, 17 Feb 2009 04:45:27 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1HCjZgo003712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 14:45:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1HCjXxD020097; Tue, 17 Feb 2009 14:45:33 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18842.45421.943263.509696@fireball.kivinen.iki.fi> Date: Tue, 17 Feb 2009 14:45:33 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG Subject: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 12:45:28 -0000 Paul Hoffman writes: > RFC 4306 says: > Although new payload types may be added in the future and may appear > interleaved with the fields defined in this specification, > implementations MUST send the payloads defined in this specification > in the order shown in the figures in section 2 and implementations > SHOULD reject as invalid a message with those payloads in any other > order. > > a) Downgrade the MUST to a SHOULD without other changes. I think that should be fine, but I think more important would be to change "SHOULD reject" to "SHOULD NOT reject" or even "MUST NOT reject". As I do not think anybody currently follows this SHOULD I think that should not make any current real implementations incompatible with new versions. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Feb 17 06:55:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7003A6B56 for ; Tue, 17 Feb 2009 06:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5EVHUzvm2UU9 for ; Tue, 17 Feb 2009 06:55:58 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C69C43A6822 for ; Tue, 17 Feb 2009 06:55:57 -0800 (PST) Received: from [10.20.30.158] (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 n1HEu5EG089795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Feb 2009 07:56:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 17 Feb 2009 06:56:05 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Potential way forward for IPsecME on ESP-NULL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 14:55:58 -0000 Wearing our one-size-fits-all shared co-chair hat, Yaron and I propose the following. - Both documents can continue forwards, adding the heuristics document as a WG item. Pasi has agreed that the current WG charter allows this. - The heuristics document would eventually be published as an Informational RFC. WESP would be the protocol produced by the WG. - The purpose of the heuristics document would be to help deep-inspection firewall vendors find ESP-NULL traffic that is not encapsulated with WESP. It is considered an educational document for firewall developers who might want to do heuristic checks on ESP traffic. Firewalls might want to do this until WESP is widely deployed, or even after wide deployment if sufficient firewall resources are available in order to check for ESP-NULL that is not yet wrapped in WESP. - Each document talks about the applicability of its own content, while referring to the other document. Are there any strong objections to this plan? --Paul Hoffman, Director --VPN Consortium From wierbows@us.ibm.com Tue Feb 17 06:58:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2FC3A6B83 for ; Tue, 17 Feb 2009 06:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpodRO23S1PS for ; Tue, 17 Feb 2009 06:58:14 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 5DAC93A6B5C for ; Tue, 17 Feb 2009 06:58:14 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1HEuHGP009686 for ; Tue, 17 Feb 2009 09:56:17 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1HEwOtg191122 for ; Tue, 17 Feb 2009 09:58:24 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1HEwOI7002208 for ; Tue, 17 Feb 2009 09:58:24 -0500 Received: from d01mc084.pok.ibm.com (d01mc084.pok.ibm.com [9.63.9.226]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1HEwOwU002200 for ; Tue, 17 Feb 2009 09:58:24 -0500 In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613328A03D5@il-ex01.ad.checkpoint.com> To: "ipsec@ietf.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Tue, 17 Feb 2009 09:58:24 -0500 X-MIMETrack: Serialize by Router on D01MC084/01/M/IBM(Release 8.0.1|February 07, 2008) at 02/17/2009 09:58:24 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2" Subject: Re: [IPsec] Issue #22: simultaneous IKE SA rekeys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 14:58:16 -0000 --0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: multipart/alternative; Boundary="1__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2" --1__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I do not believe the algorithm below is consistent with what was said i= n section 5.11.4 of RFC 4718. Section 5.11.4 of RFC 4718 said: 5.11.4. Simultaneous IKE_SA Rekeying Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case as well; however, it is important to ensure tha= t the CHILD_SAs are inherited by the right IKE_SA. The case where both endpoints notice the simultaneous rekeying works= the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges= , three IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs. "After the CREATE_CHILD_SA exchanges" implies the exchanges are expecte= d to complete before the simultaneous rekey is resolved. The algorithm belo= w resolves the simultaneous rekey during the CREATE_CHILD_SA exchange and= only allows one rekey to complete. My concern is that the algorithm be= low will be incompatible with anybody that implemented to RFC 4718. A slight tangent to this is that the possibility of a simultaneous reauthentication exists, however, RFC 4306, RFC 4718, and the current b= is draft does not address that scenario. Given that the a reauthenticatio= n is done by creating a new IKE_SA from scratch I'm not even sure if it is possible to detect a simultaneous reauthentication of an IKE_SA, but it= would be nice if we could. = Yoav Nir = = To Sent by: "ipsec@ietf.org" ipsec-bounces@iet = cc f.org = Subj= ect [IPsec] Issue #22: simultaneous = IKE 02/17/2009 05:03 SA rekeys = AM = = = = = = Hi all. Section 2.8.1 of the draft discusses what to do when Child SAs are reke= yed simultaneously by both peers. Issue #22 asks to clarify the same thing = for simultaneous rekeying of IKE SAs. We've written a proposed additional section, that should be labeled 2.8= .2. Since this specifies new behavior that was not specified before, we wan= t your comments before putting this into the draft. Thanks Yoav 2.8.2. Simultaneous IKE SA rekeying If the two ends have the same key lifetime policies for IKE SAs, it is possible that both will initiate a rekeying at the same time. This is unacceptable for IKE SAs, because the IKE SAs own the child SAs, and deleting the IKE SA leeds to deletion of all child SAs. To= reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time afte= r the need for rekeying is noticed). To avoid the case of two IKE SAs created by simultaneous CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the initiator nonces is silently discarded, and the dependent child SAs are transferred only to the IKE SA with the higher of the two initiator nonces. Here "higher" and "lower" refer to octet-by-octet= , lexicographical comparison of the nonces as large integers. The rules are as follows: 1. If a rekey request is received before this host has sent a rekey= request of its own, this host MUST NOT send a rekey request. Instead, it MUST reply to the rekey request it has received. 2. If a rekey request is received after this host has sent a rekey request, then this host MUST compare the two initiator nonce values. If the received nonce is higher than its own, it MUST reply to the received request, and SHOULD stop retransmissions o= f its own request. If the received nonce is lower, it MUST ignore= the received request. 3. If a rekey request is received after this host has sent a rekey request, and the peer has already replied, the new received request MUST be ignored. Following these rules should prevent any case of multiple successful= rekeys of an IKE SA. The only case where the 2nd rule would be needed is if both requests were sent before either of them was processed. The implementation whose rekey request was answered SHOULD delete the old IKE SA soon after. The other implementation SHOULD wait at least one minute before deleting the IKE SA unless it= s peer requests the deletion earlier. The following is an explanation of the impact this has on implementations. Assume that hosts A and B have an existing IKE SA,= and both start rekeying it at the same time: Host A Host B -----------------------------------------------------------------= send req1: SK{SA, Ni1, [KEi]} --> <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- At this point, host A knows there is a simultaneous rekeying going on. Assume that Ni2 recv req1 Now host B also knows that simultaneous rekeying is going on. It ha= s also figured out that req1 is the one to respond to, so it does so. <-- send resp1: SK {SA, Nr,[KEr]} recv resp1 <-- Now let's look at the other case, namely where Ni1 <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- Host A knows that req1 is the one to ignore, because req2 has a higher nonce. It replies to req2, and will not re-transmit req1. send resp2: SK {SA, Nr,[KEr]} --> recv req1 Now host B is in exactly the same position as host A was in the firs= t example. It compares nonces, and ignores req1. --> recv resp2 Host B now knows that the rekey is complete. To demonstrate the third rule, let's assume again that Ni1 <-- send req2: SK{SA, Ni2, [KEi]} recv req2 <-- --> recv resp2 Now host B knows nothing about req1, and assumes that its rekey request was the only one. Host A, however, is aware of the simultaneous rekey, and has decided that only req2 is to proceed. --> recv req1 Host B now knows about req1, but since it has already received a response, it ignores req1. There is no need to compare nonces. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I do not believe the algorithm below is consistent with what was sai= d in section 5.11.4 of RFC 4718. Section 5.11.4 of RFC 4718 said:

5.11.4.  Simultaneous IKE_SA Rekeying

  Probably the most complex case occurs when both peers try to re= key
  the IKE_SA at the same time.  Basically, the text in Secti= on 2.8
  applies to this case as well; however, it is important to ensur= e that
  the CHILD_SAs are inherited by the right IKE_SA.

  The case where both endpoints notice the simultaneous rekeying = works
  the same way as with CHILD_SAs.  After the CREATE_CHILD_SA= exchanges,
  three IKE_SAs exist between A and B; the one containing the low= est
  nonce inherits the CHILD_SAs.


"After the CREATE_CHILD_SA exchanges" implies the exchanges a= re expected to complete before the simultaneous rekey is resolved. The= algorithm below resolves the simultaneous rekey during the CREATE_CHIL= D_SA exchange and only allows one rekey to complete. My concern is tha= t the algorithm below will be incompatible with anybody that implemente= d to RFC 4718.

A slight tangent to this is that the possibility of a simultaneous rea= uthentication exists, however, RFC 4306, RFC 4718, and the current bis = draft does not address that scenario. Given that the a reauthenticatio= n is done by creating a new IKE_SA from scratch I'm not even sure if it= is possible to detect a simultaneous reauthentication of an IKE_SA, bu= t it would be nice if we could.


3D"InactiveYoav Nir <ynir@checkpoint.com>

=
          Yoav Nir <ynir@checkpoint.com>=
          Sent by: ipsec-bounces@ietf.org

          02/17/2009 05:03 AM

 =
3D=
To
3D""
"ipsec@ietf.org" <ipsec@ietf.org>
3D=
cc
3D""
3D=
Subject
3D""
[IPsec] Issue #22: simultaneous IKE SA rekeys
3D=3D""

 
Hi all.

Section 2.8.1 of the draft discusses what to do when Child SAs are reke= yed simultaneously by both peers. Issue #22 asks to clarify the same th= ing for simultaneous rekeying of IKE SAs.

We've written a proposed additional section, that should be labeled 2.8= .2. Since this specifies new behavior that was not specified before, we= want your comments before putting this into the draft.

Thanks

Yoav


2.8.2.  Simultaneous IKE SA rekeying

  If the two ends have the same key lifetime policies for IKE SAs= , it
  is possible that both will initiate a rekeying at the same time= .
  This is unacceptable for IKE SAs, because the IKE SAs own the c= hild
  SAs, and deleting the IKE SA leeds to deletion of all child SAs= .  To
  reduce the probability of this happening, the timing of rekeyin= g
  requests SHOULD be jittered (delayed by a random amount of time= after
  the need for rekeying is noticed).

  To avoid the case of two IKE SAs created by simultaneous
  CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the   initiator nonces is silently discarded, and the dependent child= SAs
  are transferred only to the IKE SA with the higher of the two   initiator nonces.  Here "higher" and "lower= " refer to octet-by-octet,
  lexicographical comparison of the nonces as large integers.
=
  The rules are as follows:
  1.  If a rekey request is received before this host has se= nt a rekey
      request of its own, this host MUST NOT send a rek= ey request.
      Instead, it MUST reply to the rekey request it ha= s received.
  2.  If a rekey request is received after this host has sen= t a rekey
      request, then this host MUST compare the two init= iator nonce
      values.  If the received nonce is higher tha= n its own, it MUST
      reply to the received request, and SHOULD stop re= transmissions of
      its own request.  If the received nonce is l= ower, it MUST ignore
      the received request.
  3.  If a rekey request is received after this host has sen= t a rekey
      request, and the peer has already replied, the ne= w received
      request MUST be ignored.

  Following these rules should prevent any case of multiple succe= ssful
  rekeys of an IKE SA.  The only case where the 2nd rule wou= ld be
  needed is if both requests were sent before either of them was<= br>   processed.  The implementation whose rekey request was ans= wered
  SHOULD delete the old IKE SA soon after.  The other implem= entation
  SHOULD wait at least one minute before deleting the IKE SA unle= ss its
  peer requests the deletion earlier.

  The following is an explanation of the impact this has on
  implementations.  Assume that hosts A and B have an existi= ng IKE SA,
  and both start rekeying it at the same time:

     Host A             &= nbsp;              Host B
     --------------------------------------------------= ---------------
     send req1: SK{SA, Ni1, [KEi]}
                    =              -->
                    =               <--  send req2= : SK{SA, Ni2, [KEi]}
     recv req2 <--

  At this point, host A knows there is a simultaneous rekeying go= ing
  on.  Assume that Ni2<Ni1.  A knows that req1 is th= e one to answer, so
  it ignores req2.

                    =               -->  recv req1=

  Now host B also knows that simultaneous rekeying is going on. &= nbsp;It has
  also figured out that req1 is the one to respond to, so it does= so.

                    =              <--  send resp1= : SK {SA, Nr,[KEr]}
     recv resp1 <--

  Now let's look at the other case, namely where Ni1<Ni2.

     Host A             &= nbsp;              Host B
     --------------------------------------------------= ---------------
     send req1: SK{SA, Ni1, [KEi]}
                    =              -->
                    =               <--  send req2= : SK{SA, Ni2, [KEi]}
     recv req2 <--

  Host A knows that req1 is the one to ignore, because req2 has a=
  higher nonce.  It replies to req2, and will not re-transmi= t req1.

     send resp2: SK {SA, Nr,[KEr]}
                    =               -->  recv req1=

  Now host B is in exactly the same position as host A was in the= first
  example.  It compares nonces, and ignores req1.

                    =               -->  recv resp= 2

  Host B now knows that the rekey is complete.

  To demonstrate the third rule, let's assume again that Ni1<N= i2, but
  that the sequence of messages is as follows:

     Host A             &= nbsp;              Host B
     --------------------------------------------------= ---------------
     send req1: SK{SA, Ni1, [KEi]}
                    =              -->
                    =               <--  send req2= : SK{SA, Ni2, [KEi]}
     recv req2 <--
                    =               -->  recv resp= 2

  Now host B knows nothing about req1, and assumes that its rekey=
  request was the only one.  Host A, however, is aware of th= e
  simultaneous rekey, and has decided that only req2 is to procee= d.

                    =               -->  recv req1=

  Host B now knows about req1, but since it has already received = a
  response, it ignores req1.  There is no need to compare no= nces.

Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2-- --0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFFF3DFC3CEB28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: image/gif; name="pic04356.gif" Content-Disposition: inline; filename="pic04356.gif" Content-ID: <2__=0ABBFFF3DFC3CEB28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFFF3DFC3CEB28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFFF3DFC3CEB28f9e8a93df938690918c0ABBFFF3DFC3CEB2-- From paul.hoffman@vpnc.org Tue Feb 17 07:13:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72B43A693F for ; Tue, 17 Feb 2009 07:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSIfy5wOHF09 for ; Tue, 17 Feb 2009 07:13:31 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8FC363A6833 for ; Tue, 17 Feb 2009 07:13:30 -0800 (PST) Received: from [10.20.30.158] (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 n1HFDcnr090660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 08:13:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18842.45421.943263.509696@fireball.kivinen.iki.fi> References: <18842.45421.943263.509696@fireball.kivinen.iki.fi> Date: Tue, 17 Feb 2009 07:13:39 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Payload order in IKEv2 (tracker issues #16 and #45) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:13:31 -0000 At 2:45 PM +0200 2/17/09, Tero Kivinen wrote: >Paul Hoffman writes: >> RFC 4306 says: >> Although new payload types may be added in the future and may appear >> interleaved with the fields defined in this specification, >> implementations MUST send the payloads defined in this specification >> in the order shown in the figures in section 2 and implementations >> SHOULD reject as invalid a message with those payloads in any other >> order. >> >> a) Downgrade the MUST to a SHOULD without other changes. > >I think that should be fine, but I think more important would be to >change "SHOULD reject" to "SHOULD NOT reject" or even "MUST NOT >reject". Sorry, yes, I forgot that. (a) is "downgrade the 'MUST send' to 'SHOULD send' and therefore change the 'SHOULD reject' to 'MUST NOT reject'". --Paul Hoffman, Director --VPN Consortium From DRAGAN@nortel.com Wed Feb 18 05:01:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF483A6AD0 for ; Wed, 18 Feb 2009 05:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euRZ0DKURCdw for ; Wed, 18 Feb 2009 05:01:21 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 999033A6843 for ; Wed, 18 Feb 2009 05:01:21 -0800 (PST) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1ID1Ua15054; Wed, 18 Feb 2009 13:01:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2009 08:01:09 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA418A86A88@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Potential way forward for IPsecME on ESP-NULL Thread-Index: AcmRD/AjAU3+5wxCSI6ueqdQ45ZAWQAuOpiw References: From: "Dragan Grebovich" To: "Paul Hoffman" , "IPsecme WG" Subject: Re: [IPsec] Potential way forward for IPsecME on ESP-NULL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:01:22 -0000 Sounds good to me. That's all I wanted from Day One. :-) =20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, February 17, 2009 9:56 AM To: IPsecme WG Subject: [IPsec] Potential way forward for IPsecME on ESP-NULL Wearing our one-size-fits-all shared co-chair hat, Yaron and I propose the following. - Both documents can continue forwards, adding the heuristics document as a WG item. Pasi has agreed that the current WG charter allows this. - The heuristics document would eventually be published as an Informational RFC. WESP would be the protocol produced by the WG. - The purpose of the heuristics document would be to help deep-inspection firewall vendors find ESP-NULL traffic that is not encapsulated with WESP. It is considered an educational document for firewall developers who might want to do heuristic checks on ESP traffic. Firewalls might want to do this until WESP is widely deployed, or even after wide deployment if sufficient firewall resources are available in order to check for ESP-NULL that is not yet wrapped in WESP. - Each document talks about the applicability of its own content, while referring to the other document. Are there any strong objections to this plan? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Feb 18 05:25:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D993A6C72 for ; Wed, 18 Feb 2009 05:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CcmeTrpRr2it for ; Wed, 18 Feb 2009 05:25:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6913A6945 for ; Wed, 18 Feb 2009 05:25:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1IDPbjS019723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 15:25:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1IDPblS028875; Wed, 18 Feb 2009 15:25:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18844.3153.630215.828408@fireball.kivinen.iki.fi> Date: Wed, 18 Feb 2009 15:25:37 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 19 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:25:30 -0000 Paul Hoffman writes: > At 12:48 PM -0800 1/25/09, Paul Hoffman wrote: > >Yes, definitely. At this point, we have heard from two groups of > authors; hearing from the wider implementers community would be > valuable. > > We still have not heard from many. > > During the interim meeting, a good question was raised: are we > making this decision based on implementation desires vs. protocol > cleanliness vs. deployment ability. We don't have enough input at > this point to pick between those. > > So, let me get this thread going again. If you have an opinion about > the core issue of how session resumption is done (extend the > IKE_SA_INIT or create a new exchange type), please state it again > and say what draws you to this conclusion. This is *not* a vote: it > is a request to get the discussion going with some hopefully better > metrics. I suggest keeping it as separate new exchange type. That should be cleaner from protocol point of view (keep separate options separate, do not create master jumbo super hyper exchange doing everything). That should also be easier to implement as it can be added as modular addition to the existing implementation, without breaking existing functionality. The resulting code should be simplier than modifying already complex code. One of the things that do require modification of the existing code is this exchange will change the very basic current practice of the IKEv2, where the packet is either completely unencryptede or it is completely encrypted. With this new exchange some payloads are in clear and some are encrypted. This most likely will cause changes to the packet parsing and encoding routines. This is not affected by the fact whether we use separate exchange or change IKE_SA_INIT. Note, that this text in the ticket is wrong: "More efficient protocol of the responder *does not* implement this extension". If the initiator has ticket then it KNOWS that responder do support this extension (as otherwise responder would not have sent him ticket). Using IKE_SA_INIT offers a bit more efficient protocol in case the ticket initiator is using has already expired, and initiator needs to fall back to full exchange. If any IKE_SA_INIT packet containing any encrypted payloads is sent to implementation which do not support this extensions, all those packets will be silently ignored. This does not offer initiator an option to try to use ticket with parties it does not know whether they support this extension or not. So for my point of view: Using separate exchange is simplier, easier and cleaner way to do it. Modifying IKE_SA_INIT optimizies very rare event when the ticket has already been expired by the responder when initiator tries to use, and saves one round trip times for those cases. The implementations will be more complex, and will most likely contain more errors. I do like the unix tools principle, i.e. make small tools (cat, grep, head, tail etc) that do the work they are designed to and then combine them for more complex things. Here I would like to have one more new clean tool (new IKE_SESSION_RESUME exchange) instead of tweaking existing tool (IKE_SA_INIT) to do yet another thing. -- kivinen@iki.fi From kivinen@iki.fi Wed Feb 18 06:11:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E2D3A6D2F for ; Wed, 18 Feb 2009 06:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 HUV9p9mMm18S for ; Wed, 18 Feb 2009 06:11:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E83773A6A34 for ; Wed, 18 Feb 2009 06:11:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1IEBvhF029599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 16:11:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1IEBur1024876; Wed, 18 Feb 2009 16:11:56 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18844.5932.182954.205038@fireball.kivinen.iki.fi> Date: Wed, 18 Feb 2009 16:11:56 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613328A03D5@il-ex01.ad.checkpoint.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> <9FB7C7CE79B84449B52622B506C7803613328A03D5@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 43 min X-Total-Time: 45 min Cc: "ipsec@ietf.org" Subject: [IPsec] Issue #22: simultaneous IKE SA rekeys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:11:52 -0000 Yoav Nir writes: > > Hi all. > > Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed simultaneously by both peers. Issue #22 asks to clarify the same thing for simultaneous rekeying of IKE SAs. > > We've written a proposed additional section, that should be labeled 2.8.2. Since this specifies new behavior that was not specified before, we want your comments before putting this into the draft. > > Thanks > > Yoav > > > 2.8.2. Simultaneous IKE SA rekeying > > If the two ends have the same key lifetime policies for IKE SAs, it > is possible that both will initiate a rekeying at the same time. > This is unacceptable for IKE SAs, because the IKE SAs own the child ^^^^^^^^^^^^ It is not unacceptable to initiate rekeying at the same time. It can and will happen. What is unacceptable is that we get two IKE SAs and parties do not agree on which one is the one that should be used, and to which one the Child SAs are moved to. > SAs, and deleting the IKE SA leeds to deletion of all child SAs. To > reduce the probability of this happening, the timing of rekeying > requests SHOULD be jittered (delayed by a random amount of time after > the need for rekeying is noticed). > > To avoid the case of two IKE SAs created by simultaneous > CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the Again we cannot avoid the case where they start CREATE_CHILD_SA exchange simultaneously. We can only give rules how to solve this. > initiator nonces is silently discarded, and the dependent child SAs > are transferred only to the IKE SA with the higher of the two > initiator nonces. Here "higher" and "lower" refer to octet-by-octet, > lexicographical comparison of the nonces as large integers. This is completely unacceptable. Firstly it is not following the rules already in the RFC4306 which cleary says that both IKE SAs are created as normally, and then the one follow the rule: "the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it." With IKE SAs this just requires that both ends need to agree that child SAs are always moved to the other IKE SA. We already do implement this rule specified in the RFC4306 for IKE SAs, we do not care about the simultaneous CHILD_SA/IPsec SA rekeys as they do not really cause problems (there will be duplicate CHILD_SAs/IPsec SAs but everything still works). Anyways we cannot "silently discard" any IKE SA packets, IKE SA basic principle is to provide request/reply exchages, thus there must be reply, as otherwise the other end will tear down the IKE SA. > The rules are as follows: > 1. If a rekey request is received before this host has sent a rekey > request of its own, this host MUST NOT send a rekey request. > Instead, it MUST reply to the rekey request it has received. > 2. If a rekey request is received after this host has sent a rekey > request, then this host MUST compare the two initiator nonce > values. If the received nonce is higher than its own, it MUST > reply to the received request, and SHOULD stop retransmissions of > its own request. If the received nonce is lower, it MUST ignore > the received request. > 3. If a rekey request is received after this host has sent a rekey > request, and the peer has already replied, the new received > request MUST be ignored. This will be major change to the existing RFC4306 behavior. Especially is it violates the basic IKEv2 exchange principles. I thing doing this is really bad idea. It requires quite big changes to all over the code (i.e. ability to get messages back from the retransmit and window processing queue), and so on. The current code we have already implemented, and which works (I only use the example where all request packets from responder are lost for duration of the initiators exchnage as that covers all possible cases): Host A Host B ------------ ---------------- # Start rekey # Start rekey HDR, SK{SA(SPIa1), Ni1, KEi1} ---> X <--- HDR, SK{SA(SPIb2), Ni2, KEi2} This is dropped # B receives A's requst # It knows there is simultaneous # rekey, but it will not yet # know A's reply nonce, so cannot # do anything. It ties both # rekeyed SAs together and to old IKE # SA, and replies normaly <--- HDR, SK{SA(SPIb1), Nr1, KEr1} # A receives B's reply, but it # still does not know there # is simultaneous rekey as # it has not seen B's # request yet. # It processes request # normally, creates new IKE SA1 # and moves Child SAs from old # IKE SA to this IKE SA1. # It starts timer that will # delete old IKE SA after a # while (60 seconds or so) # It will still tie # old IKE SA and new IKE SA1 # together. # B retransmits and A gets the request <--- HDR, SK{SA(SPIb2), Ni2, KEi2} # Now A notices there was # Simultaneous rekey # It will process the request # normally and create new IKE SA2 # and send reply back HDR, SK{SA(SPIa2), Nr2, KEr2} ---> # A knows there was # B already knows there was # simultaneous rekey # simultaneous rekey so it # so it starts to handle # finishes the IKE SA2 # the case. It has already # and starts to handle # tied the old IKE SA and # the case. It also has # IKE SA1 togther, and now # old IKE SA and both # it adds IKE SA2 there, and # new IKE SAs tied together # compares the Nonces (Ni1, # so it will do the same thing # Ni2, Nr1, Nr2) and finds # as A does, i.e. checks # the lowest one of them. # which one of new IKE SAs # If it was one if his # survived, and moves # then it starts timer # all child SAs from # to close that SA after # loosing IKE SA to the # timeout. In any case # surviving one. # it makes sure all # If it was the one # child SAs of that # creating the loosing one # losing IKE SA is moved # it will start # to the surviving IKE SA. # timer to delete it. # Lets say IKE SA1 lost, so # A will delete it after some # timeout (60 seconds or so # to make sure other end has # received all packets) HDR(IKE SA1), SK{D} ---> # B deletes IKE SA 1, which # is already empty, and # sends reply <--- HDR(IKE SA1), SK{} # Either end can delete the old IKE SA (normally it is done # by the host who started rekey, but as both here started # it either end can delete it). Lets assume here that # A's timer expires first (most likely as it started it before it # even knew B has started rekey), so A will send delete for that SA # too. HDR(old IKE SA), SK{D} ---> # B deletes old IKE SA, which # is already empty, and # sends reply <--- HDR(old IKE SA), SK{} This is what we have in our implementation and this is also what is described in the RFC4306. As RFC4306 only says this very briefly and bit vague terms (i.e. just refers to SA, not separting Child SAs and IKE SAs), this requires more text to the bis document, but I do not think we want to completely change the behavior of the protocol in this exeptional case. Especially we do not want to break IKEv2 rules where (from section 1 Introduction): - All IKE communications consist of pairs of messages: a request and a response. - IKE message flow always consists of a request followed by a response. It is the responsibility of the requester to ensure reliability. If the response is not received within a timeout interval, the requester needs to retransmit the request (or abandon the connection) For example I do not have any idea what happens to the message IDs of the old IKE SA in your case, i.e. if request is pulled back, is the message ID still incremented, and if request is silently ignored is that message id still marked as used in the window etc. What if we sent first IKE SA rekey and then another message (i.e using window size > 1), now if we pupp back that IKE SA rekey request, do we reuse the empty slot we have in window. If we do not have any other exchange we want to send do we fill it with some junk exchange. Also for example mobike do assume that message IDs are used in order, i.e. message ID n must be sent AFTER message ID n-1, i.e. address update in message ID n-1 can be safely ignored when address update in message ID n is seen, as message ID n is newer than message ID n-1, thus refers to the latest situation. -- kivinen@iki.fi From ken.grewal@intel.com Wed Feb 18 08:06:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84CD3A693C for ; Wed, 18 Feb 2009 08:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEyjpKEJrGU3 for ; Wed, 18 Feb 2009 08:06:21 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id E5E4C3A67B2 for ; Wed, 18 Feb 2009 08:06:20 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 18 Feb 2009 08:06:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,229,1233561600"; d="scan'208";a="111893431" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 18 Feb 2009 08:06:32 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 18 Feb 2009 09:06:22 -0700 From: "Grewal, Ken" To: Paul Hoffman , IPsecme WG Date: Wed, 18 Feb 2009 09:05:48 -0700 Thread-Topic: [IPsec] Potential way forward for IPsecME on ESP-NULL Thread-Index: AcmRD+Yqsrd2BiDoS569FC7aPEWUGwA0idNg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Potential way forward for IPsecME on ESP-NULL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:06:21 -0000 Hi Paul,=20 I have no objections to this approach moving forward.=20 Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Paul Hoffman >Sent: Tuesday, February 17, 2009 6:56 AM >To: IPsecme WG >Subject: [IPsec] Potential way forward for IPsecME on ESP-NULL > >Wearing our one-size-fits-all shared co-chair hat, Yaron and I propose the >following. > >- Both documents can continue forwards, adding the heuristics document as = a >WG item. Pasi has agreed that the current WG charter allows this. > >- The heuristics document would eventually be published as an Informationa= l >RFC. WESP would be the protocol produced by the WG. > >- The purpose of the heuristics document would be to help deep-inspection >firewall vendors find ESP-NULL traffic that is not encapsulated with WESP. >It is considered an educational document for firewall developers who might >want to do heuristic checks on ESP traffic. Firewalls might want to do thi= s >until WESP is widely deployed, or even after wide deployment if sufficient >firewall resources are available in order to check for ESP-NULL that is no= t >yet wrapped in WESP. > >- Each document talks about the applicability of its own content, while >referring to the other document. > >Are there any strong objections to this plan? > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From danmcd@sun.com Wed Feb 18 08:56:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FAD3A63D2 for ; Wed, 18 Feb 2009 08:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut5wGCWBwZV6 for ; Wed, 18 Feb 2009 08:56:36 -0800 (PST) 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 ED2933A6894 for ; Wed, 18 Feb 2009 08:56:33 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1IGukiC027935 for ; Wed, 18 Feb 2009 16:56:46 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 n1IGujaJ041796 for ; Wed, 18 Feb 2009 11:56:45 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1IGmwX1011156 for ; Wed, 18 Feb 2009 11:48:58 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1IGmwx7011155 for ipsec@ietf.org; Wed, 18 Feb 2009 11:48:58 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 18 Feb 2009 11:48:58 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090218164858.GB10961@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:56:36 -0000 Some quick/dirty WESP questions. 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we are using WESP as an incentive to move people to IKEv2? 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the answer is NO, but I didn't see any such language in the November 2008 draft. Thanks, Dan From yaronf@checkpoint.com Wed Feb 18 12:05:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AA228C186 for ; Wed, 18 Feb 2009 12:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nSTWf9zhsiy for ; Wed, 18 Feb 2009 12:05:18 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2D91428C161 for ; Wed, 18 Feb 2009 12:05:18 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 010052AC003; Wed, 18 Feb 2009 22:05:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 822C12AC002; Wed, 18 Feb 2009 22:05:28 +0200 (IST) X-CheckPoint: {499C6969-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1IK5RsZ020971; Wed, 18 Feb 2009 22:05:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 18 Feb 2009 22:05:27 +0200 From: Yaron Sheffer To: Dan McDonald , "ipsec@ietf.org" Date: Wed, 18 Feb 2009 22:05:26 +0200 Thread-Topic: [IPsec] WESP questions Thread-Index: AcmR6gmc3+PEK9etTxCh5gz0AupsWgAGEXoA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> References: <20090218164858.GB10961@kebe.East.Sun.COM> In-Reply-To: <20090218164858.GB10961@kebe.East.Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:05:19 -0000 Note: personal opinions below. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Dan McDonald > Sent: Wednesday, February 18, 2009 18:49 > To: ipsec@ietf.org > Subject: [IPsec] WESP questions >=20 > Some quick/dirty WESP questions. >=20 > 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we ar= e > using WESP as an incentive to move people to IKEv2? >=20 I don't believe in this kind of incentives. IKEv2 has to win its market sha= re based on its own merits. That said, the WG should definitely focus on IK= Ev2. So we should now consider WESP in the context of IKEv2 only, and if ne= eded (maybe not), publish a short IKEv1 document later. > 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the > answer is NO, but I didn't see any such language in the November 2008 > draft. >=20 I previously commented on the current draft that WESP had better support bo= th null and non-null encryption. Much of the value in WESP is the extensibi= lity it adds to ESP. [Co-chair hat on:] The authors of this draft are kindly requested to start = using our issue tracking application to track issues. > Thanks, > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From danmcd@sun.com Wed Feb 18 12:25:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0353A6AC9 for ; Wed, 18 Feb 2009 12:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4hCOECx2VFE for ; Wed, 18 Feb 2009 12:25:03 -0800 (PST) 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 3BA1C3A68A9 for ; Wed, 18 Feb 2009 12:25:03 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1IKPFev023080 for ; Wed, 18 Feb 2009 20:25:15 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n1IKPFid037340 for ; Wed, 18 Feb 2009 15:25:15 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1IKHSTQ011348 for ; Wed, 18 Feb 2009 15:17:28 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1IKHStb011347 for ipsec@ietf.org; Wed, 18 Feb 2009 15:17:28 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 18 Feb 2009 15:17:28 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090218201728.GN10961@kebe.East.Sun.COM> References: <20090218164858.GB10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:25:06 -0000 On Wed, Feb 18, 2009 at 10:05:26PM +0200, Yaron Sheffer wrote: > Note: personal opinions below. Understood... > > Some quick/dirty WESP questions. > > > > 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we are > > using WESP as an incentive to move people to IKEv2? > > I don't believe in this kind of incentives. IKEv2 has to win its market > share based on its own merits. That said, the WG should definitely focus on > IKEv2. So we should now consider WESP in the context of IKEv2 only, and if > needed (maybe not), publish a short IKEv1 document later. Okay. > > 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the > > answer is NO, but I didn't see any such language in the November 2008 > > draft. > > I previously commented on the current draft that WESP had better support > both null and non-null encryption. Much of the value in WESP is the > extensibility it adds to ESP. I missed that thread -- sorry. To be honest, it's not a BIG deal either way, but I do think it should be clarified in the document to prevent confusion. I'm thinking about the implementation issues as I ask. In particular, when this gets build I want to update the ipsec(7p) and ipsecesp(7p) man pages to document how insecure your packets become using WESP with encryption. > [Co-chair hat on:] The authors of this draft are kindly requested to start > using our issue tracking application to track issues. Don't look at me! :) Dan From ken.grewal@intel.com Wed Feb 18 12:47:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA663A69A8 for ; Wed, 18 Feb 2009 12:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 7PRp-CQdT1-Y for ; Wed, 18 Feb 2009 12:47:43 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 84F783A6AFF for ; Wed, 18 Feb 2009 12:47:43 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 18 Feb 2009 12:41:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,230,1233561600"; d="scan'208";a="432066884" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga002.fm.intel.com with ESMTP; 18 Feb 2009 12:43:55 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Wed, 18 Feb 2009 13:47:56 -0700 From: "Grewal, Ken" To: Dan McDonald , "ipsec@ietf.org" Date: Wed, 18 Feb 2009 13:47:23 -0700 Thread-Topic: [IPsec] WESP questions Thread-Index: AcmSBw4/2UVrdANqQHqfUh9QuCe8vgAAjoWA Message-ID: References: <20090218164858.GB10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> <20090218201728.GN10961@kebe.East.Sun.COM> In-Reply-To: <20090218201728.GN10961@kebe.East.Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:47:44 -0000 Agree with Yaron.=20 IKEv2 will be the target for negotiating WESP. Unless there is a demand for= IKEv1 support also, it probably doesn't make sense to retro-fit this in IK= Ev1, even though it will be a minor change.=20 We did have a small discussion around supporting null and non-null (a.k.a. = integrity bit in the original WESP draft) and can continue this discussion = on the mailing list. =20 I will start logging these items using the issue tracking system. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Dan McDonald >Sent: Wednesday, February 18, 2009 12:17 PM >To: ipsec@ietf.org >Subject: Re: [IPsec] WESP questions > >On Wed, Feb 18, 2009 at 10:05:26PM +0200, Yaron Sheffer wrote: >> Note: personal opinions below. > >Understood... > >> > Some quick/dirty WESP questions. >> > >> > 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we >are >> > using WESP as an incentive to move people to IKEv2? >> >> I don't believe in this kind of incentives. IKEv2 has to win its market >> share based on its own merits. That said, the WG should definitely focus >on >> IKEv2. So we should now consider WESP in the context of IKEv2 only, and >if >> needed (maybe not), publish a short IKEv1 document later. > >Okay. > >> > 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping >the >> > answer is NO, but I didn't see any such language in the November >2008 >> > draft. >> >> I previously commented on the current draft that WESP had better support >> both null and non-null encryption. Much of the value in WESP is the >> extensibility it adds to ESP. > >I missed that thread -- sorry. > >To be honest, it's not a BIG deal either way, but I do think it should be >clarified in the document to prevent confusion. I'm thinking about the >implementation issues as I ask. In particular, when this gets build I wan= t >to update the ipsec(7p) and ipsecesp(7p) man pages to document how insecur= e >your packets become using WESP with encryption. > >> [Co-chair hat on:] The authors of this draft are kindly requested to >start >> using our issue tracking application to track issues. > >Don't look at me! :) > >Dan >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Wed Feb 18 13:00:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190A73A6AB4 for ; Wed, 18 Feb 2009 13:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id valLEKIYc85W for ; Wed, 18 Feb 2009 13:00:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 294FD3A68D8 for ; Wed, 18 Feb 2009 13:00:10 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D27202AC002; Wed, 18 Feb 2009 23:00:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D844A2AC001; Wed, 18 Feb 2009 23:00:20 +0200 (IST) X-CheckPoint: {499C7645-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1IL0KsZ003638; Wed, 18 Feb 2009 23:00:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 18 Feb 2009 23:00:20 +0200 From: Yaron Sheffer To: Dan McDonald , "ipsec@ietf.org" Date: Wed, 18 Feb 2009 23:00:26 +0200 Thread-Topic: [IPsec] WESP questions Thread-Index: AcmSBwo1n7+20wcgSDKTX5zv2rAsWQABGGBA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE87@il-ex01.ad.checkpoint.com> References: <20090218164858.GB10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> <20090218201728.GN10961@kebe.East.Sun.COM> In-Reply-To: <20090218201728.GN10961@kebe.East.Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:00:11 -0000 [snip] >=20 > > > 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping > the > > > answer is NO, but I didn't see any such language in the November > 2008 > > > draft. > > > > I previously commented on the current draft that WESP had better suppor= t > > both null and non-null encryption. Much of the value in WESP is the > > extensibility it adds to ESP. >=20 > I missed that thread -- sorry. >=20 > To be honest, it's not a BIG deal either way, but I do think it should be > clarified in the document to prevent confusion. I'm thinking about the > implementation issues as I ask. In particular, when this gets build I > want > to update the ipsec(7p) and ipsecesp(7p) man pages to document how > insecure > your packets become using WESP with encryption. >=20 Insecure why? There MUST be no security degradation when we're done with th= is draft. Email secured by Check Point From kivinen@iki.fi Thu Feb 19 05:08:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261D03A67E3 for ; Thu, 19 Feb 2009 05:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 bmpK1mmv-KHE for ; Thu, 19 Feb 2009 05:08:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1492A3A6AFA for ; Thu, 19 Feb 2009 05:08:23 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1JD8XQr022107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 15:08:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1JD8Wp2005139; Thu, 19 Feb 2009 15:08:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18845.22992.632225.728842@fireball.kivinen.iki.fi> Date: Thu, 19 Feb 2009 15:08:32 +0200 From: Tero Kivinen To: Dan McDonald In-Reply-To: <20090218164858.GB10961@kebe.East.Sun.COM> References: <20090218164858.GB10961@kebe.East.Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 13:08:25 -0000 Dan McDonald writes: > Some quick/dirty WESP questions. > > 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we are > using WESP as an incentive to move people to IKEv2? I do not see any point of standardizing anything to already obsoleted protocol, so I would say IKEv2 only. I also personally do not see any way I would be ever implementing WESP negotiation to our IKEv1 library... Also the current draft refers to RFC4303 (ESP) and RFC 4302 (AH) which are for RFC4301 and IKEv2. Also knowing how long it will take before this will be used widely, I do not think limiting it to IKEv2 only is going to cause problems. > 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the > answer is NO, but I didn't see any such language in the November 2008 > draft. As the draft includes second unencrypted copy of the next header field, I myself assumed it is not limited to ESP-NULL. If it is limited to ESP NULL, then it would be better to only use one next header field. It also says the next header field in the WESP header might be zero for "security concerns"... -- kivinen@iki.fi From danmcd@sun.com Thu Feb 19 06:43:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D698428C1F5 for ; Thu, 19 Feb 2009 06:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0u+5uy-ZC1F for ; Thu, 19 Feb 2009 06:43:51 -0800 (PST) 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 C88E428C1D6 for ; Thu, 19 Feb 2009 06:43:51 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1JEi4MT007915 for ; Thu, 19 Feb 2009 14:44:05 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n1JEi4IX003013 for ; Thu, 19 Feb 2009 09:44:04 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1JET46h001813; Thu, 19 Feb 2009 09:29:04 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1JET3rH001812; Thu, 19 Feb 2009 09:29:03 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Thu, 19 Feb 2009 09:29:03 -0500 From: Dan McDonald To: Yaron Sheffer Message-ID: <20090219142903.GF1485@sun.com> References: <20090218164858.GB10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> <20090218201728.GN10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE87@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE87@il-ex01.ad.checkpoint.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 14:43:53 -0000 On Wed, Feb 18, 2009 at 11:00:26PM +0200, Yaron Sheffer wrote: > > to update the ipsec(7p) and ipsecesp(7p) man pages to document how > > insecure > > your packets become using WESP with encryption. > > > Insecure why? There MUST be no security degradation when we're done with this draft. My bad. I didn't see this text during my first read-through: Note: For security concerns, this value may optionally be set to zero, in which case the next header an be extracted from the ESP trailer. So for encrypted packets, I would recommend this value MUST be zero. Pardon my panic, Dan From yaronf@checkpoint.com Thu Feb 19 07:52:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174833A6915 for ; Thu, 19 Feb 2009 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 dgDeCUGvJi+f for ; Thu, 19 Feb 2009 07:52:49 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E2F2F3A68A6 for ; Thu, 19 Feb 2009 07:52:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 294352AC002; Thu, 19 Feb 2009 17:53:01 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 168762AC001; Thu, 19 Feb 2009 17:53:00 +0200 (IST) X-CheckPoint: {499D7FB5-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1JFqxsZ009617; Thu, 19 Feb 2009 17:52:59 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 19 Feb 2009 17:52:59 +0200 From: Yaron Sheffer To: Dan McDonald Date: Thu, 19 Feb 2009 17:52:56 +0200 Thread-Topic: [IPsec] WESP questions Thread-Index: AcmSn34JYI3EhU+oSqejxgDuYMlW6gACVFvg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECF97@il-ex01.ad.checkpoint.com> References: <20090218164858.GB10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE77@il-ex01.ad.checkpoint.com> <20090218201728.GN10961@kebe.East.Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECE87@il-ex01.ad.checkpoint.com> <20090219142903.GF1485@sun.com> In-Reply-To: <20090219142903.GF1485@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:52:50 -0000 This is worthy of a TRAC issue. Yaron > -----Original Message----- > From: Dan McDonald [mailto:danmcd@sun.com] > Sent: Thursday, February 19, 2009 16:29 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] WESP questions >=20 > On Wed, Feb 18, 2009 at 11:00:26PM +0200, Yaron Sheffer wrote: > > > to update the ipsec(7p) and ipsecesp(7p) man pages to document how > > > insecure > > > your packets become using WESP with encryption. > > > > > Insecure why? There MUST be no security degradation when we're done wit= h > this draft. >=20 > My bad. I didn't see this text during my first read-through: >=20 > Note: For security concerns, this value may optionally be set to > zero, in which case the next header an be extracted from the ESP > trailer. >=20 > So for encrypted packets, I would recommend this value MUST be zero. >=20 > Pardon my panic, > Dan >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From julien.laganier.ietf@googlemail.com Tue Feb 24 06:53:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D073A6A7C for ; Tue, 24 Feb 2009 06:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY+MaHxNzlZ8 for ; Tue, 24 Feb 2009 06:53:42 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 8FE763A6990 for ; Tue, 24 Feb 2009 06:53:41 -0800 (PST) Received: by ewy8 with SMTP id 8so261583ewy.13 for ; Tue, 24 Feb 2009 06:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QkpPGxipUWKpYMA94isP/xAf7jk49dTC1XyoUwqS/8I=; b=QmO5pI5jcfhFrPlt7bZliXcDzmfYMQpq7+gFCpO4hciDejOBmjRR7EzIhfekPgp+5G I297J3jTzt2UmpJ/uJfHiqxBlanL51PSrHve84rR9IIMqC7iOG98ZkoD0zkUtEp/FWxt +EkLixtkVCcfvfUoBsOAh41mr+U8v6n6r/6x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NZaRl3CsSeiyyPZcvl367dLgUUZCQqBl291snjmskxrUKgvjw1vP8dxshs4Ody7pYY YJyyK6B1F98iTTv/aGMiWHOb2jZKWn0Z3FWCSEWypA5c7+xnYq/vgaTS2HcD54bT7OiZ WW29nO803/gGESAh5kU+12sjlRgtteL4Ic+zU= MIME-Version: 1.0 Received: by 10.210.90.20 with SMTP id n20mr4435499ebb.162.1235487239175; Tue, 24 Feb 2009 06:53:59 -0800 (PST) Date: Tue, 24 Feb 2009 15:53:59 +0100 Message-ID: <7ad6d6db0902240653i79518d5bi66dec395f0391da2@mail.gmail.com> From: Julien Laganier To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cmadson@cisco.com, Pasi Eronen Subject: [IPsec] 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: , X-List-Received-Date: Tue, 24 Feb 2009 14:53:43 -0000 Folks, The ipsecme WG is chartered to deliver a standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. There's a WG draft trying to fullfil that available at: When we presented this draft during the Minneapolis meeting last November some people said they felt there was a gap in IPv6 support for IPsec in general, which wasn't limited to IKEv2 for IRAC and that the current draft wasn't filling that gap. It is true that the current draft as per our charter is focused on extending IKEv2 for IPv6 support in IRAC scenarios. The following solution requirements were identified so far (excerpt from the draft): o A VPN client can obtain several addresses from a given prefix; the interface IDs can be selected by the client, and may depend on the prefix. o A VPN client can be assigned multiple prefixes for use on the client-gateway link. The client does not have to know beforehand how many prefixes are needed. o The solution should avoid periodic messages over the VPN tunnel. o The solution should avoid Duplicate Address Detection (DAD) over the VPN tunnel. o Multicast works. That is, the client is able to send multicast packets (tunneled to the gateway via unicast), join multicast groups using [MLDv2], and receive multicast packets (tunneled from the gateway to the client via unicast). o It should be possible to share the VPN access over a local area network connection, without requiring anything special from other hosts in the local network (beyond minimal IPv6 node requirements specified in [RFC4294]). o Re-authentication works: the client can start a new IKE SA and continue using the same "virtual link" (with same addresses, etc.). o Compatibility with other IPsec uses: Configuring a virtual IPv6 link should not prevent the peers from using IPsec/IKEv2 for other uses. o Compatibility with current IPv6 configuration: Although the current IPv6 mechanism is not widely implemented, new solutions should not preclude its use (e.g., by defining incompatible semantics for the existing payloads). o Compatibility with current IPv4 configuration: it should be possible to use the existing IPv4 configuration mechanism within the same IKE SA. o (Optional/To be determined) When the client is also a router (to some local network), it should be able to use DHCPv6 prefix delegation [RFC3633] over the virtual link. Since it seems some people think some IPsec generic requirements shall be added to the list above to complete the IPv6 support, if they could reply to that note to propose some, hopefully the WG could get some insights on what they think is missing... On my side the only thing I could come up with so far is how to deal with link-local IPv6 addresses used as traffc selector for IPsec transport mode. In that respect one might view RFC 4301 as underspecified since a link-local address scope is limited to a link (thus is likely to correspond to an interface on a host but could correspond to more than one interface in some situations) but there is no notion of link or interface in the definition of a traffic selector as per RFC 4301. Quoting RFC 4301 " There is no requirement to maintain SPDs on a per-interface basis, as was specified in RFC 2401". We'd appreciate the view of the WG participants on the matter of IPv6 support for IPsec. Best, --julien From fanzhao828@gmail.com Tue Feb 24 10:19:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92DB28C11A for ; Tue, 24 Feb 2009 10:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHHpiBuq3ryk for ; Tue, 24 Feb 2009 10:19:37 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id AE2CA28C10A for ; Tue, 24 Feb 2009 10:19:37 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1549795qwe.31 for ; Tue, 24 Feb 2009 10:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=jtNjjgnN69tLgUafvYkcw6IPLX1q1I4/+Ipskyh4orE=; b=U3Yx2AjuDBW3ypNe/jPdM0biqbFRcgiEz62aJt3hj5VwPRF2EuQfhqPnaPBYifv2R7 gwoGNBpfcHX/3UbbVDsjyBm9o5JwHeWvktB1OF21mq+Yn3k2bE7VRiDYnBGjgC4CltX0 8aS8DxD4HfwGmBlmLlQj+ghsQ0bgykieNBqq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XICF7scsg50GGxRuK7hRId6kB3DlDQmDFnIWgFKirSZk197meF3Py9vLS8kD54QSDk /wz+8L25sQJZkXR25oLpbJ38iO1tJdmtBOiC2g2YSeJWtNsiQ9uONI/+D45EaYbXan+9 GGaR02IeNtGwv6OXWVOv9OoiTbf+6EU1Je2ic= MIME-Version: 1.0 Received: by 10.224.73.140 with SMTP id q12mr11020qaj.306.1235499597071; Tue, 24 Feb 2009 10:19:57 -0800 (PST) Date: Tue, 24 Feb 2009 10:19:57 -0800 Message-ID: From: fan zhao To: "ipsec@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [IPsec] questions on redirection during IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:19:38 -0000 Hi, The current draft uses a separate informational message after the IKE_AUTH to redirect the client. However, while receiving the NO_ADDITIONAL_SAS in the last IKE_AUTH (before the N(Redirect) is received), the IPsec client may try to connect with another IPsec gateway (it can select one from a list of gateways, for example, returned by the DNS response). Especially when during HO, the client wants to perserve its IP address/mobility states, it needs to do so since it knows that the connection with the current IPsec gateway is unsuccessful. Such the selected IPsec gateway may be different from the one that will be indicated in the N(REDIRECT). Therefore, when the client processes the N(Redirect), it may realize that it needs to abort the communication with another IPsec gateway, which results in overhead. Furthermore, the current draft specifies that when the client receives N(redirect), it MUST send an empty message as an acknowledgement. Considering the different order of N(Redirect), the delete request from the client and the empty message (as a response to n(Redirect)), there are different flows. For example, N(redirect) could be lost, and the delete request from the client could be sent before the client receives the N(redirect), etc. However, the current draft does not specify how to handle such cases. >From the perspective of the client, there are three situations: N(redirect) is lost, N(redirect) is received before sending the Delete request, N(redirect) is received after sending the Delete request. >From the perspective of the gateway, there are also three situations: the e= mpty message is lost, the empty message is received before receiving the delete request from the client, and the empty message is received after receiving the delete request. One special case is that N(redirect) is lost and the client sends a delete request. And in this case, the gateway cannot piggyback the N(redirect) together wit= h the delete payload. Because otherwise, the client cannot send back the empt= y message to the gateway. It seems to me to handle all these cases, the safest/simplest way is that the gateway always waits for the empty message to be received before it sends the response to the delete request from the client. However, one of reasons of doing redirection is gateway overloading. With this method, the gateway cannot release unuseful IKE SA as soon as possible, which prevents the gateway releasing resources and serving more clients. Otherwise, the draft needs to specify in detail how to handle these cases. Given the above reasons, I suggest that N(redirect) is carried in the last IKE_AUTH message. IMO, it seems to me it is ok to use the N(redirect) with the status type during the IKE_AUTH as RFC 4306 3.10.1 specifies that =93Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized.=94 What do you think? Thanks. Sincerely, fan From A.Hoenes@tr-sys.de Wed Feb 25 03:10:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324833A6B73 for ; Wed, 25 Feb 2009 03:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.937 X-Spam-Level: * X-Spam-Status: No, score=1.937 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cthoJf1p52vT for ; Wed, 25 Feb 2009 03:10:39 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 833FC3A6A63 for ; Wed, 25 Feb 2009 03:10:38 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA187310145; Wed, 25 Feb 2009 12:09:06 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA08550; Wed, 25 Feb 2009 12:09:05 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902251109.MAA08550@TR-Sys.de> To: ipsec@ietf.org Date: Wed, 25 Feb 2009 12:09:04 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [IPsec] enhanced WG pages at tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:10:40 -0000 Folks, Henrik Levkowetz has implemented extended mapping of Internet Drafts (by name) to WG in the IETF Tools WG pages. Now, not only I-Ds containing "-ipsecme-" in their name are linked into the "Related Active Documents" section of the IPSECME pages at http://tools.IETF.ORG/wg/ipsecme/ and http://tools.IETF.ORG/wg/ipsecme/index.pyht?sort={....} but also all I-Ds containing "-ipsec-" or "-ike-". This should help interested parties to locate work in progress related to IPsec, whether perhaps aiming directly at IPSECME or being dealt with primarily in other WGs -- to the extent draft authors follow rational 'markup' style in forming draft names. Similar additions appear in other WG pages of WGs with acronyms differing from popular protocol acronyms they are dealing with. For instance, "-dhcp-" now maps to the DHC WG, and "-tcp-" maps to the TCPM WG. WG chairs can request additional mappings if deemed useful, by contacting the webmaster at tools.ietf.org . Thanks Henrik for nearly instantaneously implementing this proposal! Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From yaronf@checkpoint.com Wed Feb 25 04:33:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA083A699C for ; Wed, 25 Feb 2009 04:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYlj4qQ7Rrrb for ; Wed, 25 Feb 2009 04:33:48 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 09F423A6768 for ; Wed, 25 Feb 2009 04:33:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 783592AC002; Wed, 25 Feb 2009 14:34:07 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 725052AC001 for ; Wed, 25 Feb 2009 14:34:06 +0200 (IST) X-CheckPoint: {49A539E3-10004-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1PCY5sZ025628 for ; Wed, 25 Feb 2009 14:34:06 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 25 Feb 2009 14:34:05 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 25 Feb 2009 14:34:05 +0200 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgHJgybw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED498@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:33:49 -0000 This is a reminder that we are having a last call for the Redirect document= . Even if you support advancing this document, but have no other comments, = please state your opinion on the list. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Monday, February 16, 2009 11:46 > To: IPsecme WG > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >=20 > This is a 2 week working group last call for draft-ietf-ipsecme-ikev2- > redirect-04. The target status for this document is Proposed Standard. >=20 > Please send your comments to the ipsec list by March 2, 2009, as follow- > ups to this message. >=20 > Please clearly indicate the position of any issue in the Internet Draft, > and if possible provide alternative text. Please also indicate the nature > or severity of the error or correction, e.g. major technical, minor > technical, nit, so that we can quickly judge the extent of problems with > the document. >=20 > The document can be accessed here: http://tools.ietf.org/html/draft-ietf- > ipsecme-ikev2-redirect-04. >=20 > Please note that one issue is currently open against this draft: > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. >=20 > Thanks, > Yaron >=20 > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From ynir@checkpoint.com Wed Feb 25 05:02:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B2E3A688A for ; Wed, 25 Feb 2009 05:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fv+UpYc5QYG for ; Wed, 25 Feb 2009 05:02:21 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3811B3A67D6 for ; Wed, 25 Feb 2009 05:02:21 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B50EB2AC004; Wed, 25 Feb 2009 15:02:40 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B2F172AC002 for ; Wed, 25 Feb 2009 15:02:38 +0200 (IST) X-CheckPoint: {49A54093-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1PD2bsZ006506 for ; Wed, 25 Feb 2009 15:02:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 25 Feb 2009 15:02:37 +0200 From: Yoav Nir To: IPsecme WG Date: Wed, 25 Feb 2009 15:02:46 +0200 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgHJgybwAAHF2zA= Message-ID: <9FB7C7CE79B84449B52622B506C7803613328A0BE6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED498@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED498@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:02:22 -0000 I support advancing this. I preferred allowing the redirect in IKE_AUTH as well, but it seems like th= e group consensus went against that. One textual comment: since we have section 7 describing a symmetric case (r= edirect by either peer), section 6.1 should be chagned to reflect that the = REDIRECT_SUPPORTED may be in either or both of the request and reply of the= Initial exchange, and perhaps a picture can be added to section 7. Even without this, the text is clear and useful. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Yaron Sheffer > Sent: Wednesday, February 25, 2009 2:34 PM > To: IPsecme WG > Subject: Re: [IPsec] WG Last Call:=20 > draft-ietf-ipsecme-ikev2-redirect-04 >=20 > This is a reminder that we are having a last call for the=20 > Redirect document. Even if you support advancing this=20 > document, but have no other comments, please state your=20 > opinion on the list. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org] On Behalf=20 > > Of Yaron Sheffer > > Sent: Monday, February 16, 2009 11:46 > > To: IPsecme WG > > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > >=20 > > This is a 2 week working group last call for=20 > draft-ietf-ipsecme-ikev2-=20 > > redirect-04. The target status for this document is=20 > Proposed Standard. > >=20 > > Please send your comments to the ipsec list by March 2, 2009, as=20 > > follow- ups to this message. > >=20 > > Please clearly indicate the position of any issue in the Internet=20 > > Draft, and if possible provide alternative text. Please=20 > also indicate=20 > > the nature or severity of the error or correction, e.g. major=20 > > technical, minor technical, nit, so that we can quickly judge the=20 > > extent of problems with the document. > >=20 > > The document can be accessed here:=20 > > http://tools.ietf.org/html/draft-ietf- > > ipsecme-ikev2-redirect-04. > >=20 > > Please note that one issue is currently open against this draft: > > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. > >=20 > > Thanks, > > Yaron > >=20 > > Email secured by Check Point > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > >=20 > > Scanned by Check Point Total Security Gateway. > >=20 > > Scanned by Check Point Total Security Gateway. >=20 > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. > = Email secured by Check Point From kivinen@iki.fi Wed Feb 25 05:03:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5F328C13A for ; Wed, 25 Feb 2009 05:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 sXAcWUK8LlJV for ; Wed, 25 Feb 2009 05:03:48 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1648B3A688A for ; Wed, 25 Feb 2009 05:03:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1PD43Nd028738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 15:04:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1PD43Rs003873; Wed, 25 Feb 2009 15:04:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18853.16835.355300.918724@fireball.kivinen.iki.fi> Date: Wed, 25 Feb 2009 15:04:03 +0200 From: Tero Kivinen To: fan zhao In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 27 min X-Total-Time: 27 min Cc: "ipsec@ietf.org" Subject: [IPsec] questions on redirection during IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:03:49 -0000 fan zhao writes: > However, while receiving the NO_ADDITIONAL_SAS in the last IKE_AUTH > (before the N(Redirect) > is received), the IPsec client may try to connect with another IPsec > gateway (it can select one from > a list of gateways, for example, returned by the DNS response). > Especially when during HO, > the client wants to perserve its IP address/mobility states, it needs > to do so since it knows > that the connection with the current IPsec gateway is unsuccessful. > > Such the selected IPsec gateway may be different from the one that > will be indicated in the N(REDIRECT). > Therefore, when the client processes the N(Redirect), it may realize > that it needs to abort > the communication with another IPsec gateway, which results in overhead. Client should wait for the few milliseconds it takes to get the next packet immediately following the IKE_AUTH reply before trying to connect new gateways. If client wants to waste resources by doing guesses where it will be redirected then that is its problem. So I do not consider that protocol issue but issue with bad implementations wanting to waste resources. We cannot really solve all bad implementation issues, vendors can always make bad implementations which waste even more resources. For example the client can start connecting to all gateways in the beginning even before receiving any REDIRECT notification. We do not have anything in the draft forbidding (or allowing) that either, and I do not think we need to cover all possible ways people can make bad implementations. > Furthermore, the current draft specifies that when the client receives > N(redirect), it MUST send an empty > message as an acknowledgement. That requirement does not come from the redirect document, it comes from the base IKEv2 specification, which mandates that each request MUST receive reply. The redirect document cannot really change the IKEv2 base document requirements, thus all implementations implementing IKEv2 will already require that same thing. > However, the current draft does not specify how to handle such > cases. The draft does not need to specify such things, as those are not redirect specific cases, they are generic IKEv2 questions. Base IKEv2 RFC already covers what do when packets are lost, and how redirects are handled in that case. The current IKEv2 RFC does not specifically tell how to handle the ongoing exchanges when delete notification is sent. It does say that delete payload deleting IKE SA must be last REQUEST sent over an IKE SA (section 2.8). As the generic requirement for IKEv2 exchange handling is that it MUST be able to process incoming requests at any time (even when it has already send out delete request himself, but not received reply for it yet), the node which have sent delete request out, must still process all incoming notifications (including N(REDIRECT)) until it receives reply to the delete notification. On the other hand the other end who has already started some other exchange with the other node (for example who has sent N(REDIRECT) request) might want to postpone replying to the delete notification until it gets the reply for all ongoing requests it has sent out. In most cases that does not matter, as deleting IKE SA will also delete all data associated with it, thus it does not matter whether it waits replies or not, as those replies can only affect things that will be deleted when IKE SA is deleted, but REDIRECT notification also affects future IKE SAs, thus it should not reply to the delete payload deleting IKE SA until it has received reply for its N(REDIRECT) request. It can also include N(REDIRECT) in to the reply to be sent to delete payload, as was explained already in the mailing list. The responder will then get either of those N(REDIRECT) payloads (either the original request, where it will then send reply, or the reply to the delete payload deleting IKE SA, in which case there will not be any other packets sent out (replies are only sent to request, replies are never sent out for received replies). This behavior is completely valid based on the RFC4306. The reply received for the delete payload deleting IKE SA is just normal reply message, thus it will still be processed as normally. For example the section 5.8 for RFC 4718 says that normally there is no information that needs to be sent to the other side, thus empty information response is usually used, but in this case we do have information we want to send, thus we can just put the N(REDIRECT) there to give that information. Note, that N(REDIRECT) notification payload DOES NOT require any reply, thats why the normal reply message to the request containing N(REDIRECT) will be empty message. > One special case is that N(redirect) is lost and the client sends a > delete request. And in this case, the gateway cannot piggyback the > N(redirect) together with the delete payload. Because otherwise, the > client cannot send back the empty message to the gateway. The request client send contains the delete payload, the reply to that packet normally is empty payload (i.e. there is no delete payload in reply). In this case it would be completely legal to include the N(REDIRECT) notification in the reply packet. The empty message reply is only required if N(REDIRECT) is sent as separate INFORMATIONAL exchange, i.e. it is sent out as request, not as reply. Every single request in IKEv2 do require reply packet to be sent back. Thus the requirement for empty message does not come because we sent N(REDIRECT), it is there because every single request must receive reply. If N(REDIRECT) is included in the reply packet then there will not be any more packets to that exchange. The sender of N(REDIRECT) will know that other end received it as it stopped retransmitting its request (in IKEv2, the initiator of the exchange is always responsible to retransmit the packet until it receives reply or decided the other end has died). > It seems to me to handle all these cases, the safest/simplest way is > that the gateway always waits for the empty message to be received > before it sends the response to the delete request from the client. That is also valid implementation. This is again implementation detail, that does not really affect the protocol, only the implementations. > However, one of reasons of doing redirection is gateway overloading. > With this method, the gateway cannot release unuseful IKE SA as soon > as possible, which prevents the gateway releasing resources and > serving more clients. Otherwise, the draft needs to specify in > detail how to handle these cases. In that case it is better to redirect already during IKE_SA_INIT, and not waste gateway resources by finishing IKE_AUTH at all. That is the most resource consuming part of the IKE SA, thus if gateway is overloaded, then redirect before using that much resources. -- kivinen@iki.fi From fanzhao828@gmail.com Wed Feb 25 14:54:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAF328C0CE for ; Wed, 25 Feb 2009 14:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0EH69BBJREL for ; Wed, 25 Feb 2009 14:54:06 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id CAADC3A6B85 for ; Wed, 25 Feb 2009 14:54:05 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so359845qwe.31 for ; Wed, 25 Feb 2009 14:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EUrMXQFPGo3puyxkRXrsYYQykbJNbYLaQjYKT7Qvky8=; b=rO4hpNzGYcZrKgioIJHgl1zyyMTxWk9gqkV/E7Gh2LikRisMshLWgcpkeL7yDYZ8/U Fvr2K1ZyAS7699TI2yIVmZGDVklFviZ/Ot39v5mMKuUFvFUX0xLNukV192lIfUX4vUBW 7eWhBFIbkOwH0dQgiAWFWpJ8eOXz6Kun1Iq08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T/npzBjkQDkQbBlxZYcUn3YmUURblar/5k7xjDpRrkL7wiTwMD8e1obzPKuaS2ZUMW O1MdyXCp8QaUxR4ms4n5ZyP1pnelbgJye+j5RDMPJfZTtCPDc/qbBbityeRNx4SzHRGd R+WaJM9dHx/k/xWxjxAGhT5kjDQiOHKgWUMtk= MIME-Version: 1.0 Received: by 10.224.53.196 with SMTP id n4mr1244145qag.197.1235602465244; Wed, 25 Feb 2009 14:54:25 -0800 (PST) In-Reply-To: <18853.16835.355300.918724@fireball.kivinen.iki.fi> References: <18853.16835.355300.918724@fireball.kivinen.iki.fi> Date: Wed, 25 Feb 2009 14:54:25 -0800 Message-ID: From: fan zhao To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] questions on redirection during IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:54:07 -0000 Hi Tero, Please see below. On Wed, Feb 25, 2009 at 5:04 AM, Tero Kivinen wrote: > fan zhao writes: >> However, while receiving the NO_ADDITIONAL_SAS in the last IKE_AUTH >> (before the N(Redirect) >> is received), the IPsec client may try to connect with another IPsec >> gateway (it can select one from >> a list of gateways, for example, returned by the DNS response). >> Especially when during HO, >> the client wants to perserve its IP address/mobility states, it needs >> to do so since it knows >> that the connection with the current IPsec gateway is unsuccessful. >> >> Such the selected IPsec gateway may be different from the one that >> will be indicated in the N(REDIRECT). >> Therefore, when the client processes the N(Redirect), it may realize >> that it needs to abort >> the communication with another IPsec gateway, which results in overhead. > > Client should wait for the few milliseconds it takes to get the next > packet immediately following the IKE_AUTH reply before trying to > connect new gateways. If client wants to waste resources by doing > guesses where it will be redirected then that is its problem. RFC 4306 and IKEv2bis do not specify that "Client should wait for the few milliseconds it takes to get the next packet immediately following the IKE_AUTH reply before trying to connect new gateways." This sounds like a new requirement to me. Furthermore, considering that the IPSec gateway sends the NO_ADDITIONAL_SAS not because of redirection, but because of be unwilling to accept the child SA, there is no point that the client needs to wait because the gateway will not send the N(Redirect) in this case. Also, when the N(redirect) is sent in the case of redirection, the informational message carrying the N(redirect) may be lost. So even if the client waits, it may still start IPsec SA establishment with the new gateway. > > So I do not consider that protocol issue but issue with bad > implementations wanting to waste resources. We cannot really solve all > bad implementation issues, vendors can always make bad implementations > which waste even more resources. This issue is because the NO_ADDITIONAL_SAS is re-used during the IKE_AUTH in case of redirection, which results in overheads. The NO_ADDITIONAL_SAS originally is not defined for the redirection purpose. > > For example the client can start connecting to all gateways in the > beginning even before receiving any REDIRECT notification. We do not > have anything in the draft forbidding (or allowing) that either, and > I do not think we need to cover all possible ways people can make bad > implementations. That is a bad implementation indeed. In fact, not only resources are wasted, but also it requires that the implementation of the client be able to identify and delete the useless SAs to obtain the same service later. I do not think any sensible implementor will do that. However, it makes sense when the NO_ADDITIONAL_SAS is received, the client tries to connect to a new gateway. > >> Furthermore, the current draft specifies that when the client receives >> N(redirect), it MUST send an empty >> message as an acknowledgement. > > That requirement does not come from the redirect document, it comes > from the base IKEv2 specification, which mandates that each request > MUST receive reply. Yes. > > The redirect document cannot really change the IKEv2 base document > requirements, thus all implementations implementing IKEv2 will already > require that same thing. OK. > >> However, the current draft does not specify how to handle such >> cases. > > The draft does not need to specify such things, as those are not > redirect specific cases, they are generic IKEv2 questions. > > Base IKEv2 RFC already covers what do when packets are lost, and how > redirects are handled in that case. The issue here is that when the client receives the N(NO_ADDITIONAL_SAS) and before receiving the N(Redirect), it decides to delete the IKE SA since such a SA is useless. When the gateway receives such delete request, it does not know whether the N(Redirect) has already been received. Therefore, it cannot delete the IKE SA because if the N(redirect) is lost and the IKE SA is deleted, the gateway cannot re-transmit the N(redirect). This is the case specific to the redirection. It is possible for the gateway to include the N(redirect) in the reply to the delete request, please see below for more on this. > > The current IKEv2 RFC does not specifically tell how to handle the > ongoing exchanges when delete notification is sent. Maybe because the scenario of redirection is not considered? > > It does say that delete payload deleting IKE SA must be last REQUEST > sent over an IKE SA (section 2.8). As the generic requirement for > IKEv2 exchange handling is that it MUST be able to process incoming > requests at any time (even when it has already send out delete request > himself, but not received reply for it yet), the node which have sent > delete request out, must still process all incoming notifications > (including N(REDIRECT)) until it receives reply to the delete > notification. Yes, agreed. > > On the other hand the other end who has already started some other > exchange with the other node (for example who has sent N(REDIRECT) > request) might want to postpone replying to the delete notification > until it gets the reply for all ongoing requests it has sent out. In > most cases that does not matter, as deleting IKE SA will also delete > all data associated with it, thus it does not matter whether it waits > replies or not, as those replies can only affect things that will be > deleted when IKE SA is deleted, but REDIRECT notification also affects > future IKE SAs, thus it should not reply to the delete payload > deleting IKE SA until it has received reply for its N(REDIRECT) > request. Yes. > > It can also include N(REDIRECT) in to the reply to be sent to delete > payload, as was explained already in the mailing list. The responder > will then get either of those N(REDIRECT) payloads (either the > original request, where it will then send reply, or the reply to the > delete payload deleting IKE SA, in which case there will not be any > other packets sent out (replies are only sent to request, replies are > never sent out for received replies). Yes. Nevertheless, when the client receives the N(Redirect) in an informational request, it may start the IKEv2 with the new IPsec gateway. Now, if it receives another N(Redirect) in the reply to the delete request, the implementation needs to check whether the IKEv2 SA establishment with the new IPsec gateway has already started as a response to the N(Redirect). It increases implementation complexity because the implementation needs to distinguish this case from other cases where the client may actually want to establish multiple IKE sessions with the same IPsec gateway. Furthremore, the N(redirect) is important information that affects the future SA setup, as you said. However, if the reply to the delete request and the N(Redirect) included therein are lost, and if the IPsec gateway deletes the IKE SA immediately when processing the delete request from the client, the client cannot receive the redirection information. If the IPsec gateway does not delete the IKE SA immediately when processing the delete request from the client, there is impact on performance, as identified below. Given N(Redirect) is important for the client, we should include it in the IKE_AUTH (which is a more critical signaling message) to ensure it can be delivered to the client reliably. > > This behavior is completely valid based on the RFC4306. The reply > received for the delete payload deleting IKE SA is just normal reply > message, thus it will still be processed as normally. For example the > section 5.8 for RFC 4718 says that normally there is no information > that needs to be sent to the other side, thus empty information > response is usually used, but in this case we do have information we > want to send, thus we can just put the N(REDIRECT) there to give that > information. OK. Please see above. > > Note, that N(REDIRECT) notification payload DOES NOT require any > reply, thats why the normal reply message to the request containing > N(REDIRECT) will be empty message. OK. > >> One special case is that N(redirect) is lost and the client sends a >> delete request. And in this case, the gateway cannot piggyback the >> N(redirect) together with the delete payload. Because otherwise, the >> client cannot send back the empty message to the gateway. > > The request client send contains the delete payload, the reply to that > packet normally is empty payload (i.e. there is no delete payload in > reply). Umm, if the client requests to delete the SA by sending the delete payload in the informational request, isn't that the gateway needs to send back a reply with the delete payload? I do not understand this sentence. > In this case it would be completely legal to include the > N(REDIRECT) notification in the reply packet. OK. Please see above. > > The empty message reply is only required if N(REDIRECT) is sent as > separate INFORMATIONAL exchange, i.e. it is sent out as request, not > as reply. Every single request in IKEv2 do require reply packet to be > sent back. Thus the requirement for empty message does not come > because we sent N(REDIRECT), it is there because every single request > must receive reply. OK. > > If N(REDIRECT) is included in the reply packet then there will not be > any more packets to that exchange. Yes. However, the reply (N(redirect) is included therein) to the delete request may be lost, right? It may be less likely, but a robust system needs to consider this possible scenario. > The sender of N(REDIRECT) will know > that other end received it as it stopped retransmitting its request > (in IKEv2, the initiator of the exchange is always responsible to > retransmit the packet until it receives reply or decided the other end > has died). > >> It seems to me to handle all these cases, the safest/simplest way is >> that the gateway always waits for the empty message to be received >> before it sends the response to the delete request from the client. > > That is also valid implementation. This is again implementation > detail, that does not really affect the protocol, only the > implementations. > >> However, one of reasons of doing redirection is gateway overloading. >> With this method, the gateway cannot release unuseful IKE SA as soon >> as possible, which prevents the gateway releasing resources and >> serving more clients. Otherwise, the draft needs to specify in >> detail how to handle these cases. > > In that case it is better to redirect already during IKE_SA_INIT, and > not waste gateway resources by finishing IKE_AUTH at all. That is the > most resource consuming part of the IKE SA, thus if gateway is > overloaded, then redirect before using that much resources. It is also possible that when during the IKE_AUTH, the IPSec gateway realizes it is overloaded, for example, many data packets belonging to the already established IPSec SA need to be processed. Therefore, the IPsec gateway issues N(redirection) to the client. Thanks for your reply. Sincerely, fan > -- > kivinen@iki.fi > From fanzhao828@gmail.com Wed Feb 25 17:57:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A6F28C1B6 for ; Wed, 25 Feb 2009 17:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrs+DqCbjTA5 for ; Wed, 25 Feb 2009 17:57:28 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id CCC8628C188 for ; Wed, 25 Feb 2009 17:57:27 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so458756qwe.31 for ; Wed, 25 Feb 2009 17:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GXzC1kt9MtxnKG6IiAX8uGh6yVo2zC+0690Q0A22omM=; b=JNiy747Im16Zw0LVD6JbetWmF0Zgee+B2BGirq6zWzRReN9HjnRBTY+fJhpIWP8aLB KT8rWNISuRdU65hx3gddF8Zpg1o0Iu1jHd6JAc72YoMksynVVV0J0hEWH+fIhk+gh9Em fWDKgCmwAxUrbJP9YgZsv9WMKPIIB6oC1v+74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XYzoMEjP6CNKWHeegSZIHI+rqFn7gwZ7jdOmgadRL7ckNHBJEieJ+hzFITaTLRyUCG pVT6jTfPsmVdaAiZgAJdkekLbjDm6uP24MieiwN6NGL4j+1bgvL+fQYTULi15Zy4XwcX 1xK58qz6EXSRM9HibSxwizo/z5wzOrbloZ3n0= MIME-Version: 1.0 Received: by 10.224.67.193 with SMTP id s1mr1399176qai.291.1235613468261; Wed, 25 Feb 2009 17:57:48 -0800 (PST) In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613328A0BE6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED498@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613328A0BE6@il-ex01.ad.checkpoint.com> Date: Wed, 25 Feb 2009 17:57:48 -0800 Message-ID: From: fan zhao To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:57:29 -0000 Hi, I am ok with moving this draft forward. However, I strongly prefer allowing redirection in the IKE_AUTH as well. As you may know, last week on the 3GPP SA2 meeting, the SA2 working group adopted the solution that uses the IKEv2 signaling message for gateway redirection/reallocation when the mobile terminal performs attach. Sincerely, fan On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir wrote: > I support advancing this. > > I preferred allowing the redirect in IKE_AUTH as well, but it seems like = the group consensus went against that. > > One textual comment: since we have section 7 describing a symmetric case = (redirect by either peer), section 6.1 should be chagned to reflect that th= e REDIRECT_SUPPORTED may be in either or both of the request and reply of t= he Initial exchange, and perhaps a picture can be added to section 7. > > Even without this, the text is clear and useful. > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >> On Behalf Of Yaron Sheffer >> Sent: Wednesday, February 25, 2009 2:34 PM >> To: IPsecme WG >> Subject: Re: [IPsec] WG Last Call: >> draft-ietf-ipsecme-ikev2-redirect-04 >> >> This is a reminder that we are having a last call for the >> Redirect document. Even if you support advancing this >> document, but have no other comments, please state your >> opinion on the list. >> >> Thanks, >> =A0 =A0 =A0 Yaron >> >> > -----Original Message----- >> > From: ipsec-bounces@ietf.org >> [mailto:ipsec-bounces@ietf.org] On Behalf >> > Of Yaron Sheffer >> > Sent: Monday, February 16, 2009 11:46 >> > To: IPsecme WG >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> > >> > This is a 2 week working group last call for >> draft-ietf-ipsecme-ikev2- >> > redirect-04. The target status for this document is >> Proposed Standard. >> > >> > Please send your comments to the ipsec list by March 2, 2009, as >> > follow- ups to this message. >> > >> > Please clearly indicate the position of any issue in the Internet >> > Draft, and if possible provide alternative text. Please >> also indicate >> > the nature or severity of the error or correction, e.g. major >> > technical, minor technical, nit, so that we can quickly judge the >> > extent of problems with the document. >> > >> > The document can be accessed here: >> > http://tools.ietf.org/html/draft-ietf- >> > ipsecme-ikev2-redirect-04. >> > >> > Please note that one issue is currently open against this draft: >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. >> > >> > Thanks, >> > =A0 =A0 Yaron >> > >> > Email secured by Check Point >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > Scanned by Check Point Total Security Gateway. >> > >> > Scanned by Check Point Total Security Gateway. >> >> Email secured by Check Point >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. >> > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Wed Feb 25 22:17:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE5C28C1EE for ; Wed, 25 Feb 2009 22:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk4eSFLtRNGO for ; Wed, 25 Feb 2009 22:17:09 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EE9B228C1ED for ; Wed, 25 Feb 2009 22:17:08 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 009952AC003; Thu, 26 Feb 2009 08:17:28 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AB5C52AC001 for ; Thu, 26 Feb 2009 08:17:27 +0200 (IST) X-CheckPoint: {49A63316-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1Q6HQsZ020880 for ; Thu, 26 Feb 2009 08:17:27 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 26 Feb 2009 08:17:26 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 26 Feb 2009 08:17:24 +0200 Thread-Topic: BCP 146, RFC 5406 on Guidelines for Specifying the Use of IPsec Version 2 Thread-Index: AcmXoRQBtQ6LvNQ9SkCbltN2qvhdBgAOI2mw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED544@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] FW: BCP 146, RFC 5406 on Guidelines for Specifying the Use of IPsec Version 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 06:17:10 -0000 This BCP has been more than 6 years in the making, it is still mostly relev= ant, but not entirely. Yaron -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of rfc-editor@rfc-editor.org Sent: Thursday, February 26, 2009 1:29 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: BCP 146, RFC 5406 on Guidelines for Specifying the Use of IPsec Ve= rsion 2 A new Request for Comments is now available in online RFC libraries. BCP 146 =20 RFC 5406 Title: Guidelines for Specifying the Use=20 of IPsec Version 2=20 Author: S. Bellovin Status: Best Current Practice Date: February 2009 Mailbox: bellovin@acm.org Pages: 13 Characters: 30393 See Also: BCP0146 I-D Tag: draft-bellovin-useipsec-10.txt URL: http://www.rfc-editor.org/rfc/rfc5406.txt The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. This document specifies an Internet=20 Best Current Practices for the Internet Community, and requests=20 discussion and suggestions for improvements. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for=20 improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Email secured by Check Point From yaronf@checkpoint.com Thu Feb 26 05:59:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FE928C2B3 for ; Thu, 26 Feb 2009 05:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 op-srVk+4gDL for ; Thu, 26 Feb 2009 05:59:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8AAC128C0E0 for ; Thu, 26 Feb 2009 05:59:23 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 91CF22AC003; Thu, 26 Feb 2009 15:59:43 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 701062AC001; Thu, 26 Feb 2009 15:59:42 +0200 (IST) X-CheckPoint: {49A69F6A-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1QDxfsZ008236; Thu, 26 Feb 2009 15:59:41 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 26 Feb 2009 15:59:41 +0200 From: Yaron Sheffer To: fan zhao , Yoav Nir Date: Thu, 26 Feb 2009 15:59:41 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmXtaRb4zjD5HgzTU+5mZT/RtSPLwAY9/cQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED607@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BED498@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613328A0BE6@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:59:25 -0000 I join Yoav and Fan in supporting this draft, even in its current form. How= ever I also agree with them that the protocol will be cleaner (and subseque= ntly, implementations will be simpler), if we allow redirection in IKE_AUTH= , specifically only in the last message of the exchange. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > fan zhao > Sent: Thursday, February 26, 2009 3:58 > To: Yoav Nir > Cc: IPsecme WG > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >=20 > Hi, >=20 > I am ok with moving this draft forward. However, I strongly prefer > allowing > redirection in the IKE_AUTH as well. As you may know, last week > on the 3GPP SA2 meeting, the SA2 working group adopted the solution > that uses the IKEv2 signaling message for gateway redirection/reallocatio= n > when the mobile terminal performs attach. >=20 > Sincerely, > fan >=20 >=20 >=20 > On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir wrote: > > I support advancing this. > > > > I preferred allowing the redirect in IKE_AUTH as well, but it seems lik= e > the group consensus went against that. > > > > One textual comment: since we have section 7 describing a symmetric cas= e > (redirect by either peer), section 6.1 should be chagned to reflect that > the REDIRECT_SUPPORTED may be in either or both of the request and reply > of the Initial exchange, and perhaps a picture can be added to section 7. > > > > Even without this, the text is clear and useful. > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > >> On Behalf Of Yaron Sheffer > >> Sent: Wednesday, February 25, 2009 2:34 PM > >> To: IPsecme WG > >> Subject: Re: [IPsec] WG Last Call: > >> draft-ietf-ipsecme-ikev2-redirect-04 > >> > >> This is a reminder that we are having a last call for the > >> Redirect document. Even if you support advancing this > >> document, but have no other comments, please state your > >> opinion on the list. > >> > >> Thanks, > >> =A0 =A0 =A0 Yaron > >> > >> > -----Original Message----- > >> > From: ipsec-bounces@ietf.org > >> [mailto:ipsec-bounces@ietf.org] On Behalf > >> > Of Yaron Sheffer > >> > Sent: Monday, February 16, 2009 11:46 > >> > To: IPsecme WG > >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > >> > > >> > This is a 2 week working group last call for > >> draft-ietf-ipsecme-ikev2- > >> > redirect-04. The target status for this document is > >> Proposed Standard. > >> > > >> > Please send your comments to the ipsec list by March 2, 2009, as > >> > follow- ups to this message. > >> > > >> > Please clearly indicate the position of any issue in the Internet > >> > Draft, and if possible provide alternative text. Please > >> also indicate > >> > the nature or severity of the error or correction, e.g. major > >> > technical, minor technical, nit, so that we can quickly judge the > >> > extent of problems with the document. > >> > > >> > The document can be accessed here: > >> > http://tools.ietf.org/html/draft-ietf- > >> > ipsecme-ikev2-redirect-04. > >> > > >> > Please note that one issue is currently open against this draft: > >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. > >> > > >> > Thanks, > >> > =A0 =A0 Yaron > >> > > >> > Email secured by Check Point > >> > _______________________________________________ > >> > IPsec mailing list > >> > IPsec@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ipsec > >> > > >> > Scanned by Check Point Total Security Gateway. > >> > > >> > Scanned by Check Point Total Security Gateway. > >> > >> Email secured by Check Point > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> Scanned by Check Point Total Security Gateway. > >> > >> Scanned by Check Point Total Security Gateway. > >> > > Email secured by Check Point > > _______________________________________________ > > 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 >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From root@core3.amsl.com Thu Feb 26 17:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6E7C728C221; Thu, 26 Feb 2009 17:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090227014501.6E7C728C221@core3.amsl.com> Date: Thu, 26 Feb 2009 17:45:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:45:01 -0000 --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-02.txt Pages : 139 Date : 2009-02-26 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). 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-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-26174248.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Thu Feb 26 19:06:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F20D28C25F for ; Thu, 26 Feb 2009 19:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zknhNJygMGI6 for ; Thu, 26 Feb 2009 19:06:02 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5FE8F28C27B for ; Thu, 26 Feb 2009 19:06:01 -0800 (PST) Received: from [10.20.30.158] (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 n1R36KCa015822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2009 20:06:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 26 Feb 2009 19:06:19 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Please review ikev2bis-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 03:06:03 -0000 The author gang for IKEv2bis have produced a new draft, which can be found at . The diffs between the -02 and -01 can be found at . Please review the draft in the near term. This will help us be sure where we stand before going forwards. Yaron will open a batch of new issues, and I have re-opened issue #36. Pasi had some problems with where we ended up on #36. But it is important that everyone review the changes now so that additional changes that we make in the future are on a stable base. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Fri Feb 27 06:20:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4F53A68F2 for ; Fri, 27 Feb 2009 06:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.135, 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 NWMRQS6BPhMz for ; Fri, 27 Feb 2009 06:19:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D52173A682C for ; Fri, 27 Feb 2009 06:19:58 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n1REKGYq007959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 16:20:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n1REKGxX009671; Fri, 27 Feb 2009 16:20:16 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18855.63136.217783.580084@fireball.kivinen.iki.fi> Date: Fri, 27 Feb 2009 16:20:16 +0200 From: Tero Kivinen To: fan zhao In-Reply-To: References: <18853.16835.355300.918724@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 30 min X-Total-Time: 29 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] questions on redirection during IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:20:00 -0000 fan zhao writes: > > Client should wait for the few milliseconds it takes to get the next > > packet immediately following the IKE_AUTH reply before trying to > > connect new gateways. If client wants to waste resources by doing > > guesses where it will be redirected then that is its problem. > > RFC 4306 and IKEv2bis do not specify that "Client should wait for the > few milliseconds it takes to get the next packet immediately following > the IKE_AUTH reply before trying to connect new gateways." RFC4306 does not specify that client MUST immediately close the IKE SA down if it receives NO_ADDITIONAL_SAS during IKE_AUTH. RFC4306 does not say anything about the matter. > This sounds like a new requirement to me. REDIRECT is new requirement, it does cause changes to the implementations, and this is one of those changes, that if implementation was written so it immediately deleted the IKE SA if IKE_AUTH received NO_ADDITIONAL_SAS, then it would be better to change it so it will instead wait for few seconds before deleting the IKE SA. You cannot implement REDIRECT without making any changes to the implementation. Note, that REDIRECT will still work even if you do not wait. It is just bad implementation to immediately delete the IKE SA at that point, as it will most likely just cause busy loop consuming resources. I.e. if the other end happened to return NO_ADDITIONAL_SAS not because of REDIRECT, but because it could not create new IPsec SAs even when it could create IKE SAs. If client implementation immediately deletes IKE SA and starts over, it will create busy loop doing Diffie-Hellmans and authentication and creating new IKE SA as fast as it can, and then delete it again if server still does not have any resources. Much better implementation will add some timer there and will not try again as fast as possible, but instead wait for few tens of seconds to allow server to perhaps free up resources, or at least slow down the busy loop. This does not have anything to do with redirect, it is just how good implementation should behave in general. > Furthermore, considering that the IPSec gateway sends the NO_ADDITIONAL_SAS > not because of redirection, but because of be unwilling to accept the child > SA, there is no point that the client needs to wait because the gateway > will not send the N(Redirect) in this case. Also, when the N(redirect) As I explained above it is better to wait even in that case, as otherwise you just busy loop and create accidental denial of service attack against the server. > This issue is because the NO_ADDITIONAL_SAS is re-used during the IKE_AUTH > in case of redirection, which results in overheads. The NO_ADDITIONAL_SAS > originally is not defined for the redirection purpose. NO_ADDITIONAL_SAS was defined to be used in cases where "responder is unwilling to accept any more CHILD_SAs on this IKE_SA.". This is exactly the case here in the REDIRECT case too. I.e. server does not want to allow new CHILD_SAs on this IKE_SA as it knows it will redirect the client away. It is true that the description only mentioned CREATE_CHILD_SA request, but in most cases the initial IPsec SA creation happening during the IKE_AUTH is handled identically to the CREATE_CHILD_SA. Exceptions where they receive special handling is listed specifically (i.e. KEYMAT generation etc). > The issue here is that when the client receives the > N(NO_ADDITIONAL_SAS) and before receiving the N(Redirect), it > decides to delete the IKE SA since such a SA is useless. When the > gateway receives such delete request, it does not know whether the > N(Redirect) has already been received. It will know that it has not received reply to the N(REDIRECT). > Therefore, it cannot delete the IKE SA because if the N(redirect) is > lost and the IKE SA is deleted, the gateway cannot re-transmit the > N(redirect). This is the case specific to the redirection. It is > possible for the gateway to include the N(redirect) in the reply to > the delete request, please see below for more on this. > > > > > The current IKEv2 RFC does not specifically tell how to handle the > > ongoing exchanges when delete notification is sent. > Maybe because the scenario of redirection is not considered? Not really. The reason it does not cover what happens to the exchange during IKE SA rekey or when IKE SA is deleted, is that those details were just omitted. The delete case is not usually the problem, as when IKE SA is deleted, there is nothing left, meaning there is no need to think what happens to the ongoing exchanges. N(REDIRECT) changes this bit, as this notify will not affect the IKE_SA, it will affect the client state outside the IKE SA, thus it makes big conceptual change to the IKE SA. Thats why the redirect draft needs to specify what happens if you have ongoing N(REDIRECT) out and you receive delete notification for the IKE SA. The bigger generic problem is what happens to the ongoing exchanges during IKE SA rekey. This gets very complicated if you have window size bigger than one, but that is outside the scope of this discussion. > Furthremore, the N(redirect) is important information that affects > the future SA setup, as you said. However, if the reply to the > delete request and the N(Redirect) included therein are lost, and if > the IPsec gateway deletes the IKE SA immediately when processing the > delete request from the client, the client cannot receive the > redirection information. If the IPsec gateway does not delete the > IKE SA immediately when processing the delete request from the > client, there is impact on performance, as identified below. The IPsec gateway must keep the IKE SA up to allow the other end to redirect its delete request just in case the reply was lost, so the gateway will be there to retrasmit its reply to delete request, even if it has already processed the delete request. As IKEv2 is reliable protocol the N(REDIRECT) and the delete payloads will be acknowledged, thus the client will receive them. > > The request client send contains the delete payload, the reply to that > > packet normally is empty payload (i.e. there is no delete payload in > > reply). > Umm, if the client requests to delete the SA by sending the delete payload > in the informational request, isn't that the gateway needs to send back a > reply with the delete payload? I do not understand this sentence. No. You only include delete payload in both directions when you delete CHILD_SAs. IKE SAs are deleted by sending delete payload in the request, and receiving reply to that. Usually that reply is empty, but in this case it could also include N(REDIRECT). > > If N(REDIRECT) is included in the reply packet then there will not be > > any more packets to that exchange. > Yes. However, the reply (N(redirect) is included therein) > to the delete request may be lost, right? It may be > less likely, but a robust system needs to consider this possible scenario. If it is lost, then client will resend its request which contains delete payload, and other end will keep IKE SA up for suitable timout, so it can resend its own reply to that delete request. This is part of standard IKEv2. -- kivinen@iki.fi