Subject: [I2nsf] draft-kim-i2nsf-consumer-facing-interface-dm-00 and draft-kim-i2nsf-security-management-architecture-03

From: Rakesh Kumar <[email-masked]>
Date: Thu, 3 Nov 2016 00:48:31 +0000

Hi Paul,

Regarding the two drafts draft-kim-i2nsf-consumer-facing-interface-dm-00 and draft-kim-i2nsf-security-management-architecture-03 and merging these with other drafts as mentioned in other threads. I have responded to “draft-kim-i2nsf-security-management-architecture-03” earlier but here is the consolidated input on both.

Here is my understanding based on reading the two candidate drafts for merge:

1.       draft-kim-i2nsf-security-management-architecture-03: As per WG suggestion that we merge this draft with “draft-kumar-i2nsf-client-facing-interface-req-01”. I have responded earlier but now that draft has become WG draft “draft-ietf-i2nsf-client-facing-interface-req”. I see your draft has few main themes:

o    I2NSF user architecture: As I stated earlier that “draft-ietf-i2nsf-client-facing-interface-req” does not focus on specifics of a client/user system. As far as I know, this is outside the scope of I2NSF charter since focus is on the client-interface; so I don’t see this as a candidate for merge. We can discuss if you think my understanding is incorrect.

o    Security requirements for VoIP/VolTE :  I see security requirements such as malware domains,  URL/IP filtering which can be enforced dynamically based on time calendar. This definitely falls into the scope of “draft-ietf-i2nsf-client-facing-interface-req”. We have defined these requirements and scheduling methods already but in a more generic way like threat feeds (IP, URL) in section 4.8. The use-case could be as VoIP/VoLTE security as you mentioned but if you think it is not coming out clearly then we can modify the text. Let us work on it.

o    Security management system architecture:  This is not in the scope of “draft-ietf-i2nsf-client-facing-interface-req”. As far as I know, this is outside the scope of I2NSF charter since focus is on the NSF-interface; so I don’t see this as a candidate for merge. We can discuss if you think my understanding is incorrect.

2.       draft-kim-i2nsf-consumer-facing-interface-dm-00: This is a candidate for merge with draft-kumar-i2nsf-client-facing-interface-im as you and Linda pointed out but our draft is an information model, not a data model as yours. Anyway, I feel, we have defined these in section 5.1 and 5.3 but we can work with you to see whether you want to add or modify.

I know, this is one of the agenda items in Seoul, we should hash this out while in Seoul. I look forward to working with you on this.

Thanks & Regards,
Rakesh

Subject: Re: [I2nsf] questions about draft-kim-i2nsf-security-management-architecture-01
From: Rakesh Kumar <[email-masked]>
To: "Mr. Jaehoon Paul Jeong" <[email-masked]>, "Diego R. Lopez" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Prof. Hyoungshick Kim" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, Rakesh Kumar <[email-masked]>
Date: Wed, 26 Oct 2016 21:56:54 +0000

Hi Paul,

Based on suggestion from Diego to see if we could merge draft-kim-i2nsf-security-management-architecture-01 with draft-kumar-i2nsf-client-facing-interface-req-01.

Our draft deals with interfaces client would use to interact with the security controller/management system. We are discussing only the client interfaces and not the client structure itself. 

We should have a discussion to see what can be merged. I look forward to working with you.

Thanks & Regards,

Rakesh

From: I2nsf <[email-masked]> on behalf of "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sunday, October 23, 2016 at 10:43 PM
To: "Diego R. Lopez" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Prof. Hyoungshick Kim" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>
Subject: Re: [I2nsf] questions about draft-kim-i2nsf-security-management-architecture-01

Hi Diego, 

Thanks for your comments.

Our draft can be aligned with draft-kumar-i2nsf-client-facing-interface-req-01 in that

ours deals with the interface between I2NSF Client and Security Controller.

However, draft-kumar-i2nsf-client-facing-interface-req-01 does not clarify the structure of 

I2NSF Client in a detailed level, but our draft proposes such a detailed structure for I2NSF Client.

In addition, our draft considers the policy update in I2NSF through the report from an NSF 

for a security attack (e.g., DDoS attack) or an event (e.g., the detection of a new malware)

toward I2NSF Client. This updated policy is disseminated to the whole I2NSF systems

for spontaneous reaction to the new security attack or event.

Like this, our draft is closely related to the the I2NSF framework.

Let us prepare for the text for the I2NSF framework draft, and then discuss

whether our text can fit the I2NSF framework.

Thanks.

Best Regards,

Paul

 

On Sat, Oct 22, 2016 at 7:49 PM, Diego R. Lopez <[email-masked]> wrote:

Hi Paul, 

While I find agreeable that your draft could be merged with another one (or other ones) in order to consolidate the documents to be produced by I2NSF, I am not 100% sure it should be the framework draft. Looking at the proposals you make  in your draft I see it more aligned with what the drafts dealing with the client-facing interface are considering than with the general framework. In particular, draft-kumar-i2nsf-client-facing-interface-req-01 has  a section(3.3) that discusses management deployment models, and I am under the impression this architecture you propose could be seen as a refinement of those models.

Be goode,

On 21 Oct 2016, at 02:54 , Mr. Jaehoon Paul Jeong <[email-masked]> wrote:

Hi Linda, 

Are you agreeing at merging our draft (draft-kim-i2nsf-security-management-architecture-02) 

into draft-ietf-i2nsf-framework-03?

Thanks.

Best Regards,

Paul

On Fri, Oct 7, 2016 at 5:32 AM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:

Hi Linda, 

As a coauthor of this draft, I will answer your questions inline below.

On Wed, Oct 5, 2016 at 1:34 PM, Linda Dunbar <[email-masked]> wrote:

Hyoungshick, et al, 

How would you position your draft-kim-i2nsf-security-management-architecture-01 with regard to the I2NSF framework draft? I find there are  a lot of duplicated content to the I2nsf  framework draft.

 [Paul] We would like to merge our draft into the i2nsf framework draft 

 because our draft has one depth more detailed architecture.

 This detailed architecture will be helpful to implement the i2nsf framework. 

There are some differences,  such as the following: Are you trying to define how “security policy” is structured?  

 [Paul] Our architecture allows an NSF to update a low-level policy and apply it to the related high-level policy

 via the control path of Security Controller and Policy Collector (renamed Event Collector in version 02) in Figure 1

 of our version 02:

 https://tools.ietf.org/html/draft-kim-i2nsf-security-management-architecture-02

 For example, if an NSF of firewall detects a new DoS-attack host, it reports the updated blacklist having

 the IP address of such a host to Application Logic in I2NSF Client via Security Controller and Event Collector. 

 Application Logic asks Policy Updater to disseminate the updated blacklist to the security controllers 

 under the administration of the same I2NSF Client. 

Will the “High Level security management” eventually lead to Client Facing Policy data models?

 [Paul] Yes, as explained above, the High-level security management leads to update and handle Client facing policy 

 data models.

Do you plan to define interfaces between all those components depicted in Figure 1?  The interfaces between some of those components are not really in the I2NSF WG current charter,  such as “Security Policy Manager” <-> “NSF Capability Manager”,  or the interface between “Application Logic” <-> “Policy Updater”.

 [Paul]  Yes, we have a plan to define such interfaces.

Are those components in your current implementation? Is it like an “example of one implementation”?

 [Paul] Though those components are not fully implemented yet in our implementation, my team at SKKU 

 will make implement those components in a later version.

 Thanks for your clarification questions.

 Best Regards,

 Paul

Thanks, Linda 

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

-- 

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

-- 

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

-- 

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 3 Nov 2016 10:53:18 +0900

Hi Rakesh,
Thanks for your analysis and suggestions.

Sure, we can discuss these issues in IETF-97 Seoul Meeting.

Thanks.

Best Regards,
Paul

On Thu, Nov 3, 2016 at 9:48 AM, Rakesh Kumar <[email-masked]> wrote:

> Hi Paul,
>
>
>
> Regarding the two drafts draft-kim-i2nsf-consumer-facing-interface-dm-00
> and draft-kim-i2nsf-security-management-architecture-03 and merging these
> with other drafts as mentioned in other threads. I have responded to
> “draft-kim-i2nsf-security-management-architecture-03” earlier but here is
> the consolidated input on both.
>
>
>
> 1.       *draft-kim-i2nsf-security-management-architecture-03: *As per WG
> suggestion that we merge this draft with “draft-kumar-i2nsf-client-facing-interface-req-01”.
> I have responded earlier but now that draft has become WG draft “
> draft-ietf-i2nsf-client-facing-interface-req”. I see your draft has few
> main themes:
>
> o    *I2NSF user architecture: *As I stated earlier that “
> draft-ietf-i2nsf-client-facing-interface-req” does not focus on specifics
> of a client/user system. As far as I know, this is outside the scope of
> I2NSF charter since focus is on the client-interface; so I don’t see this
> as a candidate for merge. We can discuss if you think my understanding is
> incorrect.
>
> o    *Security requirements for VoIP/VolTE : * I see security
> requirements such as malware domains,  URL/IP filtering which can be
> enforced dynamically based on time calendar. This definitely falls into
> the scope of “draft-ietf-i2nsf-client-facing-interface-req”. We have
> defined these requirements and scheduling methods already but in a more
> generic way like threat feeds (IP, URL) in section 4.8. The use-case could
> be as VoIP/VoLTE security as you mentioned but if you think it is not
> coming out clearly then we can modify the text. Let us work on it.
>
> o    *Security management system architecture: * This is not in the scope
> of “draft-ietf-i2nsf-client-facing-interface-req”. As far as I know, this
> is outside the scope of I2NSF charter since focus is on the NSF-interface;
> so I don’t see this as a candidate for merge. We can discuss if you think
> my understanding is incorrect.
>
> 2.       *draft-kim-i2nsf-consumer-facing-interface-dm-00: *This is a
> candidate for merge with draft-kumar-i2nsf-client-facing-interface-im as
> you and Linda pointed out but our draft is an information model, not a data
> model as yours. Anyway, I feel, we have defined these in section 5.1 and
> 5.3 but we can work with you to see whether you want to add or modify.
>
>
>
> I know, this is one of the agenda items in Seoul, we should hash this out
> while in Seoul. I look forward to working with you on this.
>
>
>
> Thanks & Regards,
>
> Rakesh
>
>
>
>
> ---------- Forwarded message ----------
> Cc: "[email-masked]" <[email-masked]>, "Prof. Hyoungshick Kim" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Linda Dunbar <
> [email-masked]>, Rakesh Kumar <[email-masked]>
> Subject: Re: [I2nsf] questions about
> draft-kim-i2nsf-security-management-architecture-01
>
> Hi Paul,
>
>
>
> Based on suggestion from Diego to see if we could merge
> draft-kim-i2nsf-security-management-architecture-01 with
> draft-kumar-i2nsf-client-facing-interface-req-01.
>
> Our draft deals with interfaces client would use to interact with the
> security controller/management system. We are discussing only the client
> interfaces and not the client structure itself.
>
>
>
> *From: *I2nsf <[email-masked]> on behalf of "Mr. Jaehoon Paul
> Jeong" <[email-masked]>
> *Date: *Sunday, October 23, 2016 at 10:43 PM
> *To: *"Diego R. Lopez" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Prof. Hyoungshick Kim" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <skku_secu-brain_all@
> googlegroups.com>, Linda Dunbar <[email-masked]>
> *Subject: *Re: [I2nsf] questions about draft-kim-i2nsf-security-
> management-architecture-01
>
>
>
> Hi Diego,
>
> While I find agreeable that your draft could be merged with another one
> (or other ones) in order to consolidate the documents to be produced by
> I2NSF, I am not 100% sure it should be the framework draft. Looking at the
> proposals you make in your draft I see it more aligned with what the drafts
> dealing with the client-facing interface are considering than with the
> general framework. In particular, draft-kumar-i2nsf-
> client-facing-interface-req-01
> <https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-req/> has
> a section(3.3) that discusses management deployment models, and I am under
> the impression this architecture you propose could be seen as a refinement
> of those models.
>
>
>
> Be goode,
>
>
>
> How would you position your draft-kim-i2nsf-security-management-architecture-01
> with regard to the I2NSF framework draft? I find there are  a lot of
> duplicated content to the I2nsf framework draft.
>
>
>
> There are some differences,  such as the following: Are you trying to
> define how “security policy” is structured?
>
>
>
>
>
>
>  [Paul] Our architecture allows an NSF to update a low-level policy and
> apply it to the related high-level policy
>
>  via the control path of Security Controller and Policy Collector (renamed
> Event Collector in version 02) in Figure 1
>
>  of our version 02:
>
>  [Paul] Yes, as explained above, the High-level security management leads
> to update and handle Client facing policy
>
>  data models.
>
>
>
> Do you plan to define interfaces between all those components depicted in
> Figure 1?  The interfaces between some of those components are not really
> in the I2NSF WG current charter, such as “Security Policy Manager” <-> “NSF
> Capability Manager”,  or the interface between “Application Logic” <->
> “Policy Updater”.
>
>
>
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
>
>
>
>
> --
>
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
>

<http://cpslab.skku.edu/people-jaehoon-jeong.php>