Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Rafa Marin-Lopez <rafa@um.es> Fri, 24 May 2019 09:29 UTC

Return-Path: <rafa@um.es>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF61200E0 for <i2nsf@ietfa.amsl.com>; Fri, 24 May 2019 02:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 w2TuyOr-PXvu for <i2nsf@ietfa.amsl.com>; Fri, 24 May 2019 02:29:34 -0700 (PDT)
Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 69C9312008D for <i2nsf@ietf.org>; Fri, 24 May 2019 02:29:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 001E720AA3; Fri, 24 May 2019 11:29:29 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon43.um.es
Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OTa89O1uOKNd; Fri, 24 May 2019 11:29:29 +0200 (CEST)
Received: from [192.168.1.36] (251.red-88-17-15.dynamicip.rima-tde.net [88.17.15.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon43.um.es (Postfix) with ESMTPSA id 5FC39207EB; Fri, 24 May 2019 11:29:27 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1F481ED-05BA-4AC2-A17A-41459698DD3A"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Rafa Marin-Lopez <rafa@um.es>
In-Reply-To: <CAP_bo1Z1TBWsLjFqCY3UYpywVk6YWB=o+J3CunHTXEuOJDs_jQ@mail.gmail.com>
Date: Fri, 24 May 2019 11:29:39 +0200
Cc: Rafa Marin-Lopez <rafa@um.es>, Gabriel Lopez <gabilm@um.es>, =?utf-8?Q?Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa?= <fernando.pereniguez@cud.upct.es>, i2nsf@ietf.org, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>, Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <39E61B5E-3F8B-4261-8941-EC1BE6D064A6@um.es>
References: <CAP_bo1ZoLxYMfxXk12sngYAgcp7SgkmzZhawQY66ZNNVFbkp2A@mail.gmail.com> <CAEC30DB-DC8E-4B6F-897D-FB40244BD6D4@um.es> <CAP_bo1Z1TBWsLjFqCY3UYpywVk6YWB=o+J3CunHTXEuOJDs_jQ@mail.gmail.com>
To: Linda Dunbar <dunbar.ll@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/26fS3S7wgZ-hl492h4V9AZ5uP1Y>
Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 09:29:38 -0000

Hi Linda:

> El 21 may 2019, a las 23:02, Linda Dunbar <dunbar.ll@gmail.com>; escribió:
> 
> Gabriel and Rofa,
> 
> Just to clarify: the purpose of asking you changing from "container.." to "grouping.." is for  "i2nsf-nsf-facing-interface-dm"  to the "ikev2" and "ietf-ipsec" structure defined in draft-ietf-i2nsf-sdn-ipsec-flow-protection.

Yes, that was clear from the beginning. One of the concern I see is the following:

If the industry only wants to implement draft-ietf-i2nsf-sdn-ipsec-flow-protection for IPsec management, it can do it only if we leave the document as it is. In other words, the ideas in the document were designed to be standalone and that is why the container definition.

For example, if you check https://tools.ietf.org/html/rfc8519 my understanding is a device can deploy that RFC to manage ACLs. It does not need to implement anything else. IPsec YANG model is defined in the same way.

If we change from “container” to “grouping ..” then we would remove that option which, in my opinion, is not good.

I think Paul’s suggestion is in this line as well when he mentioned that their data models assumed that the actual IPsec configuration will be handled by IPsec module through NETCONF (draft-ietf-i2nsf-sdn-ipsec-flow-protection), and our I2NSF interfaces will do nothing related to the IPsec configuration.

In other words, it seems to me there is no need to integrate both.

Best Regards.


> Not other way around, i.e. not asking draft-ietf-i2nsf-sdn-ipsec-flow-protection to import other properties.
> 
> By the way, i2nsf-nsf-facing-interface-dm only imported two other data structure "ietf-inet-types" & "ietf-yang-types" besides the "ikev2" and "ietf-ipsec".
> 
> It has nothing to do with other modules for TTL, SSL, etc.
> 
> Thanks, Linda
> 
> 
> On Tue, May 21, 2019 at 3:42 AM Gabriel Lopez <gabilm@um.es <mailto:gabilm@um.es>> wrote:
> Hi Linda, Paul.
> 
>> El 20 may 2019, a las 19:52, Linda Dunbar <dunbar.ll@gmail.com <mailto:dunbar.ll@gmail.com>> escribió:
>> 
>> Gabriel,
>> 
>> Thanks for the explanation.
>> 
>> Agree with you that "it does not imply to extend the NSF client interface to include all the available yang models for every security service a NSF can support.".
>> But a network function that supports I2NSF should be allowed to your IPsec module, should it? 
> 
> Sure.
> 
> Regards, Gabi.
> 
> P.D. Linda, be aware you have included other email destination addresses in the “subject” field of our email.
> 
> 
> 
> 
>> 
>> what does it mean by you saying the following? 
>> "the Actual IPsec Configuration" is not same as "our I2NSF interface"?
>> That is, our data models assume that the actual IPsec configuration will be handled by Rafa's IPsec module through NETCONF, and
>> our I2NSF interfaces will do nothing related to the IPsec configuration.
>> 
>> Thanks, Linda
>> 
>> 
>> ----------------------
>> 
>> Hi Paul, Linda.
>>  
>> Thanks again for your comments.
>> 
>> 
>> El 18 may 2019, a las 7:11, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>> escribió:
>>  
>> Hi Linda,
>> For your first question,
>> it seems like Gabriel does not like to modify their code to let NSF-Facing Interface data module import ikev2 and ietf-ipsec (i.e., ike-less)
>> according to IETF YANG conventions such as TLS, SSH, IDS, and ACL.
>> In our data models, we will specify whether an NSF supports an IPsec configuration mechanism (IKEv2 or IKEless), 
>> or does not support any IPsec configuration mechanism. 
>> That is, our data models assume that the actual IPsec configuration will be handled by Rafa's IPsec module through NETCONF, and
>> our I2NSF interfaces will do nothing related to the IPsec configuration.
>>  
>>  
>>  
>> The question is not whether I (we) like or don't like to modify the model. The question is whether it is the best technical approach or not.
>> As said before, the ipsec model has been designed to work in a standalone mode in a NSF, so the controller can configure ipsec on NSFs without any other module.
>>  
>> You mention the consensous on the last meeting, but what I get from this consensous is to study how, making use of the capability model, the controller can learn if the NSF node supports IKE case or IKE-less case, and then in the discussion there is a mention to a "reference" to the corresponding data model implementing these capabilities (our model) (here the "reference" clause could be used). But it does not imply to extend the NSF client interface to include all the available yang models for every security service a NSF can support.
>>  
>> Our main concerns is if the objective of the nsf-client-dm is:
>>  
>> - To import all other models (SSH, TLS, ALCs, etc...) just for sake of having all of them gathered in a single model (nsf-client-dm). But I don't see the benefit. In fact, SSH or TLS yang models are designed to be used by other yang model for especific applications, such as a model for HTTPS importing the TLS model or a model for a SSH server importing the SSH model. What is the service in this case?. In the case of the ACL yang module, it is also defined to work in a standalone mode (no main grouping based). In the case of IDS, could you point out the yang module?
>>  
>> - To adapt them in some way to the ECA model. The ECA model is the keystone of the nsf-client-dm, as described in section 4. If it is the case, then it is difficult to see examples of how they can be adapted. 
>>  
>>  
>> Said that, the draft is a WG item and the WG has to decide what is the right way to proceed. 
>>  
>> 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 <mailto:gabilm@um.es>
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf