From yamaya@fnsc.co.jp Mon Jul 1 04:17:02 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AD321F9CF5 for ; Mon, 1 Jul 2013 04:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNvOxtI+vyQ8 for ; Mon, 1 Jul 2013 04:16:56 -0700 (PDT) Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id F405D21F9B52 for ; Mon, 1 Jul 2013 04:16:55 -0700 (PDT) Received: from ([158.202.233.182]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.1531907; Mon, 01 Jul 2013 20:16:50 +0900 Message-ID: <51D16522.1060806@fnsc.co.jp> Date: Mon, 01 Jul 2013 20:16:50 +0900 From: yamaya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 11:17:02 -0000 Thanks for your comments, and sorry for repsonse delayed. This shared SA model might be potentially weaker than separate SA model, as you said. But I think that, with the shared SA model, an inexpensive CPE can communicate to a large number of other CPEs simultaneously. We have added some statements about the motivation to the I-D and updated it (draft-yamaya-ipsecme-mpsa-01). (2013/03/12 2:25), Paul Wouters wrote: > > > Regarding draft-yamaya-ipsecme-mpsa-00 > > The draft claims to be about "auto discovery and configuration > function". However, I don't actually see any of that in the draft. I > have no idea how nodes find out about other nodes they can talk IPsec > to. As Praveen said, CPEs find out others by BGP. He said that meshed BGP sessions causes a scale issue, but I think that it would be avoided by using Route Reflector. Using Route Refletor, end-point gateways establish one BGP session to Route Refletor. > > What I do see in the draft is a mechanism for a gateway to relay keying > material (nonces!!) for a shared IPsec SA to other nodes > after authenticating such nodes. > > That raises a few questions for me: > > If we want to accomplish a gateway allowing authenticated parties into a > collection of IPsec nodes, why not negotiate separate SA's? There is no > real reason to use a single shared IPsec SA session key, and it vastly > reduced the security. One conpromised node would reveal the IPsec SA > keying material, and with that an attacker could decrypt all the traffic > between all the nodes. Plus an attacker could just add a new node to > the system (depending on the discovery/permission model that I don't > fully understand) > > Why not distribute some kind of token or PSK between gateway and > endpoints, so that two endpoints can then use that to setup the parent > SA and do a proper setup of any child SAs with a unique keying material > for those nodes? As a bonus, that will keep to a much closer deployment to > the existing method. A compromised node might be able to attach itself > to the group, but it won't allow the direct compromise of any other > node-to-node traffic in the collection. Also this allows each node to > reject any proposals for IP address ranges it is unwilling to relay to > a particular node. > > Furthermore, I see no discovery method in the draft that tells a node > which other nodes are available via this shared MPSA. How does a node > know it can do the MPSA to another node? It seems the draft has no > method for asking the gateway about this. Without such a discovery, > administrators will still end up having to hardcode node configuration, > which is exactly what we are trying to avoid. > > While the diagrams display there can be gateway-endnode and endnode-endnode > traffic using the MPSA, I see no way how the endnode could know this. As > a node, I have traffic destined for 192.0.2.1. Should I use an MPSA? > > I see no correlation between SRC / DST IP addresses and the MPSA. Does this > mean any endnode can connect to any other endnode within the group and just > make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very > weak trust model. Additionally, what if I want my node to be in more then > one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting > to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between > nodes? Or will they just start sending me encrypted ESP for the MPSA? What if > someone replays some MPSA encrypted traffic appearing from one node, will my > node suddenly stop talking cleartext to it? That seems a weak authentication > model. > > I find the terminology for "rollover time1" (ROLL1) and "rollover time2" > (ROLL2) confusing, as it seems to actually be more representative of an > "expiration date" and an "activation date". It seems to also overlap with > "lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related > to the start of ROLL2. So we know when to roll, but we still need to connect > to the gateway to get the keying material? So why not just limit everything > to an expiration time for when the nodes have to contact the gateway again > for the new MPSA keying material? In the enviroment with many CPEs it may take long time to distirubute a key to all CPEs. So "activation date" is introduced for CPEs to switch new MPSA from old one after finishing the distribution. Auto discovery is accomplished by BGP, that session keeps to be connected between the gateway, as route reflector, and a CPE. The BGP session should be on CHILD_SA, so the SA between the gateway and CPE should kept to be. > > The gateway is supopsed to rekey, but that can be difficult with clients > behind NAT. Since the gateway informed the clients about the lifetimes, > why not let the clients reconnect? > > So in short: > > - Distribute authentication information/permission, not encryption material > (IKE SA's and traffic selectors are needed) > - Devise a mechanism to obtain a list of active nodes or a method > to ask the gateway if a certain node is avaialble via MPSA or not. > - Reduce the information sent to the minimum required. > - Agree on some kind of scope of IP addresses for the MPSA > > As it stands, I don't really see myself implementing this. There are > too many unanswered security concerns, and it does not have enough > discovery features in it for my needs. > > Paul > > Best Regards, Arifumi Yamaya From internet-drafts@ietf.org Tue Jul 2 06:55:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281D221F9E24; Tue, 2 Jul 2013 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0cztbHMBVnZ; Tue, 2 Jul 2013 06:55:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5F21F9C82; Tue, 2 Jul 2013 06:55:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702135521.24760.9407.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 06:55:21 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:55:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-00.txt Pages : 16 Date : 2013-07-02 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcgrew@cisco.com Tue Jul 2 07:32:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1321F9EDD for ; Tue, 2 Jul 2013 07:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNA3z9s1FBGA for ; Tue, 2 Jul 2013 07:32:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED521F9EDB for ; Tue, 2 Jul 2013 07:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=804; q=dns/txt; s=iport; t=1372775529; x=1373985129; h=message-id:subject:from:to:cc:date:mime-version: content-transfer-encoding; bh=9TsNJd3MhoEOqDa7pRWDpCk0HoQgt/d7dLFzNHtMG8M=; b=M6gSAN1mTqK2JZkZ76X86S4No3y0y7MK3XJilm8WmUinTq3ZX7K9tznR 25I2OlgPb61O2zqBcmeXniOwPqjEYEZ8Z7O602WcQDqwA+FgZzS7izh1/ QiuVyMgsTupHShqzxkoCwiHitE6Wc8biT4bWlTI0v+OCfmJfhfWJTvBFA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACHk0lGtJV2a/2dsb2JhbABagwkyAYMIR7xGgQEWdIJNVjUCJgKJAQyqYZE4gSaONB2CO4EaA5hyhHiLJIMtIA X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229974958" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 02 Jul 2013 14:31:55 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r62EVsrS019795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 14:31:55 GMT Message-ID: <1372775513.3983.77.camel@darkstar> From: David McGrew To: ipsec@ietf.org Date: Tue, 02 Jul 2013 10:31:53 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "wajdi.k.feghali@intel.com" , Paul Hoffman Subject: [IPsec] feedback on draft-ietf-ipsecme-esp-ah-reqts-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:32:13 -0000 Hi, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)" is an active standards-track draft that updates the ESP and AH algorithm requirements (RFC 4835). It was published in March of this year, and has seen little comment since then. There were several comments on the earlier (individual submission) version of this draft, which hopefully have been addressed. Let us know if you have comments. The usage guidance section is new, and it offers advice on how to use ESP and AH to achieve cryptographic security goals. We have solicited review from the CFRG on that section. thanks, David Quick link: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/?include_text=1 From svanru@gmail.com Tue Jul 2 22:16:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909421F9C6C for ; Tue, 2 Jul 2013 22:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXnqtVgs1kjB for ; Tue, 2 Jul 2013 22:16:51 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3F21F9C68 for ; Tue, 2 Jul 2013 22:16:51 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so6312474lab.32 for ; Tue, 02 Jul 2013 22:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=w77JWZwUs5RdZKmeeY2E9ALSny0NwzTAqoAEQD4+NQA=; b=hZLlQbkftxxhak8H1PgrVH9r7dWWOdyS4Cbn3go3aHGOTPXaFW8aJCCQNPNOhfg6Ct yCEC66MNVRqJxTfsK6nDE4W8ZMieyyqX/spraJDqtEe6bYwFUZHG5hUGp/XI8bPFIXwA fucV5Nm09BJCTYo3KQjkya8Vp9uZqF55504sv/2arUGcUtpLBYXf9jYJDoYMqkOumF9J QfK1/EirUaw9ABxkj2O4FhpbKdlateJksX8Fcjk1eVKDJJMT7g88jBZmGHJS4v55Pb8B XQMAVaLzN5x4OPT5T7NEBq4CEGV4yx/lVlSgaQ8kSMktSvPxNDPmPb53I6YqNBUlzWTr usaA== X-Received: by 10.112.143.162 with SMTP id sf2mr425825lbb.1.1372828610158; Tue, 02 Jul 2013 22:16:50 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ea14sm9852907lbb.11.2013.07.02.22.16.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Jul 2013 22:16:49 -0700 (PDT) Message-ID: <29CDA3EC0B294A93BE22F9FB19339AF1@buildpc> From: "Valery Smyslov" To: References: <20130702135521.24760.9407.idtracker@ietfa.amsl.com> Date: Wed, 3 Jul 2013 09:16:54 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:16:52 -0000 Hi all, I've posted a new draft on IKEv2 fragmentation. It is mostly identical to draft-smyslov-ipsecme-ikev2-fragmentation-01, except for the following: 1. The name of the draft is changed to reflect that it is now a WG document (and its intended status too). 2. As Tero suggested in http://www.ietf.org/mail-archive/web/ipsec/current/msg08329.html, a few words are added that other UDP-based protocols treat 576 bytes as safe minimum IP packet size. 3. Acknoledgements section is added. 4. Noticed typos and grammar errors are fixed. Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Tuesday, July 02, 2013 5:55 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-00.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 : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-00.txt > Pages : 16 > Date : 2013-07-02 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mglt.ietf@gmail.com Fri Jul 5 03:26:30 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66D711E8295; Fri, 5 Jul 2013 03:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uKkcKZeqfWc; Fri, 5 Jul 2013 03:26:30 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6CA11E8294; Fri, 5 Jul 2013 03:26:29 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so7061328wiw.17 for ; Fri, 05 Jul 2013 03:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=7POkl84fbRJTrRlfXPc5s8Ykns0+cxJImbUpKbXjBEw=; b=LpZ/Nt6I1dV0zTN59m98qpdeXwocNSLqegcddoEJDWWfTkfHjbOE7hWpvMuNTwPSUF Q64bzauWOhOXB1w76OPcGnKwB8SSPZJafwTgpPZCGptfSn67bbKT68sEGUatdgTjFa5U NBKiEniR2Vf/M6Abzxqbm+vK4IiTmoyzCbhzWUdCqN9UrROZ8WFIZPBxYsjMwQSznMlG 2A7a8FhwGCl7lIYq5daEzPWv1mQ1WRwv2LAZw+YHks12y9vwQJNBZl7ece619ZvUgJBt G/iLowFl2+K9oLxTDb3cvqjEqbXgG39zaI/sdj/EUzOPKEqmRglT5BNVIoZl0Zkoe/ms 4VkQ== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr5849450wjb.3.1373019988708; Fri, 05 Jul 2013 03:26:28 -0700 (PDT) Received: by 10.194.163.134 with HTTP; Fri, 5 Jul 2013 03:26:28 -0700 (PDT) Date: Fri, 5 Jul 2013 12:26:28 +0200 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf1985eb2515704e0c120b3 Cc: "mif@ietf.org" Subject: [IPsec] IPsec and multiple interfaces: draft-mglt-ipsecme-keep-old-ike-sa-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 10:26:30 -0000 --047d7bf1985eb2515704e0c120b3 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find here the new draft on multiple IPsec interfaces. From comments of IETF86, we do not create multiple VPNs on each interfaces from a single IKEv2 channel. Instead we keep a single IKEv2 channel for each VPN. To create VPNs on multiple interfaces, we first create parallel IKEv2 (and associated VPNs). These VPNS are using the same interfaces.Then the additional IKEv2 channel (and associated VPN) are moved to the proper interface using MOBIKE. We believe the changes IPsec are minors. Feel free to make comments! URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-keep-old-ike-sa-00.txt Best Regards, Daniel ---------- Forwarded message ---------- From: Date: Fri, Jul 5, 2013 at 12:15 PM Subject: New Version Notification for draft-mglt-ipsecme-keep-old-ike-sa-00. txt To: Daniel Migault A new version of I-D, draft-mglt-ipsecme-keep-old-ike-sa-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-ipsecme-keep-old-ike-sa Revision: 00 Title: KEEP_OLD_IKE_SA Extension Creation date: 2013-07-05 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-keep-old-ike-sa-00.txt Status: http://datatracker.ietf.org/doc/draft-mglt-ipsecme-keep-old-ike-sa Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-keep-old-ike-sa-00 Abstract: This document considers a VPN Client setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interface requires to set an IKEv2 channel on each interface, and then on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which MAY each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily load the VPN client and the authentication infrastructure. This document presents the KEEP_OLD_IKE_SA extension, where an additional IKEv2 channel from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bf1985eb2515704e0c120b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

Please find here the new draft o= n multiple IPsec interfaces. From comments of IETF86, we do not create mult= iple VPNs on each interfaces from a single IKEv2 channel. Instead we keep a single IKEv2 channel for e= ach VPN.=A0

To create VPNs on multiple interfaces, we first create = parallel IKEv2 (and associated VPNs). These VPNS are using the same interfa= ces.Then the additional IKE= v2 channel (and associated VPN) ar= e moved to the proper interface using MOBIKE.

We believe=A0the changes IPsec are minors. Feel free to= make comments!


Best Regards,=A0
Daniel
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 5, 2013 at 12:15 PM
Subject: New Version Notification for= draft-mglt-ipsecme-k= eep-old-ike-sa-00.txt
To: Daniel Migault <mglt.ietf@gma= il.com>



A new version of I-D, draft-mglt-ip= secme-keep-old-ike-sa-00.txt
has= been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-ike-sa
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 KEEP_OLD_IKE_SA Extension
Creation date: =A0 2013-07-05
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-mglt-ipsecme-keep-old-ike-sa-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-mglt-ipsecme-keep-old-ike-sa
Htmlized: =A0 =A0 =A0 =A0htt= p://tools.ietf.org/html/draft-mglt-ipsecme-keep-old-ike-sa-00


Abstract:
=A0 =A0This document considers a VPN Client setting a VPN with a security =A0 =A0gateway where at least one of the peer has multiple interfaces.

=A0 =A0With the current IKEv2, the outer IP addresses of the VPN are
=A0 =A0determined= by those used by IKEv2 channel. =A0As a result using
=A0 =A0multiple interface requires to set an IKEv2 channel on each
=A0 =A0interface<= /span>, and then on each paths if both the VPN Client and the
=A0 =A0security gateway have multiple interfaces. =A0Setting multiple IKEv2
=A0 =A0channel involves multiple authentications which MAY each require
=A0 =A0multiple round trips and delay the VPN establishment. =A0In addition =A0 =A0multiple authentications unnecessarily load the VPN client and the
=A0 =A0authentica= tion infrastructure.

=A0 =A0This document presents the KEEP_OLD_IKE_SA extension, where an
=A0 =A0additional= IKEv2 channel from an already authenticated IKEv2 channel. =A0 =A0The newly created IKEv2 channel is set without the IKEv2
=A0 =A0authentica= tion exchange. =A0The newly created IKEv2 channel can then be=
=A0 =A0assigned to another interface using MOBIKE.




The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--047d7bf1985eb2515704e0c120b3-- From praveenys@juniper.net Sat Jul 6 19:06:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D221F84DC for ; Sat, 6 Jul 2013 19:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EfP-xJVbKm6 for ; Sat, 6 Jul 2013 19:06:18 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 170EA21F9D16 for ; Sat, 6 Jul 2013 19:06:18 -0700 (PDT) Received: from mail44-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE001.bigfish.com (10.236.130.64) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 02:06:17 +0000 Received: from mail44-co9 (localhost [127.0.0.1]) by mail44-co9-R.bigfish.com (Postfix) with ESMTP id 8974B340185 for ; Sun, 7 Jul 2013 02:06:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail44-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=praveenys@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail44-co9 (localhost.localdomain [127.0.0.1]) by mail44-co9 (MessageSwitch) id 1373162775354727_11886; Sun, 7 Jul 2013 02:06:15 +0000 (UTC) Received: from CO9EHSMHS006.bigfish.com (unknown [10.236.132.249]) by mail44-co9.bigfish.com (Postfix) with ESMTP id 4BAEB48004D for ; Sun, 7 Jul 2013 02:06:15 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS006.bigfish.com (10.236.130.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Jul 2013 02:06:11 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 6 Jul 2013 19:06:11 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sat, 6 Jul 2013 19:06:10 -0700 Received: from CO9EHSOBE021.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 6 Jul 2013 19:18:55 -0700 Received: from mail121-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 02:06:10 +0000 Received: from mail121-co9 (localhost [127.0.0.1]) by mail121-co9-R.bigfish.com (Postfix) with ESMTP id 22543940332 for ; Sun, 7 Jul 2013 02:06:09 +0000 (UTC) Received: from mail121-co9 (localhost.localdomain [127.0.0.1]) by mail121-co9 (MessageSwitch) id 1373162758248887_22897; Sun, 7 Jul 2013 02:05:58 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.247]) by mail121-co9.bigfish.com (Postfix) with ESMTP id 2E1DDBC004C; Sun, 7 Jul 2013 02:05:58 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Jul 2013 02:05:54 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.66]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0324.000; Sun, 7 Jul 2013 02:05:52 +0000 From: Praveen Sathyanarayan To: IPsecme WG Thread-Topic: New draft for address ADVPN (draft-sathyanarayan-ipsecme-advpn-00) Thread-Index: AQHOeraBZuGjW2/X8kKJ6r4RrH5Kjg== Date: Sun, 7 Jul 2013 02:05:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.255.135.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7782F9A4B17CAE4EA3674E36BE8117BE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CHECKPOINT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Stephen Hanna , "ynir@checkpoint.com" , Suresh Melam , Praveen Sathyanarayan , "k.pentikousis@huawei.com" , "mglt.ietf@gmail.com" Subject: [IPsec] New draft for address ADVPN (draft-sathyanarayan-ipsecme-advpn-00) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:06:24 -0000 Hi, Please find new draft that specifies a protocol to address ADVPN Requirement (draft-ietf-ipsecme-p2p-vpn-problem-07.txt). This document proposes a protocol that can demonstratively scale in large IPsec deployments while ensuring that routing stretch is minimized and network resources are used more optimally. The proposed protocol extends [IKEV2] to meet the requirements spelled out in draft-ietf-ipsecme-p2p-vpn-problem-07.txt, providing a standard way to dynamically establish and tear down IPsec tunnels as needed without requiring non-scalable configuration. The protocol introduces the concept of a =B3shortcut" which can be used by compliant IPsec gateways to optimize the traffic path between two peers. The protocol has provisions for adhering to established policies and is applicable to single- and multi-domain environments. Shortcuts can be established and torn dynamically and, the proposed solution is applicable to a variety of use cases and scenarios, pertaining to both wired and wireless networks. URL: http://www.ietf.org/id/draft-sathyanarayan-ipsecme-advpn-00.txt Please provide us your feedback. Thanks, Praveen From paul.hoffman@vpnc.org Sat Jul 6 19:34:50 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD021F9D7E for ; Sat, 6 Jul 2013 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGbCqYdaIU9j for ; Sat, 6 Jul 2013 19:34:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB5E121F9C91 for ; Sat, 6 Jul 2013 19:34:49 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r672YkpF013819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 6 Jul 2013 19:34:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 6 Jul 2013 19:34:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53B91C26-0D0F-4231-96E2-3A4871812EF2@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1508) Subject: Re: [IPsec] New draft for address ADVPN (draft-sathyanarayan-ipsecme-advpn-00) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:34:50 -0000 OK, I'll start. Which of the requirements from = draft-ietf-ipsecme-ad-vpn-problem do any of the authors believe this = proposal meets completely? Adequately? Barely? Not at all? --Paul Hoffman= From praveenys@juniper.net Sat Jul 6 19:46:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0078C21F9DCF for ; Sat, 6 Jul 2013 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfVrEORsHE9N for ; Sat, 6 Jul 2013 19:46:29 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0E421F9DD0 for ; Sat, 6 Jul 2013 19:46:29 -0700 (PDT) Received: from mail225-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 02:46:28 +0000 Received: from mail225-tx2 (localhost [127.0.0.1]) by mail225-tx2-R.bigfish.com (Postfix) with ESMTP id 6D236A000F4 for ; Sun, 7 Jul 2013 02:46:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I1b0bI1432I4015Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail225-tx2: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=praveenys@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail225-tx2 (localhost.localdomain [127.0.0.1]) by mail225-tx2 (MessageSwitch) id 1373165186824215_18373; Sun, 7 Jul 2013 02:46:26 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.231]) by mail225-tx2.bigfish.com (Postfix) with ESMTP id BD68F90006F for ; Sun, 7 Jul 2013 02:46:26 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Jul 2013 02:46:26 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 6 Jul 2013 19:46:25 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 6 Jul 2013 19:46:24 -0700 Received: from DB8EHSOBE004.bigfish.com (213.199.154.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 6 Jul 2013 19:59:10 -0700 Received: from mail196-db8-R.bigfish.com (10.174.8.230) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.22; Sun, 7 Jul 2013 02:46:23 +0000 Received: from mail196-db8 (localhost [127.0.0.1]) by mail196-db8-R.bigfish.com (Postfix) with ESMTP id F33CBAC0077 for ; Sun, 7 Jul 2013 02:46:22 +0000 (UTC) Received: from mail196-db8 (localhost.localdomain [127.0.0.1]) by mail196-db8 (MessageSwitch) id 1373165180542228_17687; Sun, 7 Jul 2013 02:46:20 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.249]) by mail196-db8.bigfish.com (Postfix) with ESMTP id 7F6DF1401C9; Sun, 7 Jul 2013 02:46:20 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 7 Jul 2013 02:46:20 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.66]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0324.000; Sun, 7 Jul 2013 02:46:18 +0000 From: Praveen Sathyanarayan To: Paul Hoffman , IPsecme WG Thread-Topic: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00) Thread-Index: AQHOerwmQ6josprnAkazvnhLq1wEdg== Date: Sun, 7 Jul 2013 02:46:16 +0000 Message-ID: In-Reply-To: <53B91C26-0D0F-4231-96E2-3A4871812EF2@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.255.135.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <39C4054CFEFDB742BEB79C752ED02A48@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VPNC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:46:35 -0000 Hi Paul, FYI We have "Appendix B Comparison Against ADVPN Requirements=B2. This section compares draft-ietf-ipsecme-ad-vpn-problem this proposed ADVPN protocol. I believe, we meet the requirement completely. We welcome your feedback on it.=20 Thanks, Praveen On 7/6/13 7:34 PM, "Paul Hoffman" wrote: >OK, I'll start. Which of the requirements from >draft-ietf-ipsecme-ad-vpn-problem do any of the authors believe this >proposal meets completely? Adequately? Barely? Not at all? > >--Paul Hoffman >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > > From paul.hoffman@vpnc.org Sat Jul 6 19:51:28 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9C521F9D62 for ; Sat, 6 Jul 2013 19:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBW2-6nB04ma for ; Sat, 6 Jul 2013 19:51:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3356B21F9DA9 for ; Sat, 6 Jul 2013 19:51:26 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r672pOGu014480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 19:51:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 6 Jul 2013 19:51:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85C666C9-A2D2-4F27-938E-4CD86D902A22@vpnc.org> References: To: Praveen Sathyanarayan X-Mailer: Apple Mail (2.1508) Cc: IPsecme WG Subject: Re: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:51:28 -0000 On Jul 6, 2013, at 7:46 PM, Praveen Sathyanarayan = wrote: > We have "Appendix B Comparison Against ADVPN Requirements=B2. This = section > compares draft-ietf-ipsecme-ad-vpn-problem this proposed ADVPN = protocol. I > believe, we meet the requirement completely. We welcome your feedback = on > it.=20 Sorry, I was being too terse. The appendix lists the requirements, but = doesn't say how well the authors think they met or didn't meet each one. = Are there requirements you feel that the proposal covers less well than = others? --Paul Hoffman= From ynir@checkpoint.com Sat Jul 6 23:30:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0341E21F9E3A for ; Sat, 6 Jul 2013 23:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4X5FT3zkRdk for ; Sat, 6 Jul 2013 23:30:18 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BF36A21F9E2C for ; Sat, 6 Jul 2013 23:30:17 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r676Tst9012131; Sun, 7 Jul 2013 09:29:55 +0300 X-CheckPoint: {51D90AE2-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.26]) with mapi id 14.02.0342.003; Sun, 7 Jul 2013 09:29:54 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00) Thread-Index: AQHOerzr9OayIPk4pkqQfzI+NF40QZlYjvmA Date: Sun, 7 Jul 2013 06:29:55 +0000 Message-ID: <209064D8-D0E5-4B8A-82D9-C2DA3B60E173@checkpoint.com> References: <85C666C9-A2D2-4F27-938E-4CD86D902A22@vpnc.org> In-Reply-To: <85C666C9-A2D2-4F27-938E-4CD86D902A22@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.33] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 118f9b4956168e9e4210d9487b63b8f8086742ee20 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Praveen Sathyanarayan Subject: Re: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 06:30:24 -0000 On Jul 7, 2013, at 5:51 AM, Paul Hoffman wrote: > On Jul 6, 2013, at 7:46 PM, Praveen Sathyanarayan = wrote: >=20 >> We have "Appendix B Comparison Against ADVPN Requirements=B2. This secti= on >> compares draft-ietf-ipsecme-ad-vpn-problem this proposed ADVPN protocol.= I >> believe, we meet the requirement completely. We welcome your feedback on >> it.=20 >=20 > Sorry, I was being too terse. The appendix lists the requirements, but do= esn't say how well the authors think they met or didn't meet each one. Are = there requirements you feel that the proposal covers less well than others? Hi Paul I don't know if I speak for all the authors, but I think the draft covers a= ll the absolute requirements, as in #2: "ADVPN peers MUST allow IPsec Tunne= ls to be setup with other members of the ADVPN without any configuration ch= anges, even when peer addresses get updated every time the device comes up.= ". Yes, our document allows this. Where I feel there is still room for impr= ovement is where the requirements are stated as "should be minimal" or "sho= uld be simple". Specifically: Requirement #1: "For any network topology ... gateways and endpoints SHOULD= minimize configuration changes when a new gateway or endpoint is added, re= moved or changed." If Endpoint E sends traffic to networks b, c, and d through gateway G, then= our protocol allows gateway G to introduce E to another gateway, say H, an= d to instruct E to send traffic to network c through gateway H. In a hub-an= d-spoke configuration, that means that endpoint E has to be preconfigured w= ith all of the addresses in the ADVPN. So if we add a gateway (with its ass= ociated network) this new network has to be configured on all endpoints. Th= is is not minimal. We are considering two ways of fixing this: 1. Begin with all traffic going through the hub gateway, and add a "BYPASS= " shortcut to tell the gateway about all the traffic that needs not be sent= through the hub, or 2. Introduce a "trusted peer" that can send shortcuts for any traffic sele= ctor, not just delegate what our policy already says to send through it. Feedback about these two options will be highly appreciated. Requirement #8: work behind NAT. In this version of the document, the gatew= ay sending the SHORTCUT messages (the suggester) has done IKE_AUTH with bot= h spokes, and knows whether one or the other is behind NAT. If one is behin= d NAT and the other is not, it can tell the one behind the NAT to be the in= itiator. If both are behind NAT, it can and should avoid suggesting a short= cut. We think this can be improved upon. After all, VoIP applications such = as Skype manage to work pretty much anywhere where there isn't a firewall t= hat is actively blocking them. We have considered adding NAT traversal mech= anisms such as STUN, but we need to get more knowledge on the subject befor= e we're ready to add this to our solution. Requirement #15: per-peer QoS. Our protocol does not prevent peers from set= ting up multiple tunnels for multiple QoS classes. However, the SHORTCUT no= tification does not contain any QoS policy. So assuming that peer A learned= of peer C through a message from peer B, it's unreasonable to believe that= it would have a QoS policy for peer C. Not sure we need to do anything abo= ut this, but we'd be happy for people to tell us differently. Yoav From k.pentikousis@huawei.com Mon Jul 8 03:45:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E321F8C4C for ; Mon, 8 Jul 2013 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI8ntvqOU0cW for ; Mon, 8 Jul 2013 03:45:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1021F854F for ; Mon, 8 Jul 2013 03:45:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATF67277; Mon, 08 Jul 2013 10:45:03 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 11:44:34 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 11:45:00 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.253]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.007; Mon, 8 Jul 2013 18:44:54 +0800 From: Konstantinos Pentikousis To: "ipsec@ietf.org" Thread-Topic: [ippm] FW: New Version Notification for draft-ietf-ippm-ipsec-00.txt Thread-Index: AQHOebIGfkTngs0nYkmQ9kQdzDyEu5lam5+Q Date: Mon, 8 Jul 2013 10:44:52 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C24BB1AB0D@szxeml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] FW: [ippm] FW: New Version Notification for draft-ietf-ippm-ipsec-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:45:09 -0000 RGVhciBBbGwsDQoNCkkgdGhpbmsgdGhpcyBkcmFmdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gc29t ZSBmb2xrcyBpbiBpcHNlY21lLiBMb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4NCg0K QmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogS29uc3RhbnRpbm9zIFBlbnRpa291c2lzIFttYWlsdG86ay5wZW50aWtvdXNpc0BodWF3 ZWkuY29tXSANClNlbnQ6IEZyaWRheSwgSnVseSAwNSwgMjAxMyAzOjExIFBNDQpUbzogaXBwbUBp ZXRmLm9yZw0KU3ViamVjdDogW2lwcG1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wMC50eHQNCg0KRGVhciBBbGwsDQoNCldlIHBvc3RlZCB0 aGUgdXBkYXRlZCBkcmFmdCBvbiAiTmV0d29yayBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBmb3Ig SVBzZWMiIGFuZCB3ZSdyZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cywgcmV2aWV3 cyBhbmQgY29udHJpYnV0aW9ucy4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMsIFlhbmcgYW5k IEVtbWEuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBG cmlkYXksIEp1bHkgMDUsIDIwMTMgMzowNCBQTQ0KVG86IEN1aXlhbmc7IEtvbnN0YW50aW5vcyBQ ZW50aWtvdXNpczsgWmhhbmdsaWppYSAoQSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgS29zdGFzIFBlbnRpa291c2lzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLWlwcG0taXBzZWMNClJldmlzaW9u OgkgMDANClRpdGxlOgkJIE5ldHdvcmsgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgZm9yIElQc2Vj DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0wNQ0KR3JvdXA6CQkgaXBwbQ0KTnVtYmVyIG9mIHBh Z2VzOiAxNQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLWlwcG0taXBzZWMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1pcHNl Yy0wMA0KDQoNCkFic3RyYWN0Og0KICAgSVBzZWMgaXMgYSBtYXR1cmUgdGVjaG5vbG9neSB3aXRo IHNldmVyYWwgaW50ZXJvcGVyYWJsZQ0KICAgaW1wbGVtZW50YXRpb25zLiAgSW5kZWVkLCB0aGUg dXNlIG9mIElQc2VjIHR1bm5lbHMgaXMgaW5jcmVhc2luZ2x5DQogICBnYWluaW5nIHBvcHVsYXJp dHkgaW4gc2V2ZXJhbCBkZXBsb3ltZW50IHNjZW5hcmlvcywgbm90IHRoZSBsZWFzdCBpbg0KICAg d2hhdCB1c2VkIHRvIGJlIHNvbGVseSBhcmVhcyBvZiB0cmFkaXRpb25hbCB0ZWxlY29tbXVuaWNh dGlvbg0KICAgcHJvdG9jb2xzLiAgV2lkZXIgZGVwbG95bWVudCBjYWxscyBmb3IgbWVjaGFuaXNt cyBhbmQgbWV0aG9kcyB0aGF0DQogICBlbmFibGUgdHVubmVsIGVuZC11c2VycywgYXMgd2VsbCBh cyBvcGVyYXRvcnMsIHRvIG1lYXN1cmUgb25lLXdheSBhbmQNCiAgIHR3by13YXkgbmV0d29yayBw ZXJmb3JtYW5jZS4gIFVuZm9ydHVuYXRlbHksIGhvd2V2ZXIsIHN0YW5kYXJkIElQDQogICBwZXJm b3JtYW5jZSBtZWFzdXJlbWVudCBzZWN1cml0eSBtZWNoYW5pc21zIGNhbm5vdCBiZSByZWFkaWx5 IHVzZWQNCiAgIHdpdGggSVBzZWMuICBUaGlzIGRvY3VtZW50IG1ha2VzIHRoZSBjYXNlIGZvciBl bXBsb3lpbmcgSVBzZWMgdG8NCiAgIHByb3RlY3QgdGhlIE9uZS13YXkgYW5kIFR3by1XYXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29scyAoTy8NCiAgIFRXQU1QKSBhbmQgcHJvcG9zZXMgYSBt ZXRob2Qgd2hpY2ggY29tYmluZXMgSUtFdjIgYW5kIE8vVFdBTVAgYXMNCiAgIGRlZmluZWQgaW4g UkZDIDQ2NTYgYW5kIFJGQyA1MzU3LCByZXNwZWN0aXZlbHkuICBUaGlzIHNwZWNpZmljYXRpb24N CiAgIGFpbXMsIG9uIHRoZSBvbmUgaGFuZCwgdG8gZW5zdXJlIHRoYXQgTy9UV0FNUCBjYW4gYmUg c2VjdXJlZCB3aXRoIHRoZQ0KICAgYmVzdCBtZWNoYW5pc21zIHdlIGhhdmUgYXQgb3VyIGRpc3Bv c2FsIHRvZGF5IHdoaWxlLCBvbiB0aGUgb3RoZXINCiAgIGhhbmQsIGl0IGZhY2lsaXRhdGVzIHRo ZSBhcHBsaWNhYmlsaXR5IG9mIE8vVFdBTVAgdG8gbmV0d29ya3MgdGhhdA0KICAgaGF2ZSBhbHJl YWR5IGRlcGxveWVkIElQc2VjLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From Tina.Tsou.Zouting@huawei.com Mon Jul 8 13:49:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B16E21F9CE7 for ; Mon, 8 Jul 2013 13:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VNh7mBXSPB0 for ; Mon, 8 Jul 2013 13:48:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5F21F9C55 for ; Mon, 8 Jul 2013 13:48:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATG06676; Mon, 08 Jul 2013 20:48:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 21:48:22 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 21:48:49 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Mon, 8 Jul 2013 13:48:45 -0700 From: Tina TSOU To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-song-ipsecme-seq-icv-01.txt Thread-Index: AQHOfAb3jaw6yWAnb0Gl2g/i1Yb3qplbQKtg Date: Mon, 8 Jul 2013 20:48:44 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-song-ipsecme-seq-icv@tools.ietf.org" Subject: [IPsec] FW: New Version Notification for draft-song-ipsecme-seq-icv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:49:00 -0000 RGVhciBhbGwsDQpUaGlzIGlzIGZvciB5b3VyIHJlYWRpbmcgcGxlYXN1cmUgYW5kIHJldmlldy4N CllvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIQ0KDQpUaGFuayB5b3Us DQpUaW5hDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNl bnQ6IDIwMTPlubQ35pyIOOaXpSAxMToxNA0KPiBUbzogVGluYSBUU09VOyBqaWZlaSBzb25nOyBW aXNod2FzIE1hbnJhbA0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXNvbmctaXBzZWNtZS1zZXEtaWN2LTAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1zb25nLWlwc2VjbWUtc2VxLWljdi0wMS50eHQgaGFzIGJlZW4NCj4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWZlaSBTb25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtc29uZy1pcHNlY21lLXNlcS1pY3YN Cj4gUmV2aXNpb246CSAwMQ0KPiBUaXRsZToJCSBJUHNlYyBzZXF1ZW5jZSBudW1iZXIgaW50ZWdy aXR5IGNoZWNrIHZhbHVlDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA4DQo+IEdyb3VwOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDEwDQo+IFVSTDogICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc29uZy1p cHNlY21lLQ0KPiBzZXEtaWN2LTAxLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29uZy1pcHNlY21lLXNlcS1pY3YNCj4gSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zb25nLWlwc2VjbWUt c2VxLWljdi0wMQ0KPiBEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LXNvbmctaXBzZWNtZS1zZXEtDQo+IGljdi0wMQ0KPiANCj4gQWJzdHJhY3Q6 DQo+ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIElQc2VjIEFIIGFuZCBFU1Agc2VxdWVu Y2UgbnVtYmVyDQo+ICAgIHZhbGlkYXRpb24gc2NoZW1lLCB3aGljaCBpcyBjb21wbGVtZW50YXJ5 IHRvIHRoZSBleGlzdGluZyBJQ1YNCj4gICAgbWVjaGFuaXNtIGFuZCBhbnRpLXJlcGxheSBtZWNo YW5pc20gb2YgQUggYW5kIEVTUCBpbiBkZWZlbnNlIGFnYWluc3QNCj4gICAgRE9TIGF0dGFjay4g IEl0IGlzIGFuIG9wdGlvbmFsIGZlYXR1cmUgbmVnb3RpYWJsZSB0aHJvdWdoIElLRSwgZm9yDQo+ ICAgIHRoaXMgZmVhdHVyZSB0byBiZSBuZWdvdGlhdGVkLCBib3RoIHNlbmRlciBhbmQgcmVjZWl2 ZXIgbXVzdA0KPiAgICBpbXBsZW1lbnQgaXQuICBJZiBhbnkgcGFydHkgZG9lc24ndCBzdXBwb3J0 IGl0LCB0aGVuIHRoaXMgZmVhdHVyZQ0KPiAgICBzaG91bGQgYmUgZXhjbHVkZWQgZnJvbSBuZWdv dGlhdGlvbi4gIFRoZSByYXRpb25hbGUgZm9yIHN1Y2ggYSBzY2hlbWUNCj4gICAgaXMgZGlzY3Vz c2VkIGZpcnN0OyB0aGVuIHJlcXVpcmVtZW50cyBhbmQgZ3VpZGVsaW5lcyBmb3IgZGVzaWduIG9m DQo+ICAgIHRoZSBzY2hlbWUgYXJlIGxhaWQgb3V0LiAgVGhlcmUgY2FuIGJlIHZhcmlvdXMgd2F5 cyB0byBpbXBsZW1lbnQgdGhlDQo+ICAgIHNjaGVtZSwgc29tZSByZWZlcmVuY2UgZGVzaWducyBh cmUgZGlzY3Vzc2VkIHRvIHNldCB0aGUgYmFzZSBmb3INCj4gICAgZWZmb3J0IG9mIGlkZW50aWZ5 aW5nIGJlc3QgcHJhY3RpY2UgYW5kIGV2ZW50dWFsbHkgZXN0YWJsaXNoaW5nIGENCj4gICAgc3Rh bmRhcmQgb24gdGhlIHN1YmplY3QuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From vishwas.manral@hp.com Tue Jul 9 15:35:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFD011E8181 for ; Tue, 9 Jul 2013 15:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.509 X-Spam-Level: X-Spam-Status: No, score=-8.509 tagged_above=-999 required=5 tests=[AWL=-1.910, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCJq1CL3RYkW for ; Tue, 9 Jul 2013 15:35:51 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9A54121F9A61 for ; Tue, 9 Jul 2013 15:35:51 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id 15DB7306C5; Tue, 9 Jul 2013 22:35:50 +0000 (UTC) Received: from G5W5498.americas.hpqcorp.net (16.201.144.178) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 9 Jul 2013 22:34:14 +0000 Received: from G5W2732.americas.hpqcorp.net ([169.254.4.124]) by G5W5498.americas.hpqcorp.net ([16.201.144.178]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 22:34:15 +0000 From: "Manral, Vishwas" To: Paul Hoffman , "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" Thread-Topic: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem Thread-Index: AQHORbJuXNcbmh2LeU+MyHQRBCwiYpkO+WQAgE5j4eA= Date: Tue, 9 Jul 2013 22:34:13 +0000 Message-ID: <5A9E892C56FD5842856290BDA06E12A00B733A21@G5W2732.americas.hpqcorp.net> References: <517FDAC7.8080701@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.201.12.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Jul 2013 08:04:01 -0700 Cc: IPsecme WG , Sean Turner Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:35:58 -0000 Hi Paul, I am done with all the changes. I am now waiting for the reviewers to appro= ve the same. Thanks, Vishwas -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Monday, May 20, 2013 6:28 PM To: draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org Cc: Sean Turner; IPsecme WG Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem Document authors: when might we have the update so Sean can move this forwa= rds? We are gated on this before we solicit AD-VPN protocols. --Paul Hoffman On Apr 30, 2013, at 7:52 AM, Sean Turner wrote: > Please incorporate the QoS issue brought up by Toby. I'd like to make su= re we have everything in the draft that the WG wants before issuing the WGL= C. I also think the TSV/RTG directorates/ADs will be interested in that. >=20 > Can you explain the rationale for the following the changes to requiremen= t #5; I'm just not following it: >=20 > OLD: >=20 > 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN peer. >=20 > NEW: >=20 > 5. Any of the ADVPN Peers MUST NOT have a way to get the long term > authentication credentials for any other ADVPN Peers. The compromise of a= n Endpoint MUST NOT affect the security of communications between other ADV= PN Peers. The compromise of a Gateway SHOULD NOT affect the security of the= communications between ADVPN Peers not associated with that Gateway. >=20 > Is the first sentence still saying basically: "peers can't impersonate pe= ers"? >=20 > Nits: >=20 > - sec 1.1: Need to add what an ADVPN is and expand the acronym >=20 > - sec 4/1.1: The terms allied and federated environment kind of come out = of nowhere. Please add them to s1.1. I just to make sure it's clear what = the difference is between the two. From ietf-ipr@ietf.org Wed Jul 10 13:58:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D652921F9D7A; Wed, 10 Jul 2013 13:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJlITJ8wlQl4; Wed, 10 Jul 2013 13:58:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED5521F9C8A; Wed, 10 Jul 2013 13:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: charliek@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710205813.3273.16051.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 13:58:13 -0700 Cc: byfraser@cisco.com, ipsec@ietf.org, tytso@mit.edu, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: SSH Communications Security Corp's Statement about IPR related to RFC 4306 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:58:14 -0000 Dear Charlie Kaufman: An IPR disclosure that pertains to your RFC entitled "Internet Key Exchange (IKEv2) Protocol" (RFC4306) was submitted to the IETF Secretariat on 2013-0= 7-10 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2128/). The title of the IPR disclosure is "SSH Communications Security Corp's Statement about IPR relat= ed to RFC 4306.""); The IETF Secretariat From ietf-ipr@ietf.org Wed Jul 10 13:56:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0521F9EB2; Wed, 10 Jul 2013 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g1WwteYAMab; Wed, 10 Jul 2013 13:56:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6983C21F8C20; Wed, 10 Jul 2013 13:56:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: pe@iki.fi, ynir@checkpoint.com, paul.hoffman@vpnc.org, charliek@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710205652.14703.48528.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 13:56:52 -0700 X-Mailman-Approved-At: Thu, 11 Jul 2013 08:20:57 -0700 Cc: paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: SSH Communications Security Corp's Statement about IPR related to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:56:52 -0000 Dear Pasi Eronen, Yoav Nir, Paul E. Hoffman, Charlie Kaufman: An IPR disclosure that pertains to your RFC entitled "Internet Key Exchange Protocol Version 2 (IKEv2)" (RFC5996) was submitted to the IETF Secretariat= on 2013-07-10 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/2129/). The title of the IPR disclosure is "SSH Communications Security Corp's Statement about IPR relat= ed to RFC 5996.""); The IETF Secretariat From internet-drafts@ietf.org Sat Jul 13 13:53:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51DD21F9EAA; Sat, 13 Jul 2013 13:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8ClnHNHNQdt; Sat, 13 Jul 2013 13:53:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4DA21F91B0; Sat, 13 Jul 2013 13:53:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713205343.27399.81488.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 13:53:43 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:53:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-08.txt Pages : 12 Date : 2013-07-13 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaronf.ietf@gmail.com Sun Jul 14 21:45:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB221F9DB2 for ; Sun, 14 Jul 2013 21:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hoTIIYhk0iD for ; Sun, 14 Jul 2013 21:45:24 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D479921F9DA9 for ; Sun, 14 Jul 2013 21:45:23 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id b57so7233988eek.36 for ; Sun, 14 Jul 2013 21:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=ud5M3TriZ3SHr7+Ft13fbtC2w9evUZJQ6ScRwyK9LJo=; b=tAbXWUNZtFt/PUg4tR8luZcni5ZdLYVMfxRWog9Vt62zTfGFbiwo4K6GBKcwLaaL4U kJdFs3ytdYII/jVWjwEUNgOvwptDGkfyrIXMQ9KcBd/Pc60r7+fmpdKSjXJ5iEkM2plD xeMrCAcydbp3CKmvJjjAsE255NSPEf3DUUcXe4/jaQ2Ciyn1D9sDpyVesvK3A9qpRt5D 9UZjElP46dh6WkoWY6iOSo8rNktEgIrS+ubORY/DXiZbszJmkFdQ7/YjRbsIGMyi6mbV biuXgRxrbTHuOPvVO+mksxvDBrTjnnDonfAMsFEqgHRT6vBfD71sW91UDhNcxsBni/a9 mEhg== X-Received: by 10.15.94.142 with SMTP id bb14mr57067275eeb.112.1373863522950; Sun, 14 Jul 2013 21:45:22 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-176-175-149.red.bezeqint.net. [79.176.175.149]) by mx.google.com with ESMTPSA id e44sm99411248eeh.11.2013.07.14.21.45.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 21:45:22 -0700 (PDT) Message-ID: <51E37E60.5030308@gmail.com> Date: Mon, 15 Jul 2013 07:45:20 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] ADVPN proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 04:45:24 -0000 Greetings again. The WG is starting to see proposals for our main work item, Auto Discovery VPNs (ADVPNs). The chairs are aware of two relevant drafts: draft-sathyanarayan-ipsecme-advpn draft-mao-ipsecme-ad-vpn-protocol The chairs would appreciate hearing, on-list or off-list, whether others plan to submit proposals. It is our strong hope that each of the proposals discuss in detail how the proposal relates to the ADVPN requirements that the WG has recently finished (draft-ietf-ipsecme-ad-vpn-problem, which will soon be on its way to the RFC Editor), and that the initial discussion of the drafts here on the list focus on the match between the proposal and the requirements. It is easy to start focusing on the technology used in such proposals, and the WG will get there, but we want to be sure anything we talk about meets the WG's requirements before we spend much time on the technical choices. To that end, we encourage WG members to start commenting on the proposals with an eye to the requirements, particularly the requirements that are most important to each of you. The presentations at the WG meeting in Berlin (which is about two weeks away) will focus on the requirements, and we would really appreciate it if everyone has read the proposals before the meeting. Having an active discussion on the list in the next two weeks will help make our meeting time even more useful. --Paul Hoffman and Yaron Sheffer From internet-drafts@ietf.org Mon Jul 15 15:42:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFBF21F961F; Mon, 15 Jul 2013 15:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mD5htrYCjb5; Mon, 15 Jul 2013 15:42:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7311E826E; Mon, 15 Jul 2013 15:42:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715224217.30553.78178.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:42:17 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:42:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Vishwas Manral Steve Hanna Filename : draft-ietf-ipsecme-ad-vpn-problem-09.txt Pages : 12 Date : 2013-07-15 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Wed Jul 17 07:32:59 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981F21F8FF3 for ; Wed, 17 Jul 2013 07:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq2eocCb5big for ; Wed, 17 Jul 2013 07:32:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 267E621F89D8 for ; Wed, 17 Jul 2013 07:32:56 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6HEWq3W058575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Jul 2013 07:32:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <6EBB609F-23CF-4EBA-9188-C07E35421EED@vpnc.org> Date: Wed, 17 Jul 2013 07:32:54 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPsec] Agenda for Berlin X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:32:59 -0000 See . Currently: IPsecME WG IETF 87, Berlin Introduction, blue sheets, from the chairs: 10 min AD-VPN Problem Statement moving to RFC Editor DH Checks RFC published, or will be very soon draft-ietf-ipsecme-esp-ah-reqts-00 is still active, no presentation Out-of-band authentication dropped due to lack of interest Dealing with fragmentation in IKEv2: 10 min Preventing fragmentation using IKE over TCP was dropped Current: draft-ietf-ipsecme-ikev2-fragmentation-00 AD-VPN Proposals draft-sathyanarayan-ipsecme-advpn: 45 min draft-mao-ipsecme-ad-vpn-protocol: 15 min draft-mglt-ipsecme-keep-old-ike-sa: 10 min draft-yamaya-ipsecme-mpsa: 10 min, if time permits From yaronf.ietf@gmail.com Fri Jul 19 05:10:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799AD21E80B0 for ; Fri, 19 Jul 2013 05:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPtbOKAudzlA for ; Fri, 19 Jul 2013 05:10:36 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8D121E80AA for ; Fri, 19 Jul 2013 05:10:35 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so3907178wes.38 for ; Fri, 19 Jul 2013 05:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pCeSBaXkbp6IZIxEIcEvrOGgHjJ0k/WaK8pU6pVtq/s=; b=n4EkzV9xaeMMNxuPRy7AdGBNhiOV5yJTrRPvXizFfQT0ysJPPibE4g9gBoyuBTj80D 3JCX5Qk6aoof5kZiyqAS6J27jxbF8a96xGQQfBzGb0z6JJDasBcoZZrWUlGVG9BNgmre Q/aELdbYsm0QVRhrixOVFW9K28Xr3Nff7oztA/FuEht4kHO+ixRLQR1iafSRgxYHjGoT 3Zv+VP/i2KEjh4hjDJ6C8+4cWQGFusVSFvgO/9g2t6yNCnEzYqDmmQBb5yAXuYyWoUZv A+em5fwo86ckZZXmG555007v3Kh3pJrBC69HBid9JgUx9ztRWr77Cl0gJ4KfouV5bzOW uWNA== X-Received: by 10.194.122.103 with SMTP id lr7mr11924255wjb.15.1374235834677; Fri, 19 Jul 2013 05:10:34 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-169-97.red.bezeqint.net. [79.179.169.97]) by mx.google.com with ESMTPSA id z6sm22629277wiv.11.2013.07.19.05.10.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 05:10:34 -0700 (PDT) Message-ID: <51E92CB7.9090108@gmail.com> Date: Fri, 19 Jul 2013 15:10:31 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 12:10:37 -0000 Hi,

the comments below are focused on the protocol, rather than on its fit with our requirements. So in a sense I'm jumping the gun here.

Summary

First, the document is very well written, actually fun to read. It presents a relatively simple solution which I personally find advantageous, and seems to cover most of the associated issues.

Where I suspect that we have a problem is in the policy definition, for cross-domain scenarios. I think the currently proposed solution is simplistic, and I realize that a fuller one could easily turn very complex. Specifically the peers in the current proposal simply compare the shortcut request with each peer's SPD for traffic to the *suggester*. Viewed architecturally, this seems to me like mixing the control and the data plane (you cannot have a suggester that's not a valid gateway with a valid SPD). Even if we decide this is a good thing, it might not work in weirder cases like overlapping IP networks.

Details

• Why send the notification to both peers? This creates a race condition, and the data is only informational anyway, i.e. trust may not be required.
• Suggester not a good word. Do we have a better one? Supplicant :-) ?
• Why send the VID in IKE_AUTH and not in IKE_SA_INIT?
• The VID (if at all used) should be temporary, until the RFC is published. OTOH I suggest to have a "supported" notification defined immediately, otherwise we cannot add it later.
• Notification of shortcut success can take 10 sec. Is it still useful?
• Why are the traffic selectors for the shortcut related to the TS between the suggester and the two peers? This precludes the case that the suggester is an off-line "controller", which does not see the actual traffic.
• 3.4: the Critical bit is in fact set.
• 3.4: should not use a private value in the draft. I suggest to have a TBD here, and to mention in the IANA Considerations section that the value currently being used is this one.
• These are not "IPv4" or "DNS" shortcuts. The IPv4 and DNS are just fields in the shortcut definition, and do not make any difference to the shortcut's behavior. I would suggest to have a single type of shortcut, and to use a third ID-like field for the address of the target of the shortcut.
• Validity of the PSK: is it valid for the entire duration set by the suggester? Must it be deleted thereafter? Note that the PSK may be reused if the peers tear down the IKE SA or it is disconnected.
• 3.4.1: Sending the IDr (by the initiator) is not normally mandatory in IKEv2. I think here it should be.
• 3.4.2: why does the IPv6 Address field appear 4 times in the diagram?
• 3.4.3: 12 octets -> 2 octets
• 3.4.3: the recommendation at the end of the section is strange: why is it tied to certificate authentication? A peer presents its ID when authenticating with a PSK, too.
• Response Shortcut: I would prefer a separate Shortcut-Response notification, since this is not a real shortcut of course. Moreover, rather than matching a large number of strings, it's much more convenient to tag each shortcut suggestion with an ID, and include this ID in the response.
• 3.5.2: the last sentence (to do with timeouts) is unclear.
• 3.5.3: why are shortcuts a "service" that can be disabled? What is the benefit?
• 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD
• 3.5.5: the SPD lookup applies to additional things, not only to IP address.
• 3.5: If as an Initiator/Responder I don't like the suggestion that I have received, but I don't want to leak details of my security policy, is there a generic error I can use?

Thanks,
    Yaron


From iesg-secretary@ietf.org Fri Jul 19 08:59:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8508211E8156; Fri, 19 Jul 2013 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdRRp+YHgYpX; Fri, 19 Jul 2013 08:59:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBF921E80E1; Fri, 19 Jul 2013 08:59:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130719155907.28866.13399.idtracker@ietfa.amsl.com> Date: Fri, 19 Jul 2013 08:59:07 -0700 Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Document Action: 'Auto Discovery VPN Problem Statement and Requirements' to Informational RFC (draft-ietf-ipsecme-ad-vpn-problem-09.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:59:08 -0000 The IESG has approved the following document: - 'Auto Discovery VPN Problem Statement and Requirements' (draft-ietf-ipsecme-ad-vpn-problem-09.txt) as Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ Technical Summary The document lists the requirements and likely use cases for auto-discovery IPsec VPNs. These VPNs automate configuration when a very large number of hosts and networks must communicate over IPsec in environments where static configuration is not appropriate. There are already a number of proprietary solutions to this problem, and this document is meant as a precursor to the IETF possibly working on a standardized interoperable solution. Working Group Summary The document was reviewed by many people in the WG over many months and there is strong consensus to publish. There is one possible open issue from one WG participant, but that can be dealt with during IETF review. Document Quality It's a problem statement. Personnel Paul Hoffman is the document shepherd. Sean Turner is the responsible AD. From ynir@checkpoint.com Mon Jul 22 12:28:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8947E21F95EF for ; Mon, 22 Jul 2013 12:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftKOPoWcaKpM for ; Mon, 22 Jul 2013 12:28:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3321F94DC for ; Mon, 22 Jul 2013 12:28:45 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6MJSMcR007032; Mon, 22 Jul 2013 22:28:22 +0300 X-CheckPoint: {51ED87D6-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 22:28:21 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 Thread-Index: AQHOhHkAQ2N/sJqM+kuNvyuPARrxDJlw6AGA Date: Mon, 22 Jul 2013 19:28:21 +0000 Message-ID: <47554A2B-B80A-41B5-9866-4C3FA52F2EDB@checkpoint.com> References: <51E92CB7.9090108@gmail.com> In-Reply-To: <51E92CB7.9090108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.141] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11311fbbe2c3f78f65b91cc74e665c7cb4eef72097 Content-Type: multipart/alternative; boundary="_000_47554A2BB80A41B598664C3FA52F2EDBcheckpointcom_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 19:28:52 -0000 --_000_47554A2BB80A41B598664C3FA52F2EDBcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 19, 2013, at 3:10 PM, Yaron Sheffer > wrote: Hi, the comments below are focused on the protocol, rather than on its fit with= our requirements. So in a sense I'm jumping the gun here. Summary First, the document is very well written, actually fun to read. It presents= a relatively simple solution which I personally find advantageous, and see= ms to cover most of the associated issues. Thanks. Where I suspect that we have a problem is in the policy definition, for cro= ss-domain scenarios. I think the currently proposed solution is simplistic,= and I realize that a fuller one could easily turn very complex. Specifical= ly the peers in the current proposal simply compare the shortcut request wi= th each peer's SPD for traffic to the *suggester*. Viewed architecturally, = this seems to me like mixing the control and the data plane (you cannot hav= e a suggester that's not a valid gateway with a valid SPD). Even if we deci= de this is a good thing, it might not work in weirder cases like overlappin= g IP networks. We'd be happy to hear about those weirder cases. In all cases that we consi= dered, traffic from A to C was flowing through B. B "introduces" A to C so = that the traffic can flow directly. The SHORTCUT doesn't come out of the bl= ue, but is a response to existing traffic. This is easy to do when B is in = the data path, and it also makes policy relatively straightforward. If you = trust certain traffic to go through B, you should also trust that same traf= fic to go through some other party that B delegated this traffic to (we don= 't use the word "delegate" in the draft, but maybe we should). A non-GW suggester would have to receive real-time traffic reports from B, = and also be trusted by A and C to change their SPD. This is believable with= in an administrative domain, but very much not so between domains. This ext= ernal suggester would also have to be capable of bi-directional communicati= ons, as it receives data from B and sends data to A and C. So all the NAT i= ssues and firewall issues come up. We think that adds a lot of complexity. = Also, just because the shortcut messages use the IKE syntax and the IKE key= s, and are co-located with the IKE/IPsec stack does not make this a mixture= of control and data planes. The shortcut messages are entirely control pla= ne, while the IPsec traffic that follows is entirely data plane. Details =95 Why send the notification to both peers? This creates a race condition,= and the data is only informational anyway, i.e. trust may not be required. We assume that the peers don't know each other. So you have to supply them = with PAD entries. The shortcut to one peer tells it to be an initiator whil= e the other is told to be a responder. To avoid the race, all you have to d= o is to first tell the responder, and only when it ACKs do you tell the ini= tiator. =95 Suggester not a good word. Do we have a better one? Supplicant :-) ? Supplicant is taken (thank $DEITY). Until a week before we submitted the dr= aft, we called it a "shortcut starter", but we kept confusing "starter" wit= h "initiator" so we changed the term. delegator? cut-shorter? =95 Why send the VID in IKE_AUTH and not in IKE_SA_INIT? Agree. =95 The VID (if at all used) should be temporary, until the RFC is publishe= d. OTOH I suggest to have a "supported" notification defined immediately, o= therwise we cannot add it later. The VID is only to facilitate testing, and is actually required for using p= rivate-space notifies. Of course, this will be replaced by a "support" noti= fication before this document advances. =95 Notification of shortcut success can take 10 sec. Is it still useful? The success or failure notifications have little value for the suggester an= yway. They are very useful for logging. If the administrator can look at a = log and see that all shortcuts suggested with gateway E failed but traffic = still flowed between the center gateway and E, then something is weird abou= t the E's attachment to the network, and this should be checked and perhaps= fixed. =95 Why are the traffic selectors for the shortcut related to the TS betwee= n the suggester and the two peers? This precludes the case that the suggest= er is an off-line "controller", which does not see the actual traffic. If it doesn't see the traffic the only thing it can do is try to create a m= esh. We don't think that's useful in large configurations. =95 3.4: the Critical bit is in fact set. Why? The Notify payload is defined in 5996 and all payloads defined there = have their critical bit unset. =95 3.4: should not use a private value in the draft. I suggest to have a T= BD here, and to mention in the IANA Considerations section that the value c= urrently being used is this one. OK. =95 These are not "IPv4" or "DNS" shortcuts. The IPv4 and DNS are just fiel= ds in the shortcut definition, and do not make any difference to the shortc= ut's behavior. I would suggest to have a single type of shortcut, and to us= e a third ID-like field for the address of the target of the shortcut. =95 Validity of the PSK: is it valid for the entire duration set by the sug= gester? Must it be deleted thereafter? Note that the PSK may be reused if t= he peers tear down the IKE SA or it is disconnected. We should probably fix the language there. But the PSK is valid as long as = the timeout in the SHORTCUT regardless of how many times the the IKE SA has= been torn down and set up again. If a second SHORTCUT is set up with the s= ame peer, the new PSK replaces the old PSK and sets the timer if the identi= fiers are the same, but it does not cause existing SAs to be torn down. =95 3.4.1: Sending the IDr (by the initiator) is not normally mandatory in = IKEv2. I think here it should be. Good idea. =95 3.4.2: why does the IPv6 Address field appear 4 times in the diagram? Because it takes 4 32-bit rows? =95 3.4.3: 12 octets -> 2 octets Right =95 3.4.3: the recommendation at the end of the section is strange: why is = it tied to certificate authentication? A peer presents its ID when authenti= cating with a PSK, too. Yes, there's something missing there. I think it was supposed to be a sugge= stion that the *certificate* have the same FQDN, similar to HTTPS. =95 Response Shortcut: I would prefer a separate Shortcut-Response notifica= tion, since this is not a real shortcut of course. Moreover, rather than ma= tching a large number of strings, it's much more convenient to tag each sho= rtcut suggestion with an ID, and include this ID in the response. Good idea. That will also allow us to have a SHORTCUT delete message if for= example, the responder agreed to the shortcut, but the initiator refused. =95 3.5.2: the last sentence (to do with timeouts) is unclear. s/shortcut partner to the timeout/shortcut partner prior to the timeout/ =95 3.5.3: why are shortcuts a "service" that can be disabled? What is the = benefit? With AD-VPN the behavior of the gateways is less predictable. It is far eas= ier to trouble-shoot why traffic is not getting to the other side if the SP= D is fixed. Also, using AD-VPN makes you dependent on correct implementatio= n of AD-VPN in gateways you have never heard of. Disabling AD-VPN might fix= the issue. =95 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD =95 3.5.5: the SPD lookup applies to additional things, not only to IP addr= ess. Yes, I guess it is the traffic selectors that matter here. =95 3.5: If as an Initiator/Responder I don't like the suggestion that I ha= ve received, but I don't want to leak details of my security policy, is the= re a generic error I can use? Not currently, but wouldn't a new generic error signal just that? Thanks, Yaron --_000_47554A2BB80A41B598664C3FA52F2EDBcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 19, 2013, at 3:10 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi,

the comments below are focused on the protocol, rather than on its fit with= our requirements. So in a sense I'm jumping the gun here.

Summary

First, the document is very well written, actually fun to read. It presents= a relatively simple solution which I personally find advantageous, and see= ms to cover most of the associated issues.

Thanks.

Where I suspect that we have a problem is in the policy definition, for cro= ss-domain scenarios. I think the currently proposed solution is simplistic,= and I realize that a fuller one could easily turn very complex. Specifical= ly the peers in the current proposal simply compare the shortcut request with each peer's SPD for traffic to th= e *suggester*. Viewed architecturally, this seems to me like mixing the con= trol and the data plane (you cannot have a suggester that's not a valid gat= eway with a valid SPD). Even if we decide this is a good thing, it might not work in weirder cases like ov= erlapping IP networks.

We'd be happy to hear about those weirder cases. In all cases that we consi= dered, traffic from A to C was flowing through B. B "introduces" = A to C so that the traffic can flow directly. The SHORTCUT doesn't come out= of the blue, but is a response to existing traffic. This is easy to do when B is in the data path, and it also makes = policy relatively straightforward. If you trust certain traffic to go throu= gh B, you should also trust that same traffic to go through some other part= y that B delegated this traffic to (we don't use the word "delegate" in the draft, but maybe we = should). 

A non-GW suggester would have to receive real-time traffic reports fro= m B, and also be trusted by A and C to change their SPD. This is believable= within an administrative domain, but very much not so between domains. Thi= s external suggester would also have to be capable of bi-directional communications, as it receives data f= rom B and sends data to A and C. So all the NAT issues and firewall issues = come up. We think that adds a lot of complexity. Also, just because the sho= rtcut messages use the IKE syntax and the IKE keys, and are co-located with the IKE/IPsec stack does not mak= e this a mixture of control and data planes. The shortcut messages are enti= rely control plane, while the IPsec traffic that follows is entirely data p= lane.

Details

=95 Why send the notification to both peers? This creates a race condition,= and the data is only informational anyway, i.e. trust may not be required.=

We assume that the peers don't know each other. So you have to supply = them with PAD entries. The shortcut to one peer tells it to be an initiator= while the other is told to be a responder. To avoid the race, all you have= to do is to first tell the responder, and only when it ACKs do you tell the initiator.

=95 Suggester not a good word. Do we have a better one? Supplicant :-) ?

Supplicant is taken (thank $DEITY). Until a week before we submitted t= he draft, we called it a "shortcut starter", but we kept confusin= g "starter" with "initiator" so we changed the term. de= legator?  cut-shorter?

=95 Why send the VID in IKE_AUTH and not in IKE_SA_INIT?

Agree.

=95 The VID (if at all used) should be temporary, until the RFC is publishe= d. OTOH I suggest to have a "supported" notification defined imme= diately, otherwise we cannot add it later.

The VID is only to facilitate testing, and is actually required for using p= rivate-space notifies. Of course, this will be replaced by a "support&= quot; notification before this document advances.

=95 Notification of shortcut success can take 10 sec. Is it still useful?

The success or failure notifications have little value for the suggest= er anyway. They are very useful for logging. If the administrator can look = at a log and see that all shortcuts suggested with gateway E failed but tra= ffic still flowed between the center gateway and E, then something is weird about the E's attachment to the net= work, and this should be checked and perhaps fixed.

=95 Why are the traffic selectors for the shortcut related to the TS betwee= n the suggester and the two peers? This precludes the case that the suggest= er is an off-line "controller", which does not see the actual tra= ffic.

If it doesn't see the traffic the only thing it can do is try to creat= e a mesh. We don't think that's useful in large configurations.

=95 3.4: the Critical bit is in fact set.

Why?  The Notify payload is defined in 5996 and all payloads defined t= here have their critical bit unset.

=95 3.4: should not use a private value in the draft. I suggest to have a T= BD here, and to mention in the IANA Considerations section that the value c= urrently being used is this one.

OK.

=95 These are not "IPv4" or "DNS" shortcuts. The IPv4 a= nd DNS are just fields in the shortcut definition, and do not make any diff= erence to the shortcut's behavior. I would suggest to have a single type of= shortcut, and to use a third ID-like field for the address of the target of the shortcut.
=95 Validity of the PSK: is it valid for the entire duration set by the sug= gester? Must it be deleted thereafter? Note that the PSK may be reused if t= he peers tear down the IKE SA or it is disconnected.

We should probably fix the language there. But the PSK is valid as lon= g as the timeout in the SHORTCUT regardless of how many times the the IKE S= A has been torn down and set up again. If a second SHORTCUT is set up with = the same peer, the new PSK replaces the old PSK and sets the timer if the identifiers are the same, but it doe= s not cause existing SAs to be torn down.

=95 3.4.1: Sending the IDr (by the initiator) is not normally mandatory in = IKEv2. I think here it should be.

Good idea.

=95 3.4.2: why does the IPv6 Address field appear 4 times in the diagram?

Because it takes 4  32-bit rows?

=95 3.4.3: 12 octets -> 2 octets

Right

=95 3.4.3: the recommendation at the end of the section is strange: why is = it tied to certificate authentication? A peer presents its ID when authenti= cating with a PSK, too.

Yes, there's something missing there. I think it was supposed to be a sugge= stion that the *certificate* have the same FQDN, similar to HTTPS.

=95 Response Shortcut: I would prefer a separate Shortcut-Response notifica= tion, since this is not a real shortcut of course. Moreover, rather than ma= tching a large number of strings, it's much more convenient to tag each sho= rtcut suggestion with an ID, and include this ID in the response.

Good idea. That will also allow us to have a SHORTCUT delete message if for= example, the responder agreed to the shortcut, but the initiator refused.<= /div>

=95 3.5.2: the last sentence (to do with timeouts) is unclear.

s/shortcut partner to the timeout/shortcut partner prior to the timeout/

=95 3.5.3: why are shortcuts a "service" that can be disabled? Wh= at is the benefit?

With AD-VPN the behavior of the gateways is less predictable. It is fa= r easier to trouble-shoot why traffic is not getting to the other side if t= he SPD is fixed. Also, using AD-VPN makes you dependent on correct implemen= tation of AD-VPN in gateways you have never heard of. Disabling AD-VPN might fix the issue.

=95 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD
=95 3.5.5: the SPD lookup applies to additional things, not only to IP addr= ess.

Yes, I guess it is the traffic selectors that matter here.

=95 3.5: If as an Initiator/Responder I don't like the suggestion that I ha= ve received, but I don't want to leak details of my security policy, is the= re a generic error I can use?

Not currently, but wouldn't a new generic error signal just that?

Thanks,
    Yaron


--_000_47554A2BB80A41B598664C3FA52F2EDBcheckpointcom_-- From yaronf.ietf@gmail.com Tue Jul 23 00:52:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4A721E8054 for ; Tue, 23 Jul 2013 00:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fea67tOOqpVP for ; Tue, 23 Jul 2013 00:52:22 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B59A821E804D for ; Tue, 23 Jul 2013 00:52:21 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id j14so4246317eak.8 for ; Tue, 23 Jul 2013 00:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2eaA2Ht1zRI19BH/WCh9PQ5tZEehQWeNCVQuWd5iTx8=; b=grWipgkk1ToFUUhKGBI1oblhDsZfG7PZZId4LCFUc93l+8Bga07o+gMXFcZtr4cU/m qWd/nG/8C6LM/zc4obWyB6L/DkPyDNLHQELrhUOuxO72Gul5clPVtvsGyj/GSl+30Vil gjKrkQ1DX3r2XDGeSXPG9U6+qWnRJhqydKiKgcBlQcRYfC9cqJnM5YEAnlkErVamF3B2 d6EjyMTaDoyjH/bvXLFe2zDYCg8y69d5YTKMzlI4nq6ApZEwMLEDxZnKYQHi5lydCKLC 5zM6vc/yzIKX9Rpqd5aTXYKPGhVGnL0obY7xHHbloacd2ZCDkMDBD6soqeePnPrnr5MG KMwA== X-Received: by 10.15.41.196 with SMTP id s44mr31319097eev.138.1374565940871; Tue, 23 Jul 2013 00:52:20 -0700 (PDT) Received: from [10.0.0.18] (bzq-218-191-220.red.bezeqint.net. [81.218.191.220]) by mx.google.com with ESMTPSA id l42sm56591765eeo.14.2013.07.23.00.52.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 00:52:20 -0700 (PDT) Message-ID: <51EE3632.8020701@gmail.com> Date: Tue, 23 Jul 2013 10:52:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME session slides X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:52:22 -0000 Hi, If you are on our agenda for next Tuesday ( http://tools.ietf.org/wg/ipsecme/agenda), please send your slides to Paul and myself. We would like to have the slides by Friday end of day, so we can post them early enough. Please also let us know who will be presenting. Thanks, Yaron From svanru@gmail.com Wed Jul 24 05:45:41 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B797711E80DC for ; Wed, 24 Jul 2013 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LivZ0O5J+MsH for ; Wed, 24 Jul 2013 05:45:41 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9311E80F0 for ; Wed, 24 Jul 2013 05:45:40 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id d10so447155lbj.0 for ; Wed, 24 Jul 2013 05:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=de1xmEN7bErrP0NaAM0alK18tEMitp+iEnutBOY+GtU=; b=AglTV6zHyH8302dkWaF1QTW0rAb3qqYKJVqBZa5INpAJufVBVpcA54Onc0FTLaTuy9 WEKGYaVBcMdXHW/IrB7+QzDyz9qBTFvv3B+devz2R6bf6/YQsAslBnmyAPGXDqIcbQkK Ghj3iCfWMKWmPLTwrYZqk7jBWIKM2NZo5D5rSvfG20JtO3fARPE7LbyB1CcLXxPkYKlz h9fCosGZilQkikmvD6DdHOpEt6/ZSGg6bhSxEAar9ziJ2sMU5H5JQEa9VBRWHeYFxAjt IVqBDYwZr8to+B7dQYImWFvjqWRF33pulFpdo7NX/htUCMT7KdIIL7aQqFwP1oXqdrJv S3hQ== X-Received: by 10.112.167.228 with SMTP id zr4mr16455307lbb.96.1374669939745; Wed, 24 Jul 2013 05:45:39 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id i9sm14942108lai.4.2013.07.24.05.45.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 05:45:39 -0700 (PDT) Message-ID: <29AADE63542F4470AEA39A9CC3E85D6A@buildpc> From: "Valery Smyslov" To: "IPsecme WG" References: <51E92CB7.9090108@gmail.com> Date: Wed, 24 Jul 2013 16:45:42 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [IPsec] Some comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:45:41 -0000 Hi, a few comments on the draft-sathyanarayan-ipsecme-advpn-00. 1. Why not include port along with IP address of endpoint in shortcut notification? This will allow creating shortcuts in some of the situations when both endpoints are behind NAT, but at least one of them has some knowledge about the external address and port it is reachable on (or it can open port on FW/NAT via some protocol). Endpoint, selected as responder, may return this information to suggester in response to create shortcut notification and suggester will pass it to the other endpoint in corresponding create shortcut notification. 2. Draft says nothing about using of internal addresses when creating and using shortcuts. If endpoint got internal address via CP Payload when it created SA with GW, what should it do when GW requests it to create shortcut? I think, it must not request new address via shortcut IKE SA (as it is useless in most cases) and must use the address, obtained from suggester GW as its internal address for shortcut? 3. It seems that shorcuts must always be in tunnel mode, even in p2p case? 4. I agree with some of Yaron's comments, in particular: - use "supported" Notification instead of VID - use separate Shortcut-Response Regards, Valery Smyslov. From svanru@gmail.com Thu Jul 25 00:27:10 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D57321F9A44 for ; Thu, 25 Jul 2013 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.007 X-Spam-Level: * X-Spam-Status: No, score=1.007 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_50=0.001, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ONwKpV1CVtt for ; Thu, 25 Jul 2013 00:27:10 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A59BB21F9A30 for ; Thu, 25 Jul 2013 00:27:09 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id a16so1257407lbj.3 for ; Thu, 25 Jul 2013 00:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=ebG0/52ynv4UfUpsgqqY31TnRRAEqLNyjGGvRspEKRM=; b=iMGud/EV9b331vTH4su0a3CLOxqJLls64RFFBdyjcS5GREnNaB6JMkroVOl0KP028L SmUbp8u3VvpAzXhnIvgre5NOuhoX375igCkOK8dqXqOf3qOfZq0Jb6UnqueRjojL5Foz ikzeuYtauf0X1aRkVJhzCJ0pUkG7AJxnMVyBj5TTGxNu/INDnvNezZqQWBrLgMYs+o41 kJyUEFG891lUtUAZW7AZJufaDd+hdyn1ya8IcJwTvDhShDQmPK4Ziav5r2HYqYvgAZwU qQGtFE4IbD4p+c4W6wJh/hIlKjZSNb2w+NfMtp9j6bAiHlFxpJXmZXi1TzsCr0Gz4CaB zfIA== X-Received: by 10.112.133.137 with SMTP id pc9mr17970146lbb.27.1374737228453; Thu, 25 Jul 2013 00:27:08 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k10sm15871502lbl.10.2013.07.25.00.27.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 00:27:07 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "IPsecme WG" Date: Thu, 25 Jul 2013 11:27:11 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] Some comments on draft-mglt-ipsecme-keep-old-ike-sa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:27:10 -0000 Hi, some comments on the draft-mglt-ipsecme-keep-old-ike-sa-00. 1. Draft makes some suggestions that IKEv2 allows IKE SA to be silently deleted after successfull rekey. From my understanding of IKEv2, it is wrong, as RFC5996 states several times that IKE SA may be silently deleted only in case of fatal error, like SYNTAX_ERROR, or when peer doesn't respond. In all other cases, including rekey, SA must be deleted explicitly, by sending Delete Payload to the peer. From my understanding, it is initiator of rekey, who is responsible for sending Delete Payload after rekey succeeded. If it doesn't send Delete Payload, old IKE SA will be kept, even without special notifications. So, the name KEEP_OLD_IKE_SA for the notification is probably a bit misleading, as old IKE SA will be kept in any case untill initiator of rekey explicitly deletes it. I think that the real purpose of this notification is to tell responder, that this is not a rekey, but a request to clone old IKE SA, and that in this case responder must not move all child SAs from old IKE SA to the new one. Maybe the better name would be CLONE_IKE_SA. 2. Is there a real value for "Code Values" field? There are two possible values listed - "Keep Old IKE_SA" and "Unused Old IKE_SA". As far as I understand, the former is used if initiator wants to keep SA, and the latter - if it doesn't. But this may be indicated by the precence of notification (keep) or the absence of it (normal rekey, don't keep). 3. What is the purpose of "Question Bit"? 4. I very much don't like the idea to combine this notification with IKE_AUTH exchange, described in Appendix B.5. First, IKE_AUTH is already very complex due to a lot of options and making it more complex must be very well justified. I don't think that reducing a round trip is good justification here. And second, it will not be backward compatible, as initiator doesn't know yet if responder supports this extension, but already uses modified IKE_AUTH exchange. As result - unsupporting responder will be choked by the presense of extra SA, N, KE payloads and most probably returns INVALID_SYNTAX. 5. Typo in the first sentence of B.2 - two "the' and extra "set" (or "establish"). Regards, Valery Smyslov. From wwwrun@rfc-editor.org Thu Jul 25 08:24:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA92221F9AC1; Thu, 25 Jul 2013 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.867 X-Spam-Level: X-Spam-Status: No, score=-101.867 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvuVlk83-l1d; Thu, 25 Jul 2013 08:24:06 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 47CAE21F9AE6; Thu, 25 Jul 2013 08:24:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 87159B1E003; Thu, 25 Jul 2013 08:20:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130725152056.87159B1E003@rfc-editor.org> Date: Thu, 25 Jul 2013 08:20:56 -0700 (PDT) Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 6989 on Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:24:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6989 Title: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Author: Y. Sheffer, S. Fluhrer Status: Standards Track Stream: IETF Date: July 2013 Mailbox: yaronf.ietf@gmail.com, sfluhrer@cisco.com Pages: 10 Characters: 21099 Updates: RFC5996 I-D Tag: draft-ietf-ipsecme-dh-checks-05.txt URL: http://www.rfc-editor.org/rfc/rfc6989.txt This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 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/search/rfc_search.php 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 Association Management Solutions, LLC From yaronf.ietf@gmail.com Thu Jul 25 15:22:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6B521F8F4F for ; Thu, 25 Jul 2013 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWLe7ETHmcMM for ; Thu, 25 Jul 2013 15:22:55 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DE6C921F8EC3 for ; Thu, 25 Jul 2013 15:22:54 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so1221810eaj.13 for ; Thu, 25 Jul 2013 15:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VCWEMSb4IwsgyXgdMHQTnKQK38/jjiYN22T5hbp31B0=; b=0MmZc+QqW105G8TUaneoe6PhTpY6yH6HjEL2g9nBpQpoILh/+nOsmAgfI4TqKzBntz DJWshcy8X14ceoX0VWNu/sYyxU/QHCLiHCF81pOW6ypzHthtknrVvfM269onupJvQQgV 0CLHrnNk3TgubSdw4mciOwq0JbS1893t/C5/esK+wuAdfechOgB/WSx8/yCwEsjG4g5K mMQZNe/Kk4njTYhVswvYFKTJLvicI2Hx0XQJzsG1OBvS60UfC2TNmSETwPrR26R+HTps M+VMYUNfYVN2lVfDwv4WFMCuEyqzpq19hRX/WzvrtZW4897e0avZlGNtUcNjesTY4ZPP KeQg== X-Received: by 10.14.223.5 with SMTP id u5mr36468249eep.131.1374790972395; Thu, 25 Jul 2013 15:22:52 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id j2sm103447eep.6.2013.07.25.15.22.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 15:22:51 -0700 (PDT) Message-ID: <51F16895.4050901@gmail.com> Date: Thu, 25 Jul 2013 20:04:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <51E92CB7.9090108@gmail.com> <47554A2B-B80A-41B5-9866-4C3FA52F2EDB@checkpoint.com> In-Reply-To: <47554A2B-B80A-41B5-9866-4C3FA52F2EDB@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:22:56 -0000 Hi Yoav, sorry for the delayed response, but hey, what's an airplane for? Please see below. Yaron On 2013-07-22 21:28, Yoav Nir wrote: > > On Jul 19, 2013, at 3:10 PM, Yaron Sheffer > wrote: > >> Hi, >> >> the comments below are focused on the protocol, rather than on its fit >> with our requirements. So in a sense I'm jumping the gun here. >> >> Summary >> >> First, the document is very well written, actually fun to read. It >> presents a relatively simple solution which I personally find >> advantageous, and seems to cover most of the associated issues. > > Thanks. > >> Where I suspect that we have a problem is in the policy definition, >> for cross-domain scenarios. I think the currently proposed solution is >> simplistic, and I realize that a fuller one could easily turn very >> complex. Specifically the peers in the current proposal simply compare >> the shortcut request with each peer's SPD for traffic to the >> *suggester*. Viewed architecturally, this seems to me like mixing the >> control and the data plane (you cannot have a suggester that's not a >> valid gateway with a valid SPD). Even if we decide this is a good >> thing, it might not work in weirder cases like overlapping IP networks. > > We'd be happy to hear about those weirder cases. In all cases that we > considered, traffic from A to C was flowing through B. B "introduces" A > to C so that the traffic can flow directly. The SHORTCUT doesn't come > out of the blue, but is a response to existing traffic. This is easy to > do when B is in the data path, and it also makes policy relatively > straightforward. If you trust certain traffic to go through B, you > should also trust that same traffic to go through some other party that > B delegated this traffic to (we don't use the word "delegate" in the > draft, but maybe we should). > > A non-GW suggester would have to receive real-time traffic reports from > B, and also be trusted by A and C to change their SPD. This is > believable within an administrative domain, but very much not so between > domains. This external suggester would also have to be capable of > bi-directional communications, as it receives data from B and sends data > to A and C. So all the NAT issues and firewall issues come up. We think > that adds a lot of complexity. Also, just because the shortcut messages > use the IKE syntax and the IKE keys, and are co-located with the > IKE/IPsec stack does not make this a mixture of control and data planes. > The shortcut messages are entirely control plane, while the IPsec > traffic that follows is entirely data plane. I agree this removes a whole lot of complexity. I'm just not convinced it's good enough for real-world use. The control/data thing is just an analogy: you need to be on the path in order to control it. > >> Details >> >> • Why send the notification to both peers? This creates a race >> condition, and the data is only informational anyway, i.e. trust may >> not be required. > > We assume that the peers don't know each other. So you have to supply > them with PAD entries. The shortcut to one peer tells it to be an > initiator while the other is told to be a responder. To avoid the race, > all you have to do is to first tell the responder, and only when it ACKs > do you tell the initiator. So let's mandate this order. > >> • Suggester not a good word. Do we have a better one? Supplicant :-) ? > > Supplicant is taken (thank $DEITY). Until a week before we submitted the > draft, we called it a "shortcut starter", but we kept confusing > "starter" with "initiator" so we changed the term. delegator? cut-shorter? > "Manager" (half-smile)? Never mind. >> • Why send the VID in IKE_AUTH and not in IKE_SA_INIT? > > Agree. > >> • The VID (if at all used) should be temporary, until the RFC is >> published. OTOH I suggest to have a "supported" notification defined >> immediately, otherwise we cannot add it later. > > The VID is only to facilitate testing, and is actually required for > using private-space notifies. Of course, this will be replaced by a > "support" notification before this document advances. > >> • Notification of shortcut success can take 10 sec. Is it still useful? > > The success or failure notifications have little value for the suggester > anyway. They are very useful for logging. If the administrator can look > at a log and see that all shortcuts suggested with gateway E failed but > traffic still flowed between the center gateway and E, then something is > weird about the E's attachment to the network, and this should be > checked and perhaps fixed. > >> • Why are the traffic selectors for the shortcut related to the TS >> between the suggester and the two peers? This precludes the case that >> the suggester is an off-line "controller", which does not see the >> actual traffic. > > If it doesn't see the traffic the only thing it can do is try to create > a mesh. We don't think that's useful in large configurations. > >> • 3.4: the Critical bit is in fact set. > > Why? The Notify payload is defined in 5996 and all payloads defined > there have their critical bit unset. Of course. Sorry. > >> • 3.4: should not use a private value in the draft. I suggest to have >> a TBD here, and to mention in the IANA Considerations section that the >> value currently being used is this one. > > OK. > >> • These are not "IPv4" or "DNS" shortcuts. The IPv4 and DNS are just >> fields in the shortcut definition, and do not make any difference to >> the shortcut's behavior. I would suggest to have a single type of >> shortcut, and to use a third ID-like field for the address of the >> target of the shortcut. You did not comment on this point. Please consider a rearrangement of the various shortcuts. >> • Validity of the PSK: is it valid for the entire duration set by the >> suggester? Must it be deleted thereafter? Note that the PSK may be >> reused if the peers tear down the IKE SA or it is disconnected. > > We should probably fix the language there. But the PSK is valid as long > as the timeout in the SHORTCUT regardless of how many times the the IKE > SA has been torn down and set up again. If a second SHORTCUT is set up > with the same peer, the new PSK replaces the old PSK and sets the timer > if the identifiers are the same, but it does not cause existing SAs to > be torn down. This all should be noted in the draft. > >> • 3.4.1: Sending the IDr (by the initiator) is not normally mandatory >> in IKEv2. I think here it should be. > > Good idea. > >> • 3.4.2: why does the IPv6 Address field appear 4 times in the diagram? > > Because it takes 4 32-bit rows? > >> • 3.4.3: 12 octets -> 2 octets > > Right > >> • 3.4.3: the recommendation at the end of the section is strange: why >> is it tied to certificate authentication? A peer presents its ID when >> authenticating with a PSK, too. > > Yes, there's something missing there. I think it was supposed to be a > suggestion that the *certificate* have the same FQDN, similar to HTTPS. But then again, we don't do that in IKE (though maybe we should have). > >> • Response Shortcut: I would prefer a separate Shortcut-Response >> notification, since this is not a real shortcut of course. Moreover, >> rather than matching a large number of strings, it's much more >> convenient to tag each shortcut suggestion with an ID, and include >> this ID in the response. > > Good idea. That will also allow us to have a SHORTCUT delete message if > for example, the responder agreed to the shortcut, but the initiator > refused. > >> • 3.5.2: the last sentence (to do with timeouts) is unclear. > > s/shortcut partner to the timeout/shortcut partner prior to the timeout/ > >> • 3.5.3: why are shortcuts a "service" that can be disabled? What is >> the benefit? > > With AD-VPN the behavior of the gateways is less predictable. It is far > easier to trouble-shoot why traffic is not getting to the other side if > the SPD is fixed. Also, using AD-VPN makes you dependent on correct > implementation of AD-VPN in gateways you have never heard of. Disabling > AD-VPN might fix the issue. OK, but is there a useful difference between a gateway where AD-VPN was disabled and one that doesn't support it? Eventually the gateway operators need to talk to one another :-) > >> • 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD >> • 3.5.5: the SPD lookup applies to additional things, not only to IP >> address. > > Yes, I guess it is the traffic selectors that matter here. > >> • 3.5: If as an Initiator/Responder I don't like the suggestion that I >> have received, but I don't want to leak details of my security policy, >> is there a generic error I can use? > > Not currently, but wouldn't a new generic error signal just that? Yes and no. There are two quite specific responses, unmatched PAD and unmatched SPD. I would have liked a "Shortcut Refused", too. > >> Thanks, >> Yaron >> > From yaronf.ietf@gmail.com Thu Jul 25 15:40:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452CB21F8F4A for ; Thu, 25 Jul 2013 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2aatv0qAwDx for ; Thu, 25 Jul 2013 15:40:20 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9699121F8F3C for ; Thu, 25 Jul 2013 15:40:20 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so1231061eak.0 for ; Thu, 25 Jul 2013 15:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RvPqdCt4OcnzMkhru+laganJyYsCTlaCuL63AxlEF3Q=; b=kUkxtiEzlDV/xhoD3aaQxUPkQU+pPfv0mptW9+EGeFAcion/2IbLuWC+O27Yn2zkYi 7SqfEKNqBxntevowzKZwk7LBhApa8q41KBHNMAFaOPpX3ejl/LzPj9fGB2lc1FW+ikcL ILnSz2LmtFB0ufQnEeeicx4RT2oAP8lqRrtZMwSkM26aPG+Rht2bRadFf3qPWVGe2aqy SSJi5oy+SeI+yWs1a2lDi6WLOtgRfkn2Hn3oBdB/kwhv8pMxnFQe9S3dTAnfSlT5Kwpl Rn/rOBAV29S/DN2/YEVcBQTS1q40ZnkDq9VzVm3Q6pc8Hw7JnYMbsn4IZ5pNfYv/g9g8 /hTw== X-Received: by 10.14.203.194 with SMTP id f42mr44959133eeo.53.1374792019760; Thu, 25 Jul 2013 15:40:19 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id i43sm1698083eeg.10.2013.07.25.15.40.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 15:40:19 -0700 (PDT) Message-ID: <51F1A952.5080002@gmail.com> Date: Fri, 26 Jul 2013 00:40:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Comments on draft-mglt-ipsecme-keep-old-ike-sa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:40:21 -0000 Just a couple comments. Overall the idea makes sense to me. - Should not ignore the extension if it is applied to a non-IKE SA. I think a Syntax error would be more appropriate. - There seems to be no distinction between non-support of the extension and just not keeping the SA for some reason. Is this OK? If this is done with the notification code values, please clarify it in the draft. Thanks, Yaron From yaronf.ietf@gmail.com Thu Jul 25 15:46:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2521F8F67 for ; Thu, 25 Jul 2013 15:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FJ34eZOw8JX for ; Thu, 25 Jul 2013 15:46:52 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7531821F8F63 for ; Thu, 25 Jul 2013 15:46:52 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so1227723eak.4 for ; Thu, 25 Jul 2013 15:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=KTNYf3hytufIOGnF5l+7MsFGkNWRt2wjv3W8/3XZMsE=; b=XYG5sGF/dWHA3wMJCosw/3gJfHTPeMtaBWM0+mY1ityykJDwX2c1cyhE7WVesDckn4 Emfqipx0PI9DccUSiNIZUh7KS8afHaN4JiCcfgf4qPV/demDmqqpa4+qq3Ezf7JpYwTQ SH8p7a1GIQbPljaxk8BZeXSJw0N1m4/dWhkA++nLPKBIdtWAoL/VfrqadKzY1cIYI8/g ll4f0W5vO0Epf4BYx3d4DqClkPaoZAbKz19Cfd9pMyshff9BybFQ2Oh7laDy27iiwNDv SPDNbEAswweSyk2b7C6nVpndTbytysaFE/bqHSz65s++G4ZQE+He1v/5cWhvwnygLKAU FbDA== X-Received: by 10.14.215.197 with SMTP id e45mr44710596eep.130.1374792411133; Thu, 25 Jul 2013 15:46:51 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id p49sm76817817eeu.2.2013.07.25.15.46.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 15:46:50 -0700 (PDT) Message-ID: <51F1AAD9.2070509@gmail.com> Date: Fri, 26 Jul 2013 00:46:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPsecme WG References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> In-Reply-To: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> X-Forwarded-Message-Id: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:46:53 -0000 - The coverage of SKF is unclear to me. Specifically, does SKF sign the fragment number? - The heuristic of using the received size to determine the fragment size to send is brittle. Why not optionally negotiate in the notification, by each side (optionally) adding its notion of the PMTU to the notification, and if two values are advertised, choosing the lower of them. One of the peers might be configured or might have already discovered the PMTU. - Why at all add replay protection here? This adds complexity with IMHO no extra value. - I suggest to add a Transport Considerations section. E.g. what if some fragments are lost? Timeouts? Seems to me the packet loss ratio would be higher than normal. Thanks, Yaron From svanru@gmail.com Thu Jul 25 23:58:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792EE21F8445 for ; Thu, 25 Jul 2013 23:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=1.803, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JX4WJFm2bwv for ; Thu, 25 Jul 2013 23:58:13 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8549421F8447 for ; Thu, 25 Jul 2013 23:58:10 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ea20so2046676lab.36 for ; Thu, 25 Jul 2013 23:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=m6C4Q0DhHllPFPdnReB5ZlGi0lwtXGg09GiEXsrKYKY=; b=esOP+OXbc/kEOYuOq1PnDnL0JzTSRorMcaDL8hSLS40/MPuFyY7Fk9pUu/rCPEdJrr UVPcRZez+kLVoMslyJpTQi/JZiJhi84RUnpuG6k8wI42pnZ/9uRqZPLwZ0OkCKpwrHqa CAh/KMEJZt8LJYyHILFYtC6GSQixCzcA51+DIgMtmYeASPdgLeX0M9jnlnlhc0i3+hpb 6pXCcqOJVFSF/zkZfMRhH0ySzUEVoZhTehYrEwBXqM+XBB+sgRCbG4H59WVHi/kq4cAY pHZz0Y98wZqZhDVT+7iit5f8fu2SASIcv+ssIVNm8LZCwQFElfA5hKISg+dXbWunvO4J GeMQ== X-Received: by 10.112.236.33 with SMTP id ur1mr20083960lbc.13.1374821889349; Thu, 25 Jul 2013 23:58:09 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id p10sm18223444lap.8.2013.07.25.23.58.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 23:58:08 -0700 (PDT) Message-ID: <939A128A27464E3B8CA1476486DB3F78@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecme WG" References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> Date: Fri, 26 Jul 2013 10:58:13 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 06:58:14 -0000 Hi Yaron, >- The coverage of SKF is unclear to me. Specifically, does SKF sign the >fragment number? Yes. As with SK Payload the whole message, including IKE Header, unprotected Payloads preceeding SKF Payload (if any) and SKF Payload itself (from the begining of Generic Header to the end of Payload content padding) is included in ICV computation. In description of SKF Payload the draft says: Other fields are identical to those specified in Section 3.14 of [RFC5996]. (Note, that "Other fields" includes "Integrity Checksum Data" field) And Section 3.14 of RFC5669 says about that field: o Integrity Checksum Data is the cryptographic checksum of the entire message starting with the Fixed IKE header through the Pad Length. The checksum MUST be computed over the encrypted message. Its length is determined by the integrity algorithm negotiated. If you think that this reference is insufficient, I could copy-paste descriptions of all other fields from RFC5996. > - The heuristic of using the received size to determine the fragment size > to send is brittle. Why not optionally negotiate in the notification, by > each side (optionally) adding its notion of the PMTU to the notification, > and if two values are advertised, choosing the lower of them. One of the > peers might be configured or might have already discovered the PMTU. I'm in favour of minimizing manual configuration. In general, peers will not know PMTU, but the protocol allows them to discover it. Note, that this doesn't preclude using some preconfigured PMTU values. > - Why at all add replay protection here? This adds complexity with IMHO no > extra value. Replay protection is the feature of IKEv2 (section 2.2). Are you suggesting to abandon it? The draft just clarifies that in case of IKE Fragmentation all fragments will bear the same Message ID as the original message, that was fragmented. So, receiver in this case must not drop all incoming fragments after the first it received, treating them as replays, but must also look at fragment number field. > - I suggest to add a Transport Considerations section. E.g. what if some > fragments are lost? Timeouts? Seems to me the packet loss ratio would be > higher than normal. OK. Regards, Valery. > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mglt.ietf@gmail.com Fri Jul 26 01:17:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02021F8EEA for ; Fri, 26 Jul 2013 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ma-35-dzudQ for ; Fri, 26 Jul 2013 01:17:19 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5057221F84B1 for ; Fri, 26 Jul 2013 01:17:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so525983wib.12 for ; Fri, 26 Jul 2013 01:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yd+AeZpSxed1RAdwhXl2rCKe23HdwxtmTuKV/mKeALY=; b=YTmWTkLEEEmnGXdF8bTmtRS6nfbH5QSj0jeUFDGZGCe6FTJxBlh7SWrWAeSHAmLoHd P1t58gD0rGAo0/cOs08nu/FaOFngj5teeGvYnP+LMEIZn8tTlDY23ZQg7Ttf/F6P4Zef Wlq8ZdgFi56tfZFEudR5RXz9y/D7yM0hpvJHX7WRwH9OWEDc8BQ66VvQPVN4e501jrsn wHzTgz2idatzW+j6Fi0Lb3v7vx4UY0JUC8Zfv8nqMrp5+ZKt8UBYySKP+MEJ02h6dIXZ NDkiFd857f37rk3l0+4qiK8IT9t0X+kmUi0Dl8sXkZT/lej+2PnX97vIzQTStp9Q/f36 o9ow== MIME-Version: 1.0 X-Received: by 10.194.109.104 with SMTP id hr8mr33482851wjb.32.1374826617654; Fri, 26 Jul 2013 01:16:57 -0700 (PDT) Received: by 10.194.138.70 with HTTP; Fri, 26 Jul 2013 01:16:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jul 2013 10:16:57 +0200 Message-ID: From: Daniel Migault To: Valery Smyslov Content-Type: multipart/alternative; boundary=047d7bf10aea2c55e104e265c46f Cc: IPsecme WG Subject: Re: [IPsec] Some comments on draft-mglt-ipsecme-keep-old-ike-sa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:17:22 -0000 --047d7bf10aea2c55e104e265c46f Content-Type: text/plain; charset=ISO-8859-1 Hi Valery, Thank you for the remarks. See my comments in the text. On Thu, Jul 25, 2013 at 9:27 AM, Valery Smyslov wrote: > Hi, > > some comments on the draft-mglt-ipsecme-keep-old-**ike-sa-00. > > 1. Draft makes some suggestions that IKEv2 allows IKE SA to > be silently deleted after successfull rekey. From my understanding > of IKEv2, it is wrong, as RFC5996 states several times that > IKE SA may be silently deleted only in case of fatal error, > like SYNTAX_ERROR, or when peer doesn't respond. > In all other cases, including rekey, SA must be deleted > explicitly, by sending Delete Payload to the peer. > From my understanding, it is initiator of rekey, who is > responsible for sending Delete Payload after rekey succeeded. > If it doesn't send Delete Payload, old IKE SA will be kept, > even without special notifications. That is right. My understanding of RFC5996 is also that it is wrong, and my understanding is that if removed, the IKE_SA MUST be removed with a Delete Payload. However, I am not sure all implementations do so. We tested with Strongswan, and when an (IKE_SA + CHILD_SA). It looks that all CHILD_SA attached to the IKE_SA are rekeyed and removed with Delete Payload, but the IKE_SA does not seem to be deleted with Delete Payloads. On the other hand ipsec statusall does not show the old IKE_SA. We thus assumed the old IKE_SA has been deleted. We have asked to the Strongswan ML for confirmation. > So, the name KEEP_OLD_IKE_SA > for the notification is probably a bit misleading, as old IKE SA > will be kept in any case untill initiator of rekey explicitly deletes > it. > I think that the real purpose of this notification is to tell responder, > that this is not a rekey, but a request to clone old IKE SA, > and that in this case responder must not move all child SAs > from old IKE SA to the new one. Maybe the better name would be > CLONE_IKE_SA. > Absolutely right CLONE_IKE_SA is much better in all senses. I am buying it! > > 2. Is there a real value for "Code Values" field? There are two possible > values listed - "Keep Old IKE_SA" and "Unused Old IKE_SA". > As far as I understand, the former is used if initiator wants > to keep SA, and the latter - if it doesn't. But this may be > indicated by the precence of notification (keep) or the absence > of it (normal rekey, don't keep). > The main purpose of the "Code Values" was to mention there is room for other actions and see if there are. The draft only concerns the IKE_SA, but we may extend it in the future to CHILD_SA for example. But I agree that for the current use, it only clarify the default default behavior. > > 3. What is the purpose of "Question Bit"? > > The Question / response is handled in the IKE header, so we can remove it. > 4. I very much don't like the idea to combine this notification > with IKE_AUTH exchange, described in Appendix B.5. > First, IKE_AUTH is already very complex due to a lot of > options and making it more complex must be very well > justified. I don't think that reducing a round trip is > good justification here. And second, it will not be > backward compatible, as initiator doesn't know yet if > responder supports this extension, but already uses > modified IKE_AUTH exchange. As result - unsupporting > responder will be choked by the presense of extra SA, N, KE > payloads and most probably returns INVALID_SYNTAX. > > Your feedback is very important, thanks. I will add it to the next version. This also convinces me to have a CLONE_IKE_SA_SUPPORTED Notify Payload. 5. Typo in the first sentence of B.2 - two "the' and extra "set" (or > "establish"). > > ok thanks > Regards, > Valery Smyslov. > > ______________________________**_________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/**listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bf10aea2c55e104e265c46f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Valery,

Thank you for the remarks. S= ee my comments in the text.


On Thu, Jul 25, 2013 at 9:27 AM, Valery Smyslov <svanru= @gmail.com> wrote:
Hi,

some comments on the draft-= mglt= -ipsecme-keep-old-ike-sa-00.

1. Draft makes some suggest= ions that IKEv2 allows IKE SA to
=A0 =A0be silently deleted = after successfull rekey. Fr= om my understanding
=A0 =A0of IKEv2, it is wron= g, as RFC5996 states several times that
=A0 =A0IKE SA may be silently deleted only in case of fatal error,
=A0 =A0like SYNTAX_ERROR, o= r when peer doesn't respond.
=A0 =A0In all other cases, including rekey, SA must be deleted
=A0 =A0explicitly, by sendi= ng Delete Payload to the peer.
=A0 =A0From my understanding, it is initiator of rekey, who is
=A0 =A0responsible for send= ing Delete Payload after rekey succeeded.
=A0 =A0If it doesn't send Delete Payload, old IKE SA will be kept,
=A0 =A0even without special= notifications.
=A0
That is right. My understand= ing of RFC5996 is also that it is wrong, and my understanding is that if re= moved, the IKE_SA MUST be removed with a Delete Payload. However, I am not = sure all implementations do so. We tested with Strongswan, and when an (IKE= _SA + CHILD_SA). It looks that all CHILD_SA attached to the IKE_SA are rekeyed and removed with Delete= Payload, but the IKE_SA does not seem=A0to be deleted with Delete Payloads. On the other hand ipsec s= tatusall does not show the old IKE_SA. We thus assumed the old IKE_SA has b= een deleted. We have asked to the Strongswan ML for confirmation.
=A0
So, the name KEEP_OLD_IKE_SA
=A0 =A0for the notification= is probably a bit misleading, as old IKE SA
=A0 =A0will be kept in any = case untill initiator of re= key explicitly deletes it.
=A0 =A0I think that the real purpose of this notification is to tell respon= der,
=A0 =A0that this is not a r= ekey, but a request to clone old IKE SA,
=A0 =A0and that in this cas= e responder must not move all child SAs
=A0 =A0from old IKE SA to t= he new one. Maybe the better name would be
=A0 =A0CLONE_IKE_SA.
=A0
Absolutely right CL= ONE_IKE_SA is much better in all senses. I am buying it!

2. Is there a real value for "Code Values" field? There are two <= span class=3D"GINGER_SOFATWARE_correct">possible
=A0 =A0values listed - &quo= t;Keep Old IKE_SA" and "Unused Old IKE_SA".
=A0 =A0As far as I understand, the former is used if initiator wants
=A0 =A0to keep SA, and the = latter - if it doesn't. But this may be
=A0 =A0indicated by the precence of notification (keep= ) or the absence
=A0 =A0of it (normal rekey, don't keep).

The main purpose of the "Code Values" = was to mention there is room for other actions and see if there are. The dr= aft only concerns the IKE_SA, but we may extend it in the future to CHILD_S= A for example. But I agree that for the current use, it only clarify the de= fault default behavior.=A0

3. What is the purpose of "Question Bit"?

The Question / response is handled in the IKE header,= so we can remove it.
=A0
4. I very much don't like the idea to combine this notification
=A0 =A0with IKE_AUTH exchange, described in Appendix B= .5.
=A0 =A0First, IKE_AUTH is a= lready very complex due to a lot of
=A0 =A0options and making i= t more complex must be very well
=A0 =A0justified. I don'= ;t think that reducing a round trip is
=A0 =A0good justification h= ere. And second, it will not be
=A0 =A0backward compatible,= as initiator doesn't know yet if
=A0 =A0responder supports t= his extension, but already uses
=A0 =A0modified IKE_AUTH ex= change. As result - unsupporting
=A0 =A0responder will be ch= oked by the presense of ext= ra SA, N, KE
=A0 =A0payloads and most probably returns INVALID_SYNT= AX.

Your feedback is very important, thanks. I will add i= t to the next version. This also convinces me to have a CLONE_IKE_SA_SUPPOR= TED Notify Payload.

5. Typo in the first sentence of B.2 - two "the' and extra "s= et" (or "establish").

ok=A0= thanks
=A0
Regards,
Valery Smyslov.

_______________________________________________
IPse= c mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Migau= lt
Orange Labs -- Security
+33 6 70 72 69 58
--047d7bf10aea2c55e104e265c46f-- From ynir@checkpoint.com Fri Jul 26 04:56:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F411621F9360 for ; Fri, 26 Jul 2013 04:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV9NrWl-tEn8 for ; Fri, 26 Jul 2013 04:56:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6699E21F91CB for ; Fri, 26 Jul 2013 04:56:00 -0700 (PDT) Received: from drp-ex10.ad.checkpoint.com (drp-ex10.ad.checkpoint.com [192.168.228.21]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6QBtuVl009617; Fri, 26 Jul 2013 14:55:56 +0300 X-CheckPoint: {51F263CC-1-1B221DC2-1FFFF} Received: from DRP-EX10.ad.checkpoint.com ([169.254.1.252]) by DRP-EX10.ad.checkpoint.com ([169.254.1.46]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 13:55:56 +0200 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 Thread-Index: AQHOhHkAQ2N/sJqM+kuNvyuPARrxDJlw6AGAgASwOYCAASt3gA== Date: Fri, 26 Jul 2013 11:55:55 +0000 Message-ID: <05F7BCCF-F0BE-433C-BC0B-082063A29E21@checkpoint.com> References: <51E92CB7.9090108@gmail.com> <47554A2B-B80A-41B5-9866-4C3FA52F2EDB@checkpoint.com> <51F16895.4050901@gmail.com> In-Reply-To: <51F16895.4050901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.44.9] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 11:56:06 -0000 On Jul 25, 2013, at 9:04 PM, Yaron Sheffer wrote: >>> =95 Suggester not a good word. Do we have a better one? Supplicant :-) = ? >>=20 >> Supplicant is taken (thank $DEITY). Until a week before we submitted the >> draft, we called it a "shortcut starter", but we kept confusing >> "starter" with "initiator" so we changed the term. delegator? cut-short= er? >>=20 >=20 > "Manager" (half-smile)? Never mind. The Quicker Shorter Cutter >>> =95 These are not "IPv4" or "DNS" shortcuts. The IPv4 and DNS are just >>> fields in the shortcut definition, and do not make any difference to >>> the shortcut's behavior. I would suggest to have a single type of >>> shortcut, and to use a third ID-like field for the address of the >>> target of the shortcut. >=20 > You did not comment on this point. Please consider a rearrangement of the= various shortcuts. We'll consider this when we're working on -01. It's a slight change in synt= ax. >>> =95 3.4.3: the recommendation at the end of the section is strange: why >>> is it tied to certificate authentication? A peer presents its ID when >>> authenticating with a PSK, too. >>=20 >> Yes, there's something missing there. I think it was supposed to be a >> suggestion that the *certificate* have the same FQDN, similar to HTTPS. >=20 > But then again, we don't do that in IKE (though maybe we should have). In HTTPS, they match the FQDN used to look up the server with the names in = the certificate. I always expect that in IKE, the certificate will match th= e ID payload. But scanning through RFC 5996, I don't see such a requirement= anywhere. In face, according to section 3.7, the only requirements are: o is configured to use certificate authentication, o is allowed to send a CERT payload, o has matching CA trust policy governing the current negotiation, and o has at least one time-wise and usage-appropriate end-entity certificate chaining to a CA provided in the CERTREQ. From yaronf.ietf@gmail.com Fri Jul 26 22:42:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF22321F9B80 for ; Fri, 26 Jul 2013 22:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl0BJ1jCXXAB for ; Fri, 26 Jul 2013 22:42:05 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A70F721F9B60 for ; Fri, 26 Jul 2013 22:42:04 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b15so1902126eae.24 for ; Fri, 26 Jul 2013 22:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JrE+lHUrsGA8av2iIowxClYE3mlVWwppKFTBPUjANKc=; b=KWOuZugm+rTkf9RAI4reMHeA240TA3+9QjqiFzfL8/YVSR9O77Oz/QcDH4Aex+DZKz E6rih/9ART5B4FVHMlF0sjm41HhoVWpqPccN1ypw2Aje1Z54vZEltfpjBPU5Wza7QBUv 9TXjUKw2Lx0IvsOT/BbB3o/o6eCYa45iMoM51ctI0pZOZpecSN1beOPy2DLDYp9xxBFg ohWvPb7T864Jb8VjPJ8Wx3PoZiZW3uG+7fJKolLuWEhPRmcxhWXJKfiT7+QfEuAgAK9h r8VcoyQUo2xqNZ/Yxe+0zczgoqoNh7KOJbxI5LYU6Xxj3Ij3VeOwirUhPwPy91R0Onaw QgEw== X-Received: by 10.14.172.2 with SMTP id s2mr5260717eel.63.1374903719215; Fri, 26 Jul 2013 22:41:59 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id a4sm85654713eez.0.2013.07.26.22.41.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 22:41:58 -0700 (PDT) Message-ID: <51F35DA5.6080903@gmail.com> Date: Sat, 27 Jul 2013 07:41:57 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Valery Smyslov References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> In-Reply-To: <939A128A27464E3B8CA1476486DB3F78@buildpc> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 05:42:05 -0000 Hi Valery, please see below. Thanks, Yaron On 2013-07-26 08:58, Valery Smyslov wrote: > Hi Yaron, > >> - The coverage of SKF is unclear to me. Specifically, does SKF sign >> the fragment number? > > Yes. As with SK Payload the whole message, including IKE Header, > unprotected Payloads preceeding SKF Payload (if any) and SKF Payload itself > (from the begining of Generic Header to the end of Payload content padding) > is included in ICV computation. > > In description of SKF Payload the draft says: > Other fields are identical to those specified in Section 3.14 of > [RFC5996]. > > (Note, that "Other fields" includes "Integrity Checksum Data" field) > > And Section 3.14 of RFC5669 says about that field: > o Integrity Checksum Data is the cryptographic checksum of the > entire message starting with the Fixed IKE header through the Pad > Length. The checksum MUST be computed over the encrypted message. > Its length is determined by the integrity algorithm negotiated. > > If you think that this reference is insufficient, I could copy-paste > descriptions of all other fields from RFC5996. No, I would suggest to cut-and-paste. But please also add: The cryptographic processing is identical to Sec. 3.14 of RFC 5996, as well as documents updating it for particular algorithms or modes, such as RFC 5282. Also, in the second paragraph of 2.5, please change "as well as" to "similarly to the". > >> - The heuristic of using the received size to determine the fragment >> size to send is brittle. Why not optionally negotiate in the >> notification, by each side (optionally) adding its notion of the PMTU >> to the notification, and if two values are advertised, choosing the >> lower of them. One of the peers might be configured or might have >> already discovered the PMTU. > > I'm in favour of minimizing manual configuration. In general, peers > will not know PMTU, but the protocol allows them to discover it. > Note, that this doesn't preclude using some preconfigured > PMTU values. I was giving an example. People might choose configuration or discovery to obtain the information. But your text suggests that the peers should somehow share the information (e.g. because only one side can perform discovery), and I propose to make this sharing simpler and more explicit. > >> - Why at all add replay protection here? This adds complexity with >> IMHO no extra value. > > Replay protection is the feature of IKEv2 (section 2.2). Are you suggesting > to abandon it? The draft just clarifies that in case of IKE Fragmentation > all fragments will bear the same Message ID as the original message, > that was fragmented. So, receiver in this case must not drop all incoming > fragments after the first it received, treating them as replays, but > must also look at fragment number field. I re-read this part of the draft and I think it is fine. > >> - I suggest to add a Transport Considerations section. E.g. what if >> some fragments are lost? Timeouts? Seems to me the packet loss ratio >> would be higher than normal. > > OK. > > Regards, > Valery. > >> >> Thanks, >> Yaron >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From praveenys@juniper.net Sat Jul 27 06:39:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8921C21F9981 for ; Sat, 27 Jul 2013 06:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csKaS17hJjIP for ; Sat, 27 Jul 2013 06:39:09 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 717E721F9926 for ; Sat, 27 Jul 2013 06:39:08 -0700 (PDT) Received: from mail66-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 13:39:07 +0000 Received: from mail66-db9 (localhost [127.0.0.1]) by mail66-db9-R.bigfish.com (Postfix) with ESMTP id 45D81300063 for ; Sat, 27 Jul 2013 13:39:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail66-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=praveenys@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail66-db9 (localhost.localdomain [127.0.0.1]) by mail66-db9 (MessageSwitch) id 1374932345164695_2040; Sat, 27 Jul 2013 13:39:05 +0000 (UTC) Received: from DB9EHSMHS013.bigfish.com (unknown [10.174.16.225]) by mail66-db9.bigfish.com (Postfix) with ESMTP id 249A1460051 for ; Sat, 27 Jul 2013 13:39:05 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.53) by DB9EHSMHS013.bigfish.com (10.174.14.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 13:39:02 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 27 Jul 2013 06:38:59 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sat, 27 Jul 2013 06:39:00 -0700 Received: from DB8EHSOBE031.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 27 Jul 2013 06:43:15 -0700 Received: from mail79-db8-R.bigfish.com (10.174.8.241) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 13:38:57 +0000 Received: from mail79-db8 (localhost [127.0.0.1]) by mail79-db8-R.bigfish.com (Postfix) with ESMTP id 54ABD5A02EA for ; Sat, 27 Jul 2013 13:38:57 +0000 (UTC) Received: from mail79-db8 (localhost.localdomain [127.0.0.1]) by mail79-db8 (MessageSwitch) id 1374932335335510_5893; Sat, 27 Jul 2013 13:38:55 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.230]) by mail79-db8.bigfish.com (Postfix) with ESMTP id 4D3E0380046; Sat, 27 Jul 2013 13:38:55 +0000 (UTC) Received: from BLUPRD0511HT004.namprd05.prod.outlook.com (157.56.232.213) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 13:38:55 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.2.244]) by BLUPRD0511HT004.namprd05.prod.outlook.com ([10.255.135.167]) with mapi id 14.16.0329.000; Sat, 27 Jul 2013 13:38:53 +0000 From: Praveen Sathyanarayan To: Valery Smyslov , IPsecme WG Thread-Topic: [IPsec] Some comments on draft-sathyanarayan-ipsecme-advpn-00 Thread-Index: AQHOiGvdkJuZFnzBrUiQbFatT1hzH5l4FxAA Date: Sat, 27 Jul 2013 13:38:53 +0000 Message-ID: In-Reply-To: <29AADE63542F4470AEA39A9CC3E85D6A@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.255.135.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <84112DF3C7506C42B972B4CC7CB648B3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [IPsec] Some comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:39:14 -0000 Hi Valery, Thanks for the review and comments. Our response inline. -- Praveen On 7/24/13 5:45 AM, "Valery Smyslov" wrote: >Hi, > >a few comments on the draft-sathyanarayan-ipsecme-advpn-00. > >1. Why not include port along with IP address of endpoint > in shortcut notification? This will allow creating shortcuts > in some of the situations when both endpoints are behind NAT, > but at least one of them has some knowledge about the > external address and port it is reachable on (or it can > open port on FW/NAT via some protocol). Endpoint, selected > as responder, may return this information to suggester in response to > create shortcut notification and suggester will pass it > to the other endpoint in corresponding create shortcut notification. [PRAVEEN] We did explore about this just few weeks before we were submitting the draft. This is something like how STUN protocol would work. I am no NAT expert. What I understand from reading STUN protocol is that, it solves most NAT situation, for example symmetric NAT. Thus we wanted to explore if there are other solutions, that may resolve in all NAT situations. Because of time constraint, we didn't rush to include in -00 draft. But definitely this is something that we are looking for -01 draft. > >2. Draft says nothing about using of internal addresses when > creating and using shortcuts. If endpoint got internal address > via CP Payload when it created SA with GW, what should > it do when GW requests it to create shortcut? I think, > it must not request new address via shortcut IKE SA > (as it is useless in most cases) and must use the address, obtained > from suggester GW as its internal address for shortcut? [PRAVEEN] Yes. Shortcut partners must use internal address for shortcut (at it is the address suggested by suggester). But we are not sure if it covers every scenario. > >3. It seems that shorcuts must always be in tunnel mode, even in p2p case? [PRAVEEN] I am not sure about the use case where transport-mode could be useful. May be when other tunneling protocol is used like GRE. So, when Shortcut suggester sees traffic from one GRE tunnel going to another GRE tunnel, it may send SHORTCUT notification to shortcut peers, with a traffic-selector which has single IP address. Then, shortcut initiator may choose to trigger shortcut tunnel negotiation with transport mode or tunnel mode. If transport mode was chosen, as transport mode is optional in IKEv2, if shortcut responder does not agree, a tunnel mode will be used for shortcut tunnel. > >4. I agree with some of Yaron's comments, in particular: > - use "supported" Notification instead of VID > - use separate Shortcut-Response [PRAVEEN] We agree as well. We are considering above Yaron's suggestions in future revision draft. > >Regards, >Valery Smyslov. > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > > From svanru@gmail.com Sat Jul 27 10:47:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFA11E80D9 for ; Sat, 27 Jul 2013 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYcC+oTbBjhp for ; Sat, 27 Jul 2013 10:47:05 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D711E80DE for ; Sat, 27 Jul 2013 10:47:05 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id x10so3263519lbi.5 for ; Sat, 27 Jul 2013 10:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=NdpRWeyVnzyJDbXT4zd/z+MPF3V63tCNwMZAR73xozc=; b=SMRUON43gEyy5nr+iwY65Dyt5sbqNBSH7EzvzZdcScAEAXFCzho+IK9gCg+EHDqICp 7XChlr8Widdc05FP+fI8WHCrNRoUJdW2somNwjcWRb3G9Hm508Aeu8SAVoz4tJEhE5Cv l6a9zXZ2jvJY3bmqZBnu+swSjpTpniwt3GJSfA3lZVHVQ5hMCNVTDOj0pMgwsw8UABad /scTyRKb6T3HcubmWvXFr1RlOnALCvTwqs7XCqBPmrfG/W3B7QW55s7YolHt8jRfBNIg LPhX4RjHeuj+w313LlC5wWuwLmXmXFDcIQuHrhL0h608v0/52vcDO0/mVD60R4f5/gwJ ZhOw== X-Received: by 10.152.88.5 with SMTP id bc5mr23174733lab.81.1374947224371; Sat, 27 Jul 2013 10:47:04 -0700 (PDT) Received: from chichi (ppp91-77-169-254.pppoe.mtu-net.ru. [91.77.169.254]) by mx.google.com with ESMTPSA id et10sm3047609lbc.6.2013.07.27.10.47.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Jul 2013 10:47:03 -0700 (PDT) Message-ID: <670D1640477347DEAD0339894476F214@chichi> From: "Valery Smyslov" To: "Yaron Sheffer" References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> In-Reply-To: <51F35DA5.6080903@gmail.com> Date: Sat, 27 Jul 2013 21:46:54 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:47:06 -0000 > Hi Valery, > > please see below. Hi Yaron, please find my answers inline. > >> - The coverage of SKF is unclear to me. Specifically, does SKF sign > >> the fragment number? > > > > Yes. As with SK Payload the whole message, including IKE Header, > > unprotected Payloads preceeding SKF Payload (if any) and SKF Payload > > itself > > (from the begining of Generic Header to the end of Payload content > > padding) > > is included in ICV computation. > > > > In description of SKF Payload the draft says: > > Other fields are identical to those specified in Section 3.14 of > > [RFC5996]. > > > > (Note, that "Other fields" includes "Integrity Checksum Data" field) > > > > And Section 3.14 of RFC5669 says about that field: > > o Integrity Checksum Data is the cryptographic checksum of the > > entire message starting with the Fixed IKE header through the Pad > > Length. The checksum MUST be computed over the encrypted message. > > Its length is determined by the integrity algorithm negotiated. > > > > If you think that this reference is insufficient, I could copy-paste > > descriptions of all other fields from RFC5996. > > No, I would suggest to cut-and-paste. Sorry, "would" or "would not"? > But please also add: > The cryptographic processing is identical to Sec. 3.14 of RFC 5996, as > well as documents updating it for particular algorithms or modes, such as > RFC 5282. OK. > Also, in the second paragraph of 2.5, please change "as well as" to > "similarly to the". OK, thank you. > >> - The heuristic of using the received size to determine the fragment > >> size to send is brittle. Why not optionally negotiate in the > >> notification, by each side (optionally) adding its notion of the PMTU > >> to the notification, and if two values are advertised, choosing the > >> lower of them. One of the peers might be configured or might have > >> already discovered the PMTU. > > > > I'm in favour of minimizing manual configuration. In general, peers > > will not know PMTU, but the protocol allows them to discover it. > > Note, that this doesn't preclude using some preconfigured > > PMTU values. > > I was giving an example. People might choose configuration or discovery to > obtain the information. But your text suggests that the peers should > somehow share the information (e.g. because only one side can perform > discovery), and I propose to make this sharing simpler and more explicit. I understand your point. But I have some doubts whether PMTU discovery (ot PMTU configuring) is needed here at all. It is possible to just specify that all fragments must have their sizes smaller or equal than the size, that is guaranteed not to be gragmented by IP level. From my understanding for IPv6 this size is specified - 1280 bytes. What about IPv4 - as far as I know, no official low limit exists, but in real life 576 byte is often considered as this limit. If we stick to these values and get rid of any discovery or configuring, protocol will become a bit simpler. And IKE is not a bulk transfer protocol, so network efficiency could be suboptimal. I'd like to know what the others think about this. Thank you for your comments, Valery. From yaronf.ietf@gmail.com Sat Jul 27 13:58:44 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC9111E80F9 for ; Sat, 27 Jul 2013 13:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQaOnYbDpE7X for ; Sat, 27 Jul 2013 13:58:43 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3619B11E80F7 for ; Sat, 27 Jul 2013 13:58:42 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so236603eaj.34 for ; Sat, 27 Jul 2013 13:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C1Jz/TSIMc1W69rH+nBxKnMobjy+9q1gADQyUMHv4qs=; b=fhUaIONVmC8Vh1/qJt8XzRP37nlU+i9A64csmmETVGi0rRaZVmiSNsGFE7ZZq8tZac IdXdaQjqiLa/HC7ya5w2tQgKcwWYUDeJL7g1dOMnX4FF6bZLLyg2/wVqfOrYiOI9oRlL rMykIUfrPO96dZQCE3+idwX1i3fGCsJXaIRnX7vj/Wn8ghHBYNzWmXfo9epTW8My8+2Q rd/fJkvffrx4sMBndh+M5J+0q3eZGe6te2Omn/TBB2l35E8wZHC0BniSKgBpDcdAwpQx wkNtUY57X9qtsU6QQsyUF7+pm4earNIPeK/h7ma3yBAqw/eFWDi/1rNASYRGlKQ8JitM /weQ== X-Received: by 10.14.199.7 with SMTP id w7mr679800een.56.1374958722211; Sat, 27 Jul 2013 13:58:42 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id l42sm90317428eeo.14.2013.07.27.13.58.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 13:58:41 -0700 (PDT) Message-ID: <51F43480.3050000@gmail.com> Date: Sat, 27 Jul 2013 22:58:40 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Valery Smyslov References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> <670D1640477347DEAD0339894476F214@chichi> In-Reply-To: <670D1640477347DEAD0339894476F214@chichi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:58:44 -0000 Hi Valery, "would not". And I agree we should get additional inputs about useful fragment lengths. Thanks, Yaron On 2013-07-27 19:46, Valery Smyslov wrote: >> Hi Valery, >> >> please see below. > > Hi Yaron, > > please find my answers inline. > >> >> - The coverage of SKF is unclear to me. Specifically, does SKF sign >> >> the fragment number? >> > >> > Yes. As with SK Payload the whole message, including IKE Header, >> > unprotected Payloads preceeding SKF Payload (if any) and SKF Payload >> > itself >> > (from the begining of Generic Header to the end of Payload content > >> padding) >> > is included in ICV computation. >> > >> > In description of SKF Payload the draft says: >> > Other fields are identical to those specified in Section 3.14 of >> > [RFC5996]. >> > >> > (Note, that "Other fields" includes "Integrity Checksum Data" field) >> > >> > And Section 3.14 of RFC5669 says about that field: >> > o Integrity Checksum Data is the cryptographic checksum of the >> > entire message starting with the Fixed IKE header through the Pad >> > Length. The checksum MUST be computed over the encrypted >> message. >> > Its length is determined by the integrity algorithm negotiated. >> > >> > If you think that this reference is insufficient, I could copy-paste >> > descriptions of all other fields from RFC5996. >> >> No, I would suggest to cut-and-paste. > > Sorry, "would" or "would not"? > >> But please also add: >> The cryptographic processing is identical to Sec. 3.14 of RFC 5996, as >> well as documents updating it for particular algorithms or modes, such >> as RFC 5282. > > OK. > >> Also, in the second paragraph of 2.5, please change "as well as" to >> "similarly to the". > > OK, thank you. > >> >> - The heuristic of using the received size to determine the fragment >> >> size to send is brittle. Why not optionally negotiate in the >> >> notification, by each side (optionally) adding its notion of the PMTU >> >> to the notification, and if two values are advertised, choosing the >> >> lower of them. One of the peers might be configured or might have >> >> already discovered the PMTU. >> > >> > I'm in favour of minimizing manual configuration. In general, peers >> > will not know PMTU, but the protocol allows them to discover it. >> > Note, that this doesn't preclude using some preconfigured >> > PMTU values. >> >> I was giving an example. People might choose configuration or >> discovery to obtain the information. But your text suggests that the >> peers should somehow share the information (e.g. because only one side >> can perform discovery), and I propose to make this sharing simpler and >> more explicit. > > I understand your point. > > But I have some doubts whether PMTU discovery (ot PMTU configuring) > is needed here at all. It is possible to just specify that all fragments > must have their sizes smaller or equal than the size, that is guaranteed > not to be gragmented by IP level. From my understanding for IPv6 > this size is specified - 1280 bytes. What about IPv4 - as far as I know, > no official low limit exists, but in real life 576 byte is often considered > as this limit. If we stick to these values and get rid of any discovery > or configuring, protocol will become a bit simpler. And IKE is not > a bulk transfer protocol, so network efficiency could be suboptimal. > I'd like to know what the others think about this. > > Thank you for your comments, > Valery. > > From pwouters@redhat.com Mon Jul 29 10:14:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D14D21F9BC4 for ; Mon, 29 Jul 2013 10:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbGZm2AkSnzw for ; Mon, 29 Jul 2013 10:14:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3AE21F9546 for ; Mon, 29 Jul 2013 10:10:41 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6THAVFK025461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Jul 2013 13:10:31 -0400 Received: from thinkpad.nohats.ca (vpn-60-149.rdu2.redhat.com [10.10.60.149]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6THAUYn024655 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Jul 2013 13:10:31 -0400 Message-ID: <51F6A205.805@redhat.com> Date: Mon, 29 Jul 2013 19:10:29 +0200 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> <670D1640477347DEAD0339894476F214@chichi> In-Reply-To: <670D1640477347DEAD0339894476F214@chichi> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:14:49 -0000 On 07/27/2013 07:46 PM, Valery Smyslov wrote: > But I have some doubts whether PMTU discovery (ot PMTU configuring) > is needed here at all. It is possible to just specify that all fragments > must have their sizes smaller or equal than the size, that is guaranteed > not to be gragmented by IP level. From my understanding for IPv6 > this size is specified - 1280 bytes. What about IPv4 - as far as I know, > no official low limit exists, but in real life 576 byte is often considered > as this limit. If we stick to these values and get rid of any discovery > or configuring, protocol will become a bit simpler. I would strongly prefer that over any discovery/negotiation. It also matches IKEv1 behaviour I see in the wild From mcr@sandelman.ca Mon Jul 29 11:58:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6721F9F31 for ; Mon, 29 Jul 2013 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoOsS8uM8EIy for ; Mon, 29 Jul 2013 11:58:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA1921F9EF2 for ; Mon, 29 Jul 2013 11:58:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 439A620267; Mon, 29 Jul 2013 16:04:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B719063A5E; Mon, 29 Jul 2013 14:56:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9CC47636AD; Mon, 29 Jul 2013 14:56:49 -0400 (EDT) From: Michael Richardson To: oIPsecme WG , yamaya@fnsc.co.jp X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: ueki@fnsc.co.jp, murai@fnsc.co.jp, t.ohya@rdc.west.ntt.co.jp Subject: [IPsec] questions about ipsecme-mpsa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:58:23 -0000 --=-=-= Thank your this draft. As I understand MPSA, the gateway simply generates incoming/outgoing SA pairs. I get the impression that the same information is sent to each CPE? What is this multi-point SA mentioned? Assuming that one wanted to do this, I don't see how CPE_A knows to send C's traffic to CPE_C. Where are the tunnel outer information configured? It seems to me at least some traffic selectors are needed. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfa67oqHRg3pndX9AQJwMwP+M0hLxkkCYnqCwkjshxRCCdiphp1mlBCR A9BxGofvTen32u+sKzHjkiycq/heGK9SHo5UsmfQWbAMiD0Sr+aunDrES96eJ3YS wCXGpfbuZe0mwMN9N5JbD1Jl6Tp4k7PiKdvFHK+d7XALsVqap7rKnFG+bfy0RHXR Itsa2PwfHL4= =L3Ri -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Jul 29 12:22:28 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79111E811F for ; Mon, 29 Jul 2013 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdr5wS+bV1Dd for ; Mon, 29 Jul 2013 12:21:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 378E621F862B for ; Mon, 29 Jul 2013 12:19:26 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5790C20251; Mon, 29 Jul 2013 16:25:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E69A963A5E; Mon, 29 Jul 2013 15:17:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CCD32636AD; Mon, 29 Jul 2013 15:17:58 -0400 (EDT) From: Michael Richardson To: oIPsecme WG X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: draft-mao-ipsecme-ad-vpn-protocol@tools.ietf.org Subject: [IPsec] comments on mao-ipsecme-ad-vpn X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:22:28 -0000 --=-=-= Thank you for this draft. I found your writing very clear and direct. Reading the beginning of the draft, I want to suggest a change in terminology. Rather than "Private IP Address", I would to suggest that either the terms: "Protected IP address" or "Inner IP address" or "Intranet IP address" wow, punting the transfer of IP addresses to a routing protocol seems a big punt.... I think that it needs to be specified in the ADVPN protocol, not left up to implementations. I wonder if some of the message types in the ADVPN fixed header, such as the keepalive items, can not be satisfied with existing IKEv2 message types? I also wonder if your messages take into account NAT traversal? Couldn't TSx payloads be used rather than the TrafficFlowPayload? I think that once an ADC spoke learns of the traffic flow, that it will initiate to the appropriate other spoke and do full IKEv2, including authentication? I think that I have missed where the ADC spoke is told by the ADC client where it is supposed to redirect to. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfa/5IqHRg3pndX9AQJt9AQAlRqCXGkWJqEMT+VNpV1efdiOCR1z/g5a d7pLZHnsyb3yTgBs3y8ww6BnNuA5dWT/eur/+unN4dAC6fJi5EOhx4Ht2cQOZCIr M1sBDF4Sf6MsP4OIfVpLihUFxpoIUNX5ukCZA55ZVchpnOyQTXnBjU1/6iuxYa7S N6IYhJry07M= =HmuJ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Jul 29 12:44:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31E721F944C for ; Mon, 29 Jul 2013 12:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9RwK7o2saRY for ; Mon, 29 Jul 2013 12:44:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3911E812E for ; Mon, 29 Jul 2013 12:44:10 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15BD12018F for ; Mon, 29 Jul 2013 16:50:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A617F63A5E; Mon, 29 Jul 2013 15:42:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9295A636AD for ; Mon, 29 Jul 2013 15:42:46 -0400 (EDT) From: Michael Richardson To: oIPsecme WG X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [IPsec] comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:44:24 -0000 --=-=-= This is a really minor comment: you reserve 3-39999 as unassigned and 40K+ as private use. Why not make that boundary 49152, nice binary multiple. I also wonder if having four Shortcut Notify types might just be simpler to implement, rather than having another layer of type codes. I'm also not clear why a Notify: it seems like it ought to be an entirely normal payload type, cousin to Proposal. One might even argue that this is a new kind of *Proposal*, the "shortcut proposal". My goal here is to reuse as much as the current decoding and validation code as possible. It seems that port numbers belong in the Shortcut Types. I think that an IPv4 shortcut is one that traverse IPv4, and it could have anything inside it. (IPv4, IPv6, maybe even transport mode SAs) I'd rather see IDi/TSi embedded in this using the normal payload structure of IKEv2. Do the IDi/r and TSi/r payloads include their normal 4-byte header? The IDi description says no generic header.... the TSi description should be moved up to the TSi description. Gee, I'd sure rather we weren't encouraging more PSK use. I'm finding the IDx payloads interesting: it is interesting that the identity is being managed here. That sure gets around a whole host of issues with letting the gateways use their own identities, which might be tied up with certificates and other stuff. I think that some recommendation should made (and some MUST implement) about ID types here. I like Appendix A.2. I'm glad you took the suggestion of having the shortcut be learned incrementally. Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are in fact on the same subnet, etc. is there any way for it to tell them to create a "bypass" between them? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfbFs4qHRg3pndX9AQLFJQQAr3zIefvBBksR9ohFDXRL+C8M87Fc/jP9 9+aUl68NHbtyj+1OFJlnz7B1ZI4+TfDToPDozHZYaeJsAxCKKw8tbdgU4HLY+6qS LUAkzlqYYFip4/c0ktqM/R5sv1meBV/ATIO1ZljEIutru1xt/1fx6A9zs0xOxRVG lVFtf3XRTMM= =6kPk -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Jul 29 12:58:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9711E811E for ; Mon, 29 Jul 2013 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT+mVTOu-Gfz for ; Mon, 29 Jul 2013 12:57:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id DDB1C11E8114 for ; Mon, 29 Jul 2013 12:57:56 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5302E2018F for ; Mon, 29 Jul 2013 17:03:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D1E8263A5E; Mon, 29 Jul 2013 15:56:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C3A06636AD for ; Mon, 29 Jul 2013 15:56:32 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <51F6A205.805@redhat.com> References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> <670D1640477347DEAD0339894476F214@chichi> <51F6A205.805@redhat.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:58:07 -0000 --=-=-= Please note that fragmentation below UDP is unpopular among IPv6. http://www.ietf.org/proceedings/87/slides/slides-87-6man-2.pdf -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfbI64qHRg3pndX9AQKA2QP/VdvkIftqCrEBiHX0y2iAx4Ays6lTSjKc F3FfvfudQ5ZPzLqsCtVWTGbylNKnCr/PjrXkVSfw838VkuTwfZE646LhngiTf59h ZAe9VNbgGH1FQ7JYUtDGpnYyFM2ZDGavlL2EKCjsdbX0MQqh6Si1OsNTRxbPmWkC SoNSk6y6Ukc= =ZLgX -----END PGP SIGNATURE----- --=-=-=-- From svanru@gmail.com Mon Jul 29 23:07:42 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A817611E81BE for ; Mon, 29 Jul 2013 23:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBmtOtjFfTG8 for ; Mon, 29 Jul 2013 23:07:35 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E4BDC11E81BB for ; Mon, 29 Jul 2013 23:07:34 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so536287eek.1 for ; Mon, 29 Jul 2013 23:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :importance:x-mailer:x-mimeole; bh=UT+x3UF5cm/193WOkVSuxpNYAut3h+nkuWTmP53uvqU=; b=bjDOiaw87CwptA5C8dBrkGTf/0bpegYeE361kCn31cuQClRoivtMPqIv+9mLzl9arM LJufIdffYTk5nbKWDofNi7qrPpvyH3B9BVLvagFGgJimO6JI2rs8cbCVTStqnC5Dcegt Pnc9qaO4/JiGITFJEHW7L3+xJWuooIRVMYNyvKaGM2r2ermwjNmUEBlW7tJu2NE4aP1h 0tMWGjNVt35SYOOFvuNRi3ONZ4yyJtzEN2ci3ZOpPByOIAnoZA5+0DnN+xdOCdNxav7/ 8qFR1NJ8ropY2ZZsGc9QJasM9aFlXvVEcoeU2Bk/1tTPOy03jG/hyoxLzXVQqk9WkDia BqvQ== X-Received: by 10.15.23.194 with SMTP id h42mr61811177eeu.123.1375164454011; Mon, 29 Jul 2013 23:07:34 -0700 (PDT) Received: from notebook ([81.92.21.2]) by mx.google.com with ESMTPSA id ci50sm107787990eeb.12.2013.07.29.23.07.32 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 29 Jul 2013 23:07:33 -0700 (PDT) Message-ID: <68D90CD35E7B4F64A5B47B73FF7DAC42@notebook> From: "Valery Smyslov" To: "Michael Richardson" , References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com><51F1AAD9.2070509@gmail.com><939A128A27464E3B8CA1476486DB3F78@buildpc><51F35DA5.6080903@gmail.com><670D1640477347DEAD0339894476F214@chichi> <51F6A205.805@redhat.com> <27323.1375127792@sandelman.ca> In-Reply-To: <27323.1375127792@sandelman.ca> Date: Tue, 30 Jul 2013 08:07:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3508.205 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3508.205 Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:07:42 -0000 Hi Michael, thanks for reference. IP fragmentation is exactly the thing we are trying to avoid with this solution. So, we are in line with IPv6 folks. Regards, Valery Smyslov. -----Original Message----- From: Michael Richardson Sent: Monday, July 29, 2013 9:56 PM To: ipsec@ietf.org Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 > Please note that fragmentation below UDP is unpopular among IPv6. > http://www.ietf.org/proceedings/87/slides/slides-87-6man-2.pdf > > > _______________________________________________ > IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Mon Jul 29 23:14:31 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AEC21F9BD3 for ; Mon, 29 Jul 2013 23:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7muAYVv6SDC for ; Mon, 29 Jul 2013 23:14:30 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 95F3B21F9BC9 for ; Mon, 29 Jul 2013 23:14:30 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so444768eek.22 for ; Mon, 29 Jul 2013 23:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VFneC/UnkQd/9iA5SBZ/sZk0rRXOHRET3Pijda3oAjg=; b=HH9BHANpLDh0snkYDezSwg75IsFOx4Cni7EvWJildzD5uUgpt34hkqXJ9ljncWL9v6 B/VwNmyYpGe5JiFoIAIh0gvDbaO9Dg01ERg9I9QHHYbgmQfmcwROMDejHDmLysy9lgYR +tEbY/4Wbm7sxYa0ia6UVuObdylPAZr13PogsOFJ48BlLrcjhZ8MMUiFPAjim/C+rHFi VzXRwZI1+qFA9rXlfIJocOxnV6fC47xbSskQPmANvXrpP7mu2nnOWNX1ohJMMm+BsQi+ IIzEywRKklTFSrF9xQSRhZx2C+H+3xGe7Ai0wWOsHgLA8rIz1KT4f68lHDsr53xaglvc Oz/Q== X-Received: by 10.14.204.194 with SMTP id h42mr11893364eeo.47.1375164869688; Mon, 29 Jul 2013 23:14:29 -0700 (PDT) Received: from [192.168.1.133] (g225109105.adsl.alicedsl.de. [92.225.109.105]) by mx.google.com with ESMTPSA id c3sm107862608eev.3.2013.07.29.23.14.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 23:14:28 -0700 (PDT) Message-ID: <51F759C3.1010809@gmail.com> Date: Tue, 30 Jul 2013 08:14:27 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Wouters References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> <670D1640477347DEAD0339894476F214@chichi> <51F6A205.805@redhat.com> In-Reply-To: <51F6A205.805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:14:31 -0000 Unless *everybody* thinks that a fixed number is the right way to go, there will be people doing PMTU discovery, configuration and hardcoded length. So again we would like both peers to advertise the value they're using, so that each can *choose* to use the lower value, or use the other peer's value. Thanks, Yaron On 2013-07-29 19:10, Paul Wouters wrote: > On 07/27/2013 07:46 PM, Valery Smyslov wrote: > >> But I have some doubts whether PMTU discovery (ot PMTU configuring) >> is needed here at all. It is possible to just specify that all fragments >> must have their sizes smaller or equal than the size, that is guaranteed >> not to be gragmented by IP level. From my understanding for IPv6 >> this size is specified - 1280 bytes. What about IPv4 - as far as I know, >> no official low limit exists, but in real life 576 byte is often considered >> as this limit. If we stick to these values and get rid of any discovery >> or configuring, protocol will become a bit simpler. > > I would strongly prefer that over any discovery/negotiation. > > It also matches IKEv1 behaviour I see in the wild > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From pwouters@redhat.com Mon Jul 29 23:40:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5F921F9EA2 for ; Mon, 29 Jul 2013 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asoveFt9rB2U for ; Mon, 29 Jul 2013 23:40:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADC6221F93D4 for ; Mon, 29 Jul 2013 23:40:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3c47Rc2My3z21n; Tue, 30 Jul 2013 02:39:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id uoZ6PkKXpVzJ; Tue, 30 Jul 2013 02:39:53 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 30 Jul 2013 02:39:53 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 34B2080EC9; Tue, 30 Jul 2013 02:39:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 24D8380E8F; Tue, 30 Jul 2013 02:39:54 -0400 (EDT) Date: Tue, 30 Jul 2013 02:39:54 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: <51F759C3.1010809@gmail.com> Message-ID: References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> <939A128A27464E3B8CA1476486DB3F78@buildpc> <51F35DA5.6080903@gmail.com> <670D1640477347DEAD0339894476F214@chichi> <51F6A205.805@redhat.com> <51F759C3.1010809@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:40:07 -0000 On Tue, 30 Jul 2013, Yaron Sheffer wrote: > Unless *everybody* thinks that a fixed number is the right way to go, there > will be people doing PMTU discovery, configuration and hardcoded length. So > again we would like both peers to advertise the value they're using, so that > each can *choose* to use the lower value, or use the other peer's value. What's the gain? At 576 bytes you will need what, 3 to 5 packets? When negotiating an optimal mtu, you will need what? 2 packets? Does it really matter whether you burst out 2 or 5 packets within the same ms? Your pmtu might not be the peer's pmtu, as these are not nececssarilly symmetric. Why take the risk? Paul > Thanks, > Yaron > > On 2013-07-29 19:10, Paul Wouters wrote: >> On 07/27/2013 07:46 PM, Valery Smyslov wrote: >> >>> But I have some doubts whether PMTU discovery (ot PMTU configuring) >>> is needed here at all. It is possible to just specify that all fragments >>> must have their sizes smaller or equal than the size, that is guaranteed >>> not to be gragmented by IP level. From my understanding for IPv6 >>> this size is specified - 1280 bytes. What about IPv4 - as far as I know, >>> no official low limit exists, but in real life 576 byte is often >>> considered >>> as this limit. If we stick to these values and get rid of any discovery >>> or configuring, protocol will become a bit simpler. >> >> I would strongly prefer that over any discovery/negotiation. >> >> It also matches IKEv1 behaviour I see in the wild >> _______________________________________________ >> 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 ynir@checkpoint.com Mon Jul 29 23:57:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA221E8053 for ; Mon, 29 Jul 2013 23:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9w6mYubwUeu for ; Mon, 29 Jul 2013 23:57:04 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AB29921E80C1 for ; Mon, 29 Jul 2013 23:57:02 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6U6uiNY000694; Tue, 30 Jul 2013 09:56:44 +0300 X-CheckPoint: {51F763AC-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 09:56:44 +0300 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] comments on draft-sathyanarayan-ipsecme-advpn-00 Thread-Index: AQHOjJQNbNDu+kuxT0Cxz3rm8yKhn5l8mHEA Date: Tue, 30 Jul 2013 06:56:43 +0000 Message-ID: References: <24914.1375126966@sandelman.ca> In-Reply-To: <24914.1375126966@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.215] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11b24bbc9efd136ed6fcf3a6afcefaf1a330415197 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [IPsec] comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:57:13 -0000 Hi MCR On Jul 29, 2013, at 9:42 PM, Michael Richardson wro= te: >=20 > This is a really minor comment: you reserve 3-39999 as unassigned > and 40K+ as private use. Why not make that boundary 49152, nice binary > multiple. Yes, that's more conventional. But why do we prefer the convenience of mach= ines (who don't really care one way or the other) to the convenience of peo= ple, who work in decimal? > I also wonder if having four Shortcut Notify types might just be simpler = to > implement, rather than having another layer of type codes. > I'm also not clear why a Notify: it seems like it ought to be an entirely > normal payload type, cousin to Proposal. > One might even argue that this is a new kind of *Proposal*, the "shortcut > proposal". My goal here is to reuse as much as the current decoding and > validation code as possible. Yaron proposed that we replace at least the three types of shortcut into on= e, and add an ID payload (IDs with s for "shortcut"?) that describes the pe= er and might contain an IP address or DNS name. Either way, it's kind of we= ird to have regular payloads inside a Notify payload, or even a new type of= payload. Maybe the best path would be to have a new exchange type, that co= ntains payloads (as messages tend to do). Of course in that case we can't o= mit the generic header. > It seems that port numbers belong in the Shortcut Types. Sorry, I don't get that. > I think that an IPv4 shortcut is one that traverse IPv4, and it could hav= e > anything inside it. (IPv4, IPv6, maybe even transport mode SAs) > I'd rather see IDi/TSi embedded in this using the normal payload structur= e of > IKEv2. >=20 > Do the IDi/r and TSi/r payloads include their normal 4-byte header? > The IDi description says no generic header.... the TSi description should > be moved up to the TSi description. All of them omit the generic header. > Gee, I'd sure rather we weren't encouraging more PSK use. PSKs are great! The only problem with using PSKs is that people configure = short, memorable ones. In this specification, the suggester generates reall= y, really secure PSKs with $BIG_NUMBER bits generated by a $YOUR_FAVORITE_G= OVERNMENT_AGENCY-approved PRNG. Isn't this better than trusting some CA?=20 > I'm finding the IDx payloads interesting: it is interesting that the iden= tity > is being managed here. That sure gets around a whole host of issues with > letting the gateways use their own identities, which might be tied up wit= h > certificates and other stuff. I think that some recommendation should m= ade > (and some MUST implement) about ID types here. Since some implementations are going to use certificates for shortcuts, I g= uess we should have at least the ID_DER_ASN1_DN type, maybe also the ID_FQD= N and ID_IPvX_ADDR address. ID_KEY_ID is good for PSK, but then maybe we wa= nt to use ID_RFC822_ADDR for users. Aaargh. > I like Appendix A.2. I'm glad you took the suggestion of having the short= cut > be learned incrementally. >=20 > Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are i= n > fact on the same subnet, etc. is there any way for it to tell them to cre= ate > a "bypass" between them? Currently not. But is that a good idea? They might be on the same subnet (t= hink IETF network), but that network may not be trusted (hey, all my compan= y's competitors are on this network). We do plan to have something like a bypass shortcut in the next iteration, = but that is for cases where the center gateway forwards a particular slice = of traffic to the Internet, so the spoke gateway might as well forward to t= he Internet all by itself. There should be some consideration given to NATs= (like if the spoke was protecting RFC-1918 addresses, and the center gatew= ay was doing the NAT before sending them to the Internet) Yoav From mcr@sandelman.ca Tue Jul 30 01:55:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA02011E81C3 for ; Tue, 30 Jul 2013 01:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvyxcW78KDkc for ; Tue, 30 Jul 2013 01:55:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0882621F9C6C for ; Tue, 30 Jul 2013 01:53:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 806BD2017B; Tue, 30 Jul 2013 05:59:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E00B963A7C; Tue, 30 Jul 2013 04:52:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CEF6E636AD; Tue, 30 Jul 2013 04:52:11 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <24914.1375126966@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: " WG" Subject: Re: [IPsec] comments on draft-sathyanarayan-ipsecme-advpn-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:55:17 -0000 --=-=-= Yoav Nir wrote: >> I also wonder if having four Shortcut Notify types might just be simpler to >> implement, rather than having another layer of type codes. >> I'm also not clear why a Notify: it seems like it ought to be an entirely >> normal payload type, cousin to Proposal. >> One might even argue that this is a new kind of *Proposal*, the "shortcut >> proposal". My goal here is to reuse as much as the current decoding and >> validation code as possible. > Yaron proposed that we replace at least the three types of shortcut > into one, and add an ID payload (IDs with s for "shortcut"?) that > describes the peer and might contain an IP address or DNS name. Either > way, it's kind of weird to have regular payloads inside a Notify > payload, or even a new type of payload. Maybe the best path would be to > have a new exchange type, that contains payloads (as messages tend to > do). Of course in that case we can't omit the generic header. I am in favour of a new exchange type then. >> It seems that port numbers belong in the Shortcut Types. > Sorry, I don't get that. I was assuming that we would need port numbers in order to support spokes behind NAT. Not all NATs will support that, but some will. > All of them omit the generic header. >> Gee, I'd sure rather we weren't encouraging more PSK use. > PSKs are great! The only problem with using PSKs is that people > configure short, memorable ones. In this specification, the suggester > generates really, really secure PSKs with $BIG_NUMBER bits generated by > a $YOUR_FAVORITE_GOVERNMENT_AGENCY-approved PRNG. Isn't this better > than trusting some CA? I guess.... >> I'm finding the IDx payloads interesting: it is interesting that the identity >> is being managed here. That sure gets around a whole host of issues with >> letting the gateways use their own identities, which might be tied up with >> certificates and other stuff. I think that some recommendation should made >> (and some MUST implement) about ID types here. > Since some implementations are going to use certificates for shortcuts, > I guess we should have at least the ID_DER_ASN1_DN type, maybe also the > ID_FQDN and ID_IPvX_ADDR address. ID_KEY_ID is good for PSK, but then > maybe we want to use ID_RFC822_ADDR for users. Aaargh. Can the IDx be omitted? >> Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are in >> fact on the same subnet, etc. is there any way for it to tell them to create >> a "bypass" between them? > Currently not. But is that a good idea? They might be on the same > subnet (think IETF network), but that network may not be trusted (hey, > all my company's competitors are on this network). The spoke gets to decline if it thinks it is in an unsafe place. > We do plan to have something like a bypass shortcut in the next > iteration, but that is for cases where the center gateway forwards a > particular slice of traffic to the Internet, so the spoke gateway might > as well forward to the Internet all by itself. There should be some > consideration given to NATs (like if the spoke was protecting RFC-1918 > addresses, and the center gateway was doing the NAT before sending them > to the Internet) good. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfd+uYqHRg3pndX9AQI8qgP/RHjgxdViJ33yMwSt44QavcHqK/WGlII8 JGmPsJGOWHxv5Sd77LB7LOjLeiKGMq6UI2wGgbRe7CoUaSiy5fmuydFZJqVE9DNW i7BDDZnTQnyNwGCqvLrL0l47X46Z3t4iQqh5hNGO/2yO7c+sFHiPYrV03RCRJPwr BUxxJIkhIuI= =5tnX -----END PGP SIGNATURE----- --=-=-=-- From pwouters@redhat.com Tue Jul 30 06:50:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE011E81F4 for ; Tue, 30 Jul 2013 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldfwI7Suhjtn for ; Tue, 30 Jul 2013 06:50:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4511E81E2 for ; Tue, 30 Jul 2013 06:50:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3c4Jzs3VBsz5Sh for ; Tue, 30 Jul 2013 09:50:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 59ziGBrrbtom for ; Tue, 30 Jul 2013 09:49:59 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Tue, 30 Jul 2013 09:49:59 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id BF6D480EC9; Tue, 30 Jul 2013 09:49:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AF97880E8F for ; Tue, 30 Jul 2013 09:49:58 -0400 (EDT) Date: Tue, 30 Jul 2013 09:49:58 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: IPsecme WG In-Reply-To: <51F1AAD9.2070509@gmail.com> Message-ID: References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [IPsec] DOS protection and draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:50:21 -0000 I still don't understand what the DOS protection actually accomplishes. I think it actually makes the problem worse. If the attacker is on-path, it can just withhold the packet. If the attack is not on-path he either cannot see your packets, which means the cookies/SPI numbers protect the exchange (whole packets and fragments), or they can see your packets. So let's assume they can see your packets. The initiator sends a packet with their cookie and the responder cookie set to 0. The attacker responds immediately with 1000 spoofed packets with different responder cookies. The initiator now has 1001 potentially valid responder states. Is it going to send 1001 packets and keep track of these? And all of this happens before fragmentation can even kick in, because we need a valid icookie/rcookie to identify them (with or without some authentication). If you do keep state, good. You send out 1001 ike packets (if this is 3g or wifi, it's probably going to fail) Let's say you can actually proceed at this point. You are further into the exchange, and now you are getting a bunch of fragments. Now the attacker can simply sent you bogus fragments with the real icookies/rcookies and apart from receiving this network DOS, your CPU will be under a DOS because it has to do crypto before it can discard all these packets. Or the attacker can use other zombies to send a motherload of fragments to the other endpoint. As teh attacker can just start a "new" exchange, they can keep sending your fragments to keep your CPU busy. Now look at the very simple defacto IKEv1 fragmentation, which is basically and IKEv1 header (with icookie/rcookie) followed by a single payload: * 1 2 3 * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! Next Payload ! RESERVED ! Payload Length ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! Fragment_ID ! Fragment_num ! Flags ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! ! * ~ Fragment Data ~ * ! ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The only supported flag is "last fragment", when you received the fragment containing that, you can try and assemble the packet. The Fragment_ID is unneccessary (and in practice all implementations I've seen hardcode it to 1) and we should leave it out if we specify this for IKEv2, unless we need to support multiple exchanges in flight for the same SA. I'm still not convinced the extra complexity solves any real practical problem. Could someone try to convince me again why we need to cryptographically protect a fragment of cryptographically protected information? Paul From kivinen@iki.fi Tue Jul 30 07:28:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C30621E810C for ; Tue, 30 Jul 2013 07:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yiijq8CBwjL for ; Tue, 30 Jul 2013 07:28:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4645111E81FB for ; Tue, 30 Jul 2013 07:28:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6UERIbD012731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jul 2013 17:27:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6UERHsr005897; Tue, 30 Jul 2013 17:27:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20983.52549.139234.934084@fireball.kivinen.iki.fi> Date: Tue, 30 Jul 2013 17:27:17 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com> <51F1AAD9.2070509@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 23 min Cc: IPsecme WG Subject: [IPsec] DOS protection and draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:28:23 -0000 Paul Wouters writes: > The initiator sends a packet with their cookie and the responder cookie > set to 0. The attacker responds immediately with 1000 spoofed packets > with different responder cookies. The initiator now has 1001 potentially > valid responder states. Is it going to send 1001 packets and keep track > of these? If implementation really wants to make sure it is protected against DoS attacks it is allowed to do that. See section 2.4 in RFC 5996 saying: ---------------------------------------------------------------------- There is a DoS attack on the initiator of an IKE SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid. ---------------------------------------------------------------------- Note, that this does not need cookies to protect against this attack. Cookies protect the responder, not initiator. I assume you actually mean SPI's not cookies in your text. > And all of this happens before fragmentation can even kick in, > because we need a valid icookie/rcookie to identify them (with or > without some authentication). If you do keep state, good. You send out > 1001 ike packets (if this is 3g or wifi, it's probably going to fail) If attacker tries hard enough he can make the connections fail. The difference is that with non-authenticated fragmentation packets he does not need to send 1000 packets for each packet initiator sends. He needs to send one packet for each full message initiator sends, i.e. if initiator fragments IKE_AUTH packet to 10 pieces each of them 500 bytes (with total of 5 kB packet), the attacker needs to send just one 40 byte packet to cause the whole 5 kB to be trashed. If attacker is flooding packets to network at fast rate, it is easy to find it, if the attacker sends one packet every now and then it is much harder to detect. > Let's say you can actually proceed at this point. You are further into the > exchange, and now you are getting a bunch of fragments. Now the attacker > can simply sent you bogus fragments with the real icookies/rcookies and > apart from receiving this network DOS, your CPU will be under a DOS > because it has to do crypto before it can discard all these packets. Or > the attacker can use other zombies to send a motherload of fragments to > the other endpoint. As teh attacker can just start a "new" exchange, > they can keep sending your fragments to keep your CPU busy. Again that is different attack. Sending so much packets that destination is overloaded when decrypting the traffic is again attack that will require so much bandwidth that it is easy to see, and it will be costly for the attacker too. The question here is not whether attacker can cause DoS, the question is can we make it so that attacker has at least same cost or even higher cost to do the attack. This is called amplification factor, and thats why we try to design protocols so that there is no easy way to trigger big expensive operations with one small packet. In this case we do not want to allow the attacker to send one small packet that will cause receiver to discard much more data it already have. > I'm still not convinced the extra complexity solves any real practical > problem. Could someone try to convince me again why we need to > cryptographically protect a fragment of cryptographically protected > information? IKEv2 is tried to make to be much more robust against DoS attacks than IKEv1. In IKEv1 that design might have been acceptable, but as we can do things better and protect against that kind of attacks in IKEv2, I suggest we do it. I do not really think it makes implementation that much harder. It is Encode and Encrypt and MAC packet Split in pieces For each piece Send piece out vs Split in pices For each piece Encode and Encrypt and MAC piece Send piece out On the receiving end it will be: Receive packet Add it to reassembly queue (including all random packets attacker sends) If all fragments received Reassemble packet Verify MAC, decrypt and decode vs Recieve packet Verify MAC, if wrong drop If MAC verification succeeds, add to reassembly queue If all fragments received Reassemble packet Decrypt and decode (Decryption can also happen earlier, depending on the implementation, i.e. the reassembly queue can actually have decrypted pieces especially in case AEAD ciphers are used). -- kivinen@iki.fi From kivinen@iki.fi Tue Jul 30 07:35:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA2121F8BCE for ; Tue, 30 Jul 2013 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnRZPHEZxBS7 for ; Tue, 30 Jul 2013 07:34:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58F21F9D45 for ; Tue, 30 Jul 2013 07:34:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6UEYYWE017002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 Jul 2013 17:34:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6UEYYfA024880; Tue, 30 Jul 2013 17:34:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20983.52986.355750.805854@fireball.kivinen.iki.fi> Date: Tue, 30 Jul 2013 17:34:34 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 3 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:35:01 -0000 I posted a new version of this dropped out WG draft (and draft submission didn't even complain about the fact that there is replaces notify for this draft). ---------------------------------------------------------------------- A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-04.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-oob-pubkey Revision: 04 Title: More Raw Public Keys for IKEv2 Creation date: 2013-07-30 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-oob-pubkey-04.txt Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey Htmlized: http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-oob-pubkey-04 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2 and obsoletes the old raw RSA key format. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- kivinen@iki.fi From yamaya@fnsc.co.jp Tue Jul 30 09:17:10 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7070721F9E77 for ; Tue, 30 Jul 2013 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho55qssrMiYx for ; Tue, 30 Jul 2013 09:17:05 -0700 (PDT) Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2A21F9E68 for ; Tue, 30 Jul 2013 09:17:05 -0700 (PDT) Received: from ([192.52.120.237]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.1576821; Wed, 31 Jul 2013 01:16:59 +0900 Message-ID: <51F7E6FD.8030204@fnsc.co.jp> Date: Wed, 31 Jul 2013 01:17:01 +0900 From: yamaya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <17835.1375124209@sandelman.ca> In-Reply-To: <17835.1375124209@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] questions about ipsecme-mpsa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:17:10 -0000 Thanks for your comment. (2013/07/30 3:56), Michael Richardson wrote: > > Thank your this draft. > > As I understand MPSA, the gateway simply generates incoming/outgoing SA > pairs. I get the impression that the same information is sent to each > CPE? Yes, the gateway sends the same information to CPEs, so that each CPE shares a single SA. > > What is this multi-point SA mentioned? > Assuming that one wanted to do this, I don't see how CPE_A knows to send C's > traffic to CPE_C. Where are the tunnel outer information configured? CPE_A knows that information by another protocol, such as BGP, not by MPSA. For example, using BGP with RFC5512 and 5566, CPE_A learns prefixes and tunnel end points, and knows which packets will be tunnled in MPSA from the prefixes and to which addresses thet packets will be sent. CPE_A encapsulates a packet with MPSA information, but CPE_A knows tunnel outer information and etc from BGP. I think that other protocols can be used, LISP, etc., not only BGP. -- Arifumi Yamaya > > It seems to me at least some traffic selectors are needed. > > > -- > Michael Richardson , Sandelman Software Works > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From svanru@gmail.com Tue Jul 30 23:39:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7764521F9AA4 for ; Tue, 30 Jul 2013 23:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mle0UWMXjWVt for ; Tue, 30 Jul 2013 23:39:42 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2F52321F85D1 for ; Tue, 30 Jul 2013 23:39:41 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d51so137185eek.9 for ; Tue, 30 Jul 2013 23:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :importance:x-mailer:x-mimeole; bh=a7J163Oq5OdWDgpqMyA5F2n3BdI5ZeBpkmwVNDc6r5Q=; b=PnuHpLzFLHVEARDLcD15nY2KcVOwFvBwYUfwYEQL822Q4CiWwXaAXsoNQRtyKDIAQR ugCXMSFgxcejuCbnVp+Z3otAStHBpYyFqVw1HFS7yVY2UQdHKTBeP2bRnbQvEUJa5PxT aNC9rdoeVbCR7FBA1hkNwsvDTMTJewgRz8FJ5Zl8Rbbrmo+eRsBSAyWjKbDRJ/owrH2q qTb7E+NW0eKyJl0UsVAz/jASbeMgofaHPOvfTmBX+/6ghcfx8Gc8/P7wp5+IRLRJiPZv 2EDXfpscoxNbV5pRv9ryp9Z1DQAW7pVryIU5shTUsNrXJYfHKb4D6EAeWlKuRj1p0lyo sWXA== X-Received: by 10.15.61.130 with SMTP id i2mr65768175eex.122.1375252781320; Tue, 30 Jul 2013 23:39:41 -0700 (PDT) Received: from notebook ([81.92.21.2]) by mx.google.com with ESMTPSA id v41sm137389eep.10.2013.07.30.23.39.39 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Jul 2013 23:39:40 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "IPsecme WG" References: <0fb3a68e-671d-433e-b0d3-6be1aae57912@email.android.com><51F1AAD9.2070509@gmail.com> In-Reply-To: Date: Wed, 31 Jul 2013 08:38:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3508.205 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3508.205 Subject: Re: [IPsec] DOS protection and draft-ietf-ipsecme-ikev2-fragmentation-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 06:39:43 -0000 Hi Paul, actually, Tero has already answered your question and I have very little to add. I just want to reemphasize, that this design doesn't protect server from exhausting its CPU resources when attacker sends zillions of bogus messages - in this case both designs are roughly equivalent. But this design protects against more subtle attack - when attacker infrequently sends bogus fragments. If fragments are not protected, than attacker spendind _zero_ resources can effectively prevent legal user to connect. And, as Tero pointed out, this kind of attack is much harder to trace down. Regards, Valery. -----Original Message----- From: Paul Wouters Sent: Tuesday, July 30, 2013 3:49 PM To: IPsecme WG Subject: [IPsec] DOS protection and draft-ietf-ipsecme-ikev2-fragmentation-00 I still don't understand what the DOS protection actually accomplishes. I think it actually makes the problem worse. If the attacker is on-path, it can just withhold the packet. If the attack is not on-path he either cannot see your packets, which means the cookies/SPI numbers protect the exchange (whole packets and fragments), or they can see your packets. So let's assume they can see your packets. The initiator sends a packet with their cookie and the responder cookie set to 0. The attacker responds immediately with 1000 spoofed packets with different responder cookies. The initiator now has 1001 potentially valid responder states. Is it going to send 1001 packets and keep track of these? And all of this happens before fragmentation can even kick in, because we need a valid icookie/rcookie to identify them (with or without some authentication). If you do keep state, good. You send out 1001 ike packets (if this is 3g or wifi, it's probably going to fail) Let's say you can actually proceed at this point. You are further into the exchange, and now you are getting a bunch of fragments. Now the attacker can simply sent you bogus fragments with the real icookies/rcookies and apart from receiving this network DOS, your CPU will be under a DOS because it has to do crypto before it can discard all these packets. Or the attacker can use other zombies to send a motherload of fragments to the other endpoint. As teh attacker can just start a "new" exchange, they can keep sending your fragments to keep your CPU busy. Now look at the very simple defacto IKEv1 fragmentation, which is basically and IKEv1 header (with icookie/rcookie) followed by a single payload: * 1 2 3 * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! Next Payload ! RESERVED ! Payload Length ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! Fragment_ID ! Fragment_num ! Flags ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ! ! * ~ Fragment Data ~ * ! ! * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The only supported flag is "last fragment", when you received the fragment containing that, you can try and assemble the packet. The Fragment_ID is unneccessary (and in practice all implementations I've seen hardcode it to 1) and we should leave it out if we specify this for IKEv2, unless we need to support multiple exchanges in flight for the same SA. I'm still not convinced the extra complexity solves any real practical problem. Could someone try to convince me again why we need to cryptographically protect a fragment of cryptographically protected information? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec