Re: [I2nsf] Request for WGLC on I2NSF YANG Data Models

Hi Gabriel,
I have submitted a revision of the Consumer-Facing Interface Data Model
draft supporting
your IPsec method for IKE and IKEless cases:
https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-04

Thanks.

Best Regards,
Paul

On Mon, Apr 1, 2019 at 10:30 PM Mr. Jaehoon Paul Jeong <
jaehoon.paul@gmail.com> wrote:

> Hi Gabriel,
> I will answer your questions inline below.
>
> On Mon, Apr 1, 2019 at 7:18 PM Gabriel Lopez <gabilm@um.es> wrote:
>
>> Hi Paul.
>>
>> Just a few comments about the drafts:
>>
>> El 28 mar 2019, a las 8:39, Mr. Jaehoon Paul Jeong <
>> jaehoon.paul@gmail.com> escribió:
>>
>> Hi Linda and Yoav,
>> As we discussed this I2NSF WG meeting, my SKKU team reflected the data
>> convergence
>> including I2NSF IPsec (such as ipsec-ike case and ipsec-ikeless case) on
>> the three data model drafts, and then
>> uploaded them into the IETF repository this morning:
>> - NSF Capability Data Model
>> - NSF-Facing Interface Data Model
>> - Registration Interface Data Model
>>
>> The update of each draft is described in Changes section per draft.
>>
>> There is no change in Consumer-Facing Interface Data Model draft.
>>
>> Could you start WGLC for the following four data model drafts?
>> - NSF Capability Data Model
>>   https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-04
>>
>>
>>
>> This draft specifies whether IKE/ IKE-less cases are supported by the NSF
>> or not, in the same way that it specifies if the NSF supports IPS or not.
>> But the details about capabilities for ipsec or IDS are moved now to
>> another draft (dong-i2nsf-asf-config). Is it right?
>>
>
>  => Yes. For the detailed configuration of ipsec, we will be able to use
> your data model by
>       letting it be referenced by our NSF-facing interface YANG module.
>       We will let you know how to modify your YANG module this week so
> that it can be used by our NSF-facing interface data model.
>
>
>>
>> - NSF-Facing Interface Data Model
>>   https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-05
>>
>>
>> How does it align with the security-policy-translation draft?
>>
>  => The security policy translator translates a high-level security policy
> XML file (based on Consumer-facing interface data model)
>        into a low-level security policy XML file (based on NSF-facing
> interface data model).
>        In the security-policy-translation draft,
>        there is exemplary XML code as follows:
>        - High-level security policy XML Code
>
> https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-03#page-7
>
>        - Low-level security policy XML Code
>
> https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-03#page-18
>
>
>>
>> - Registration Interface Data Model
>>
>> https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-03
>>
>>
>>
>>
>>
>> - Consumer-Facing Interface Data Model
>>
>> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-03
>>
>>
>>
>> Import of the ipsec draft should not be included here. Both drafts (ipsec
>> and this one) should stay both like nsf facing interface models, but not
>> one integrated into the other.
>>
>>   => This statement is not clear to me. Could you clarify this more
> clearly if you have a better way?
>
>        For Registration interface data model, we use ipsec-method (either
> IKE or IKEless) that is defined in I2NSF Capability data model draft:
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-04#page-7
>
>        To use this ipsec-method in Registration interface data model, we
> import I2NSF Capability data model as follows:
>
> ############################################################
> 6.1.3. NSF Capability Information - p. 11
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-03#page-11
>
>
>
> ----------------------------------------------------------------------------------------------------
> 6.2. YANG Data Modules - p. 12
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-03#page-12
>
>
> import ietf-i2nsf-capability{
>   prefix capa;
>   reference "draft-ietf-i2nsf-capability-data-model-04";
> }
>
>
> ----------------------------------------------------------------------------------------------------
> grouping i2nsf-nsf-capability-info - p. 15-16
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-03#page-16
>
>
> group i2nsf-nsf-capability-info {
>   description
>   "Detail information of an NSF";
>   container i2nsf-capability {
>     description
>       "ietf i2nsf capability information";
>     uses "capa:nsf-capabilities";
>     reference "draft-ietf-i2nsf-capability-data-model-04";
>   }
>   container nsf-performance-capability {
>     description
>       "performance capability";
>     uses i2nsf-nsf-performance-capability;
>   }
> }
>
>
> ----------------------------------------------------------------------------------------------------
> Configuration Example 1~6: p. 19
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-03#page-19
>
>
> <ipsec-method>ikeless</ipsec-method>
> ############################################################
>
>       For the configuration of IPsec (e.g., SPD and PAD parameters) for an
> NSF, could you make a YANG code
>       for such configuration for Registration interface YANG code and XML
> code like our example in
>       Registration interface data model draft?
>       We will be able to include your YANG code to accommodate IPsec
> configuration in the revision of our Registration interface data model
> draft.
>
>       If you have a better way to configure your IPsec configuration into
> Security Controller, please let me know.
>
>  => For Consumer-facing interface data model, we will include ipsec-method
> (either IKE or IKEless) in
>       the revision of Consumer-facing interface data model draft.
>       This configuration will let NSFs for a high-level security policy
> make an IPsec tunnel between each pair of NSFs
>       along the SFC path (e.g., Firewall -> DPI -> DDoS Attack Mitigator).
>
>       I think your students can work with my students at SKKU for the test
> of this integration and test.
>       My Ph.D student, Jinyong (Tim) Kim, is in charge of the
> implementation and test.
>
>       If you have questions, please let me know.
>
>       Thanks.
>
>       Best Regards,
>       Paul
>
>>
>> Best regards, Gabi.
>>
>>
>> I hope we can publish them before the IETF-105 Montreal meeting. :-)
>>
>> Thanks.
>>
>> Best Regards,
>> Paul
>> --
>> ===========================
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Associate Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957
>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>> _______________________________________________
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>> -----------------------------------------------------------
>> 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 <gabilm@um.es>
>>
>>
>>
>>
>
> --
> ===========================
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Associate Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957
> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>