Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

Gabriel Lopez <gabilm@um.es> Tue, 27 November 2018 13:23 UTC

Return-Path: <gabilm@um.es>
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 34316130EAE; Tue, 27 Nov 2018 05:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5pZ_e8brDnT; Tue, 27 Nov 2018 05:23:34 -0800 (PST)
Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 34695130EA0; Tue, 27 Nov 2018 05:23:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 2DF3220099; Tue, 27 Nov 2018 14:23:31 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon42.um.es
Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JFrBUILKhfKd; Tue, 27 Nov 2018 14:23:31 +0100 (CET)
Received: from inf-205-3.inf.um.es (inf-205-3.inf.um.es [155.54.205.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 50B4E1FFCB; Tue, 27 Nov 2018 14:23:29 +0100 (CET)
From: Gabriel Lopez <gabilm@um.es>
Message-Id: <3415DDC9-ED45-462F-B561-E48773E404FB@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C06730B5-BD05-4166-87B8-DDC1F4254512"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 27 Nov 2018 14:23:28 +0100
In-Reply-To: <alpine.LRH.2.21.1811180149220.25604@bofh.nohats.ca>
Cc: Gabriel Lopez <gabilm@um.es>, Yoav Nir <ynir.ietf@gmail.com>, i2nsf@ietf.org, "ipsec@ietf.org WG" <ipsec@ietf.org>, Rafa Marin Lopez <rafa@um.es>
To: Paul Wouters <paul@nohats.ca>
References: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com> <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <DAE14995-8504-4134-B021-93D56A4994FB@gmail.com> <alpine.LRH.2.21.1811180149220.25604@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/vtNRB-aBk1FNgFtGR9Xo74o7VBg>
Subject: Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 13:23:46 -0000

Hi Paul, all

Please find attached some answers to your comments. Let’s go section by section, it will be easier to follow the discussion.


> El 18 nov 2018, a las 7:52, Paul Wouters <paul@nohats.ca> escribió:
> 
> 
> 
> 
> 
> General comments:
> I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I keep losing track of which case is which.
> Perhaps call them IKE Case and IKE-less Case ?

[Authors] We agree. What about "IKE-full" and "IKE-less" cases?

> 
> 
> Section 1:
> 
>   Typically, traditional IPsec VPN concentrators and, in general,
>   entities (i.e. hosts or security gateways) supporting IKE/IPsec, must
>   be configured directly by the administrator.  This makes the IPsec
>   security association (SA) management difficult and generates a lack
>   of flexibility, specially if the number of security policies and SAs
>   to handle is high.
> 
> This is not entirely true. We have Opportunistic IPsec that automates
> this precisely for the same reasons. We also have packet triggers in
> combination with Traffic Selector narrowing to create multiple IPsec
> SA's on demand. I know this is all qualified by "typically" but I think
> this paragraph is not adding any real information. The idea is that we
> have an SDWAN situation with SDN controllers and nodes, and we want to
> automate the IKE/IPsec for that specific deployment use case.



[Authors]  Thanks for the suggestion. Certainly the text is not reflecting the existence of those techniques alleviating the task of establishing IPsec SAs. Nonetheless, we have to clarify that this draft is not only guided by the SDWAN scenario and, in fact, it is intended to be applicable in other foreseeable SDN deployments.  With this in mind, we propose the following changes in the text:


s/"Typically, traditional IPsec VPN concentrators and, in general,
   entities (i.e. hosts or security gateways) supporting IKE/IPsec, must
   be configured directly by the administrator.  This makes the IPsec
   security association (SA) management difficult and generates a lack
   of flexibility, specially if the number of security policies and SAs
   to handle is high.  With the growth of SDN-based scenarios where
   network resources are deployed in an autonomous manner, a mechanism
   to manage IPsec SAs according to the SDN architecture becomes more
   relevant.  Thus, the SDN-based service described in this document
   will autonomously deal with IPsec SAs management." /
   
   "With the growth of SDN-based scenarios where
   network resources are deployed in an autonomous manner, a mechanism
   to manage IPsec SAs according to the SDN architecture becomes more
   relevant."
   	
s/"An example of usage can be the notion of Software Defined WAN (SD-
   WAN), SDN extension providing a software abstraction to create secure
   network overlays over traditional WAN and branch networks.  SD-WAN is
   based on IPsec as underlying security protocol and aims to provide
   flexible, automated, fast deployment and on-demand security network
   services." /
   
   "An example of usage can be the notion of Software Defined WAN (SD-
   WAN), SDN extension providing a software abstraction to create secure
   network overlays over traditional WAN and branch networks.  SD-WAN is
   based on IPsec as underlying security protocol and aims to provide
   flexible, automated, fast deployment and on-demand security network
   services. Other examples are host-to-host or full-mesh encryption. 
   Thus, the SDN-based service described in this document will autonomously deal with IPsec 
   SAs management.

> 
> 
>   The analysis of the host-to-gateway (roadwarrior) scenario is TBD.
> 
> Does this sentence mean this is to be done in this document or is it out
> of scope for this document (but it does allow it to be added later) ?


[Authors] We do not see a clear use case for roadwarrior scenarios based on SDN, the proposal
  is to remove it from this document. 



Regards, Gabi.

> 
> 

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es