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

Gabriel Lopez <gabilm@um.es> Tue, 27 November 2018 16:53 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 BDD4612D4EA; Tue, 27 Nov 2018 08:53:06 -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 gy7nKXuAlT-O; Tue, 27 Nov 2018 08:53:04 -0800 (PST)
Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id D339C126BED; Tue, 27 Nov 2018 08:53:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id C00302015D; Tue, 27 Nov 2018 17:53:02 +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 kfR7t4gZpR_4; Tue, 27 Nov 2018 17:53:02 +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 954DA1FEDD; Tue, 27 Nov 2018 17:53:00 +0100 (CET)
From: Gabriel Lopez <gabilm@um.es>
Message-Id: <B47EE67E-1B50-44BB-9821-AB439CA2C2F1@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CA24D225-DC26-48B0-902D-D3617FAEBDB6"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 27 Nov 2018 17:52:58 +0100
In-Reply-To: <alpine.LRH.2.21.1811270826430.2053@bofh.nohats.ca>
Cc: Gabriel Lopez <gabilm@um.es>, i2nsf@ietf.org, "ipsec@ietf.org WG" <ipsec@ietf.org>, Rafa Marin Lopez <rafa@um.es>, Yoav Nir <ynir.ietf@gmail.com>
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> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <alpine.LRH.2.21.1811270826430.2053@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/11pYOAjWLQ4cbGEHtO_uGx6J2CM>
Subject: Re: [IPsec] [I2nsf] 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 16:53:07 -0000

Hi Paul,

> El 27 nov 2018, a las 14:34, Paul Wouters <paul@nohats.ca>; escribió:
> 
> On Tue, 27 Nov 2018, Gabriel Lopez wrote:
> 
>> 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?
> 
> Hmm, I find "IKE-full" a bit odd (also because in English you would
> probably say "full-IKE" and not "IKE-full". Maybe another word could
> be "IKE-managed" or "IKE-controled" or "IKE-delegated” ?


Let’s use then IKE and IKE-less cases. Is that ok?

> 
>> [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.
> 
> works for me.
> 
>>        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. 
> 
> The case I can think of is if this is a "site to site" connection but
> one site is on dynamic IP (eg cable modem or 4g/5g connection) ?
> 
> The only difference in yang would be to instead of a static ip or
> hostname, to also allow a value of "any IP". In libreswan we use
> the string "%any" (and %any4 or %any6) but one could also use 0.0.0.0
> to mean that. I don't think it needs any other special handling (other
> then making sure an endpoint 0.0.0.0 should not use an IP based
> identity.

ok, that can be supported by the model without the necessity to include the specific road warrior scenario.


BTW, Fernando Pereñiguez is helping with the review. Our plan is to add him as author in the next version.

> 
> Paul

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