Re: [I2nsf] I-D Action: draft-ietf-i2nsf-terminology-02.txt

[John Strassner]

Hi Daniel,

Thanks for the comments, please see inline.

Best,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Wednesday, November 02, 2016 3:20 AM
To: i2nsf@ietf.org
Subject: Re: [I2nsf] I-D Action: draft-ietf-i2nsf-terminology-02.txt

Please consider responding to this email rather than the previous one. -- Too 
many CCs.
Yours,
Daniel

On Wed, Nov 2, 2016 at 6:16 AM, Daniel Migault 
> wrote:
Hi,
I reviewed the document. Please find my comments below.
Yours,
Daniel


   Metadata:  Data that provides information about other data.

MGLT: This is actually how metadata is defined. However, it might be usefull to 
provide an example, or conplete the definition.

How about if we add an example? As you say, this is a complete and concise 
definition of metadata; I would prefer if the definitions are kept concise, and 
are augmented with examples.

I an also wondering if I2NSF only defines metadata associated to YANG models. 
If so woudl it be relevant to mention RFC7952 ?

This is a good point.

The examples do not seem to ilustrate what metadata is, instead they mention 
protocols that use YANG for which metadta is defined.
  Examples include IETF network management protocols (e.g.  NETCONF,
  RESTCONF, IPFIX) or IETF routing interfaces (I2RS).  The I2NSF
  security interface may utilize Metadata to describe and/or
  prescribe characteristics and behavior of the YANG data models.

You are correct. I propose replacing the existing example with the following:
Metadata may be used to describe and/or prescribe the characteristics
and behavior of the data that the metadata applies to. Metadata is NOT
limited to metadata as defined in YANG models [RFC7952]; rather,
metadata ca be used to augment the modeling of any I2NSF model
element. Examples include:
  - version information of an I2NSF Capability, I2NSF Component,
 I2NSF Policy, or other function or object of an I2NSF system
   - descriptive information, such as best current practices or other
 usage information, that describe the use or operation of an
 I2NSF Component
   - prescriptive information, such as algorithms or commands, that
 define how an I2NSF Component should be used


   Network Security Function (NSF):  Software that provides a set of
  security-related services.  Examples include detecting unwanted
  activity and blocking or mitigating the effect of such unwanted
  activity in order to fulfil service requirements.  The NSF can
  also help in supporting communication stream integrity and
  confidentiality.

MGLT: It is not clear to me the relation between function and service. My 
understanding is that service may involve multiple functions. But I believe it 
would be helpful to position these two concepts - at least in this definition.


Good point. How about:
   Network Security Function (NSF):  Software that provides a set of
  security-related services. An NSF represents the software as a
  functional block. An NSF functional block may contain one or
  more security-related services. Examples include detecting unwanted
  activity and blocking or mitigating the effect of such unwanted
  activity in order to fulfil service requirements.  The NSF can
  also help in supporting communication stream integrity and
  confidentiality.


   Producer:  A Producer is a Role that is assigned to an I2NSF
  Component that can send information and/or commands to another
  I2NSF Component.  See also: Consumer, Role.

MGLT: Is Producer equivalent to provider ? If so maybe that would hepl to use a 
single designation.


I assume you mean I2NSF Provider Interface? Or are you worried that people will 
equate Provider to Producer?
Generically, Providers supply services, but are NOT a functional block in an 
I2NSF system. Rather, they are actors that use an I2NSF system. In contrast, a 
Producer is a functional block in an I2NSF system that supplies information, 
resources, or services for consumption by other I2NSF Components.
We could add the fact that a Producer is a type of I2NSF Component, whereas a 
Provider is not.
We could also define a functional block. ☺


On Sun, Oct 23, 2016 at 9:44 PM, 
> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions of the 
IETF.

Title   : Interface to Network Security Functions (I2NSF) 
Terminology
Authors : Susan Hares
  John Strassner
  Diego R. Lopez
  Liang Xia
  Henk Birkholz
Filename: draft-ietf-i2nsf-terminology-02.txt
Pages   : 13
Date: 2016-10-23

Abstract:
   This document defines a set of 

Re: [I2nsf] RFC or not RFC in I2NSF?

[John Strassner]

I agree with your recommendations.

Regards,
John

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, November 02, 2016 11:42 AM
To: i2nsf@ietf.org
Cc: 'Kathleen Moriarty' 
Subject: [I2nsf] RFC or not RFC in I2NSF?

Hi,

We have a charter action and milestone to decide whether to publish our work as 
RFCs or not. The milestone reads:

> WG decides whether to progress adopted drafts for publication as RFCs 
> (use
cases,
> framework, information model, and examination of existing secure 
> communication
> mechanisms)

We had some (light) conversations on the list and arrived at the following 
position, I think. This is your chance to scream if you disagree - otherwise, 
this is the email of record documenting our plan.

use cases
draft-ietf-i2nsf-problem-and-use-cases
Pursue publication

framework
draft-ietf-i2nsf-framework
Pursue publication

information model
Not yet clear, but some feeling that we should publish.
Pending adoption and more work.

gap analysis for protocols
draft-ietf-i2nsf-gap-analysis
Do not publish
Keep draft alive for as long as it is useful, then archive

requirements for protocol extensions
Covered as part of draft-ietf-i2nsf-client-facing-interface-req-00
Pursue publication

examination of existing secure communication mechanisms Aim to add this to  
draft-ietf-i2nsf-client-facing-interface-req-00
Pursue publication

terminology
draft-ietf-i2nsf-terminology
Pursue publication

Cheers,
Adrian

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Questions to draft-mglt-i2nsf-ssf-collaboration

[Daniel Migault]

Hi Linda,

Thank you for the feed back. It is unlikely we will present an updated
version of the draft at the ietf in Seoul, but we will probably be able to
update the draft by the  end of teh year. I understand your question is
about the protocol used to configure the NSF.


Will different NSFs have different “protocol” to work across domains?

Can you give some examples of those NSFs?
We hope no, but it may happen. At least netconf and restconf are two
distinct protocols and NSF may implement one of teh other over time. Our
agreement template defines some attributes so the Cloud ( or Customer) can
actually configure the NSF in the Cloudlet. Suppose the NSF is a firewall.
We do not consider the configuration of the firewall as part of the
agreement. Instead the provider instantiates the firewall and provides the
necessary element for the controller of the Cloud to configure the
firewall. We expect for example that the configuration of the firewall will
be performed using netconf and YANG.

Is the protocol straightly between two NSF instances?

I understand thsi as wether the netconf session terminates at the NSF. No
it depends on the arcnitecture.  The controller is expected to configure
the instance. It may directly reach the NSF but it can also be proxyfied.
In our example teh Cloud receives an attribute that indicates it can
configure the firewall NSF at this IP/port address with Netconf. In our
infrastructure the IP/port is on the  Controller of the Cloudlet. The
Controller of the Cloud reaches the Controller of the Cloudlet which in
turn configures the NSF. Other architectures may consider a direct
connection between teh COntroller of the Cloud and the NSF. What is behind
the IP/port is out of control of the Cloud.

Is it necessary for the NSFs in two domains by same vendors?



When configuration of the NSF is performed using Netconf/YANG there is no
need that the NSF be from the same vendor. If te configuration is performed
using a vendor specific protocol then likely yes.

Yours,
Daniel


On Wed, Nov 2, 2016 at 11:48 AM, Linda Dunbar 
wrote:

>
>
> Daniel,
>
>
>
> Your draft said:
>
> *“**Our protocol defines how the two domains interconnect to have NSF
> working in different domains interacting properly. In our case, the
> security controller of the cloud and the security controller of the
> cloudlet agree on how the cloudlet and the cloud needs to interconnect
> their data plane as well as how the cloud can configure or control the NSF
> in the cloudlet. The configuration of the NSF itself is not part of the
> collaboration protocol typically we expect that NETCONF/YANG be used.” *
>
> Will different NSFs have different “protocol” to work across domains? Is
> the protocol straightly between two NSF instances? Is it necessary for the
> NSFs in two domains by same vendors?
>
>
>
> Can you give some examples of those NSFs?
>
>
>
> Thanks, Linda
>
>
>
> *From:* mglt.i...@gmail.com [mailto:mglt.i...@gmail.com
> ] *On Behalf Of *Daniel Migault
> *Sent:* Wednesday, September 21, 2016 8:04 AM
> *To:* Linda Dunbar
> *Cc:* Alireza Ranjbar; i2nsf@ietf.org
> *Subject:* Re: [I2nsf] Is the “Security Service Function (SSF)” in
> draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the
> I2NSF-problem-and-use-cases?
>
>
>
> Hi Linda,
>
>
>
> I apology for the delay. Please find my response and additional questions
> – mostly for Susan ;-). If you are find with the response, I can also send
> them on the ML.
>
>
>
> Q1: There is no difference between SSF and NSF. We will change that in the
> next version. Thanks for raising it, this is a good reminder to update our
> terminology.
>
>
>
> Q2: Our protocol defines how the two domains interconnect to have NSF
> working in different domains interacting properly. In our case, the
> security controller of the cloud and the security controller of the
> cloudlet agree on how the cloudlet and the cloud needs to interconnect
> their data plane as well as how the cloud can configure or control the NSF
> in the cloudlet. The configuration of the NSF itself is not part of the
> collaboration protocol typically we expect that NETCONF/YANG be used.
>
>
>
> My understanding of draft-kumar-i2nsf-controller-northbound-framework-00
> [1] is that is provides some requirements for an API to be able to manage a
> whole domain of NSF provided by multiple vendors. In our case if a cloud
> were using such API, we would consider the security controller of the cloud
> got control over a significant part of the resource of the cloudlet. In our
> case, we would like that collaboration of the cloudlet can be performed
> with a reduced footprint from the cloud. The foot print is limited by the
> cloudlet by limiting the interaction from the cloud to the NSF
> instantiating in the cloud.
>
>
>
> BR,
>
> Daniel
>
>
>
> On Mon, Sep 12, 2016 at 5:59 PM, Linda Dunbar 
> wrote:
>
> Daniel and Alirezza,
>
>
>
> Is the 

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

[Rakesh Kumar]

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:

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

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

oSecurity 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

--- Begin Message ---
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  on behalf of "Mr. Jaehoon Paul Jeong" 

Date: Sunday, October 23, 2016 at 10:43 PM
To: "Diego R. Lopez" 
Cc: "i2nsf@ietf.org" , "Prof. Hyoungshick Kim" 
, "paulje...@skku.edu" , 
"skku_secu-brain_...@googlegroups.com" , 
Linda Dunbar 
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  
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 

Re: [I2nsf] RFC or not RFC in I2NSF?

[Daniel Migault]

I agree. As the gap analysis draft is not to be published, I would probably
try to integrate some very clarifying text/figure into the problem and use
case draft.

Yours,
Daniel

On Wed, Nov 2, 2016 at 2:42 PM, Adrian Farrel  wrote:

> Hi,
>
> We have a charter action and milestone to decide whether to publish our
> work as
> RFCs or not. The milestone reads:
>
> > WG decides whether to progress adopted drafts for publication as RFCs
> (use
> cases,
> > framework, information model, and examination of existing secure
> communication
> > mechanisms)
>
> We had some (light) conversations on the list and arrived at the following
> position, I think. This is your chance to scream if you disagree -
> otherwise,
> this is the email of record documenting our plan.
>
> use cases
> draft-ietf-i2nsf-problem-and-use-cases
> Pursue publication
>
> framework
> draft-ietf-i2nsf-framework
> Pursue publication
>
> information model
> Not yet clear, but some feeling that we should publish.
> Pending adoption and more work.
>
> gap analysis for protocols
> draft-ietf-i2nsf-gap-analysis
> Do not publish
> Keep draft alive for as long as it is useful, then archive
>
> requirements for protocol extensions
> Covered as part of draft-ietf-i2nsf-client-facing-interface-req-00
> Pursue publication
>
> examination of existing secure communication mechanisms
> Aim to add this to  draft-ietf-i2nsf-client-facing-interface-req-00
> Pursue publication
>
> terminology
> draft-ietf-i2nsf-terminology
> Pursue publication
>
> Cheers,
> Adrian
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] IETF-97 draft agenda posted

[Linda Dunbar]

Hi All,

The draft agenda is posted here 
https://datatracker.ietf.org/meeting/97/agenda/i2nsf/

If you requested agenda time and don't see yourself there, or if you need to 
make a correction, please let the chairs know.

Thanks,

Linda & Adrian

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] [i2nsf] Hacking I2NSF in IETF-97 Seoul Meeting

[Linda Dunbar]

Paul,

Thank you very much for championing the I2NSF hackathon at IETF97.

We have reserved 10 minutes slot on the I2NSF WG session agenda for you to give 
a report of the I2NSF hackathon.

Thank you.

Linda

From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
Sent: 2016年11月2日 14:19
To: hackat...@ietf.org
Cc: Linda Dunbar ; Adrian Farrel 
; skku_secu-brain_...@googlegroups.com; JungSoo Park 
; Tae-Jin Ahn ; Mr. Jaehoon Paul Jeong 

Subject: [i2nsf] Hacking I2NSF in IETF-97 Seoul Meeting

Greetings,

My coworkers and I are planning to champion an I2NSF project at the Hackathon 
in IETF-97 Seoul Meeting
to work on the implementation of security services in the I2NSF framwork.

We added our Hackathon description for the I2NSF framework project:

[I2nsf] Call for WG adoption of draft-xibassnez-i2nsf-capability

[Linda Dunbar]

Dear WG:

This email serves as a call for WG adoption of draft-xibassnez-i2nsf-capability 
as a WG document. Considering people will be traveling to Seoul for IETF 97 and 
the Thanksgiving holiday afterwards, the call for adoption will run for 3.5 
weeks ending Nov 28, 2016.

draft-xibassnez-i2nsf-capability-00 actually is the -07 version of 
draft-xia-i2nsf-capability-interface-IM, draft name change as the result of the 
progress of I2NSF terminology and merge with
draft-baspez-i2nsf-capabilities

Please note that this is a call for adoption, and not a last call for content 
of the document. Adopting a WG document simply means that the WG will focus its 
efforts on that particular draft going forward, and use that document for 
resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issues 
you have with the current document itself can also be raised, but they should 
be raised in the context of what should be changed in the document going 
forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies 
to this draft, in line with the IPR disclosure obligations for WG participants 
(see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a 
document author please respond to this email (to the chairs) whether or not you 
are aware of any relevant IPR
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/


Thank you,

Linda & Adrian



___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Security for security :-)

[Rakesh Kumar]

Hi Adrian,

Thanks for pointing this out.
We will look into this and make changes.


Regards,
Rakesh
On 11/2/16, 11:33 AM, "Adrian Farrel"  wrote:

Hi,

Looking at draft-ietf-i2nsf-client-facing-interface-req I think it may be
lacking some discussion of security for the interface itself.

I think sections 4.2 through 4.5 cover some of this. But maybe there should 
also
be something in section 5?

A really good prompt for things you might need to cover is RFC 3552. Have a 
look
and see whether it causes any ideas.

Additionally, you will require a "Security Considerations" section. *if* you
have everything covered elsewhere this section can be a summary of issues 
and
resolutions complete with pointers to the relevant sections.

Thanks!

Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.






___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] RFC or not RFC in I2NSF?

[Adrian Farrel]

Hi,

We have a charter action and milestone to decide whether to publish our work as
RFCs or not. The milestone reads:

> WG decides whether to progress adopted drafts for publication as RFCs (use
cases,
> framework, information model, and examination of existing secure communication
> mechanisms) 

We had some (light) conversations on the list and arrived at the following
position, I think. This is your chance to scream if you disagree - otherwise,
this is the email of record documenting our plan.

use cases
draft-ietf-i2nsf-problem-and-use-cases
Pursue publication

framework
draft-ietf-i2nsf-framework
Pursue publication

information model
Not yet clear, but some feeling that we should publish.
Pending adoption and more work.

gap analysis for protocols
draft-ietf-i2nsf-gap-analysis
Do not publish
Keep draft alive for as long as it is useful, then archive

requirements for protocol extensions
Covered as part of draft-ietf-i2nsf-client-facing-interface-req-00 
Pursue publication

examination of existing secure communication mechanisms
Aim to add this to  draft-ietf-i2nsf-client-facing-interface-req-00 
Pursue publication

terminology
draft-ietf-i2nsf-terminology
Pursue publication

Cheers,
Adrian

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Security for security :-)

[Adrian Farrel]

Hi,

Looking at draft-ietf-i2nsf-client-facing-interface-req I think it may be
lacking some discussion of security for the interface itself.

I think sections 4.2 through 4.5 cover some of this. But maybe there should also
be something in section 5?

A really good prompt for things you might need to cover is RFC 3552. Have a look
and see whether it causes any ideas.

Additionally, you will require a "Security Considerations" section. *if* you
have everything covered elsewhere this section can be a summary of issues and
resolutions complete with pointers to the relevant sections.

Thanks!

Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.




___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Milestones changed for i2nsf WG

[IETF Secretariat]

Changed milestone "Adopt requirements for extensions to protocols as
WG document", resolved as "Done", added
draft-ietf-i2nsf-client-facing-interface-req to milestone.

URL: https://datatracker.ietf.org/wg/i2nsf/charter/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] The I2NSF WG has placed draft-xibassnez-i2nsf-capability in state "Candidate for WG Adoption"

[IETF Secretariat]

The I2NSF WG has placed draft-xibassnez-i2nsf-capability in state 
Candidate for WG Adoption (entered by Adrian Farrel)

The document is available at
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Will you provide more details on the Rules' Information model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

[Rakesh Kumar]

Hi Linda,

One more thing regarding how a policy/rule is to be enforced. We see two 
distinct requirements:


1.   Static security posture --> The security admin determines what 
security policies need to be enforced in their network based on their business 
needs (access policies such as who can access what) and/or regulatory 
compliance (HIPPA, FISA). These policies usually stay in the network unless 
manually removed. In my experience, majority of security policies fall under 
this category.

2.   Dynamic  security posture --> Some of the policies may be created but 
not always enforced. A security admin may want to increase or decrease its 
security posture based on an event. The event could be a time-based or threat 
based. For example, a policy is enforced only during weekend or a policy is 
enforced only when a DDoS event is detected.

I don’t have any name for first one but the second one is ECA (Event Condition 
Action). We wanted to take both of them for interfaces to be meaningful in real 
security world. I hope this clarifies our thinking. We can add a section in our 
draft to put similar text there if you think that would be helpful.

Thanks & Regards,
Rakesh


From: I2nsf  on behalf of Rakesh Kumar 

Date: Tuesday, November 1, 2016 at 11:56 AM
To: Linda Dunbar , "i2nsf@ietf.org" 
Cc: Adrian Farrel 
Subject: Re: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Hi Linda,

Thanks a lot for the review.

One of the biggest challenges in the security world today is that, it is too 
complex with each vendor having their own set of features and functionality 
exposed in a very proprietary manner.  We have to simplify this with I2NSF 
client-facing interface so that a security admin can express their business 
needs without having to worry about the complexity.

It is very important that security requirements be expressed by security admin 
with simple rules. But it is easier said than done, this is one of the most 
complex problem as how to make rules simple but at the same time able to 
capture wide variety of use-cases in different environment.

The work done so far in this draft is just the beginning and we should brain 
storm and see how to make it more complete. I will look at the link you have 
sent and see how to leverage from there. Even if we develop very generic rules, 
we still need to define some basic constructs which would be used to build a 
policy. We have taken a step in that direction, but this is just a start and 
work will continue with ideas from folks in this WG.


Regards,
Rakesh

From: Linda Dunbar 
Date: Tuesday, November 1, 2016 at 10:55 AM
To: Rakesh Kumar , "i2nsf@ietf.org" 
Cc: Adrian Farrel 
Subject: RE: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

By the way, the I2NSF framework has specified to use ECA (Event Condition 
Action) to describe “Rules”.
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/ has the 
detailed description on how “Rules” information model.

Is there any issue to utilize those information model?

Thanks,
Linda

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: 2016年11月1日 12:10
To: Rakesh Kumar ; i2nsf@ietf.org
Cc: Adrian Farrel 
Subject: [I2nsf] Will you provide more details on the Rules' Information model 
in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

Thank you very much for contributing the draft. Just curious, the current IM 
for Rules doesn't have much details:


[cid:image001.jpg@01D234E9.B3807410]

Will you add more in future revision?

Linda Dunbar

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar
Sent: 2016年10月31日 12:14
To: i2nsf@ietf.org
Cc: Adrian Farrel >; Linda 
Dunbar >
Subject: [I2nsf] FW: New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-im-00.txt

We posted a new draft that captures an information model for the client-facing 
interfaces based on “draft-ietf-i2nsf-client-facing-interface-req”.
This is an initial version, we plan to update this as we evolve based on new 
requirements and information.


Thanks & Regards,
Rakesh and other co-authors.


On 10/31/16, 10:08 AM, 
"internet-dra...@ietf.org" 
> wrote:


A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-00.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

[I2nsf] Questions to draft-mglt-i2nsf-ssf-collaboration

[Linda Dunbar]

Daniel,

Your draft said:
“Our protocol defines how the two domains interconnect to have NSF working in 
different domains interacting properly. In our case, the security controller of 
the cloud and the security controller of the cloudlet agree on how the cloudlet 
and the cloud needs to interconnect their data plane as well as how the cloud 
can configure or control the NSF in the cloudlet. The configuration of the NSF 
itself is not part of the collaboration protocol typically we expect that 
NETCONF/YANG be used.”
Will different NSFs have different “protocol” to work across domains? Is the 
protocol straightly between two NSF instances? Is it necessary for the NSFs in 
two domains by same vendors?

Can you give some examples of those NSFs?

Thanks, Linda

From: mglt.i...@gmail.com 
[mailto:mglt.i...@gmail.com] On Behalf Of Daniel Migault
Sent: Wednesday, September 21, 2016 8:04 AM
To: Linda Dunbar
Cc: Alireza Ranjbar; i2nsf@ietf.org
Subject: Re: [I2nsf] Is the “Security Service Function (SSF)” in 
draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the 
I2NSF-problem-and-use-cases?

Hi Linda,

I apology for the delay. Please find my response and additional questions – 
mostly for Susan ;-). If you are find with the response, I can also send them 
on the ML.

Q1: There is no difference between SSF and NSF. We will change that in the next 
version. Thanks for raising it, this is a good reminder to update our 
terminology.

Q2: Our protocol defines how the two domains interconnect to have NSF working 
in different domains interacting properly. In our case, the security controller 
of the cloud and the security controller of the cloudlet agree on how the 
cloudlet and the cloud needs to interconnect their data plane as well as how 
the cloud can configure or control the NSF in the cloudlet. The configuration 
of the NSF itself is not part of the collaboration protocol typically we expect 
that NETCONF/YANG be used.

My understanding of draft-kumar-i2nsf-controller-northbound-framework-00 [1] is 
that is provides some requirements for an API to be able to manage a whole 
domain of NSF provided by multiple vendors. In our case if a cloud were using 
such API, we would consider the security controller of the cloud got control 
over a significant part of the resource of the cloudlet. In our case, we would 
like that collaboration of the cloudlet can be performed with a reduced 
footprint from the cloud. The foot print is limited by the cloudlet by limiting 
the interaction from the cloud to the NSF instantiating in the cloud.

BR,
Daniel

On Mon, Sep 12, 2016 at 5:59 PM, Linda Dunbar 
> wrote:
Daniel and Alirezza,

Is the “Security Service Function (SSF)” in your draft equivalent to the 
Network Security Function (NSF) defined in 
https://www.ietf.org/id/draft-ietf-i2nsf-problem-and-use-cases-01.pdf  ?


NSF: Network Security Function. An NSF is a function that detects abnormal 
activity and blocks/mitigates the effect of such abnormal activity in order to 
preserve the availability of a network or a service. In addition, the NSF can 
help in supporting communication stream integrity and confidentiality.

Flow-based NSF: An NSF which inspects network flows according to a
security policy. Flow-based security also means that packets are
inspected in the order they are received, and without altering
packets due to the inspection process (e.g., MAC rewrites, TTL
decrement action, or NAT inspection or changes).


If they are the same, can you change the terminology? If they are different, 
can you elaborate the differences in your draft?


Second question:
When the “Cloud based services” need network provider to enforce certain flow 
rules for the traffic destined to (originated from) the “Cloud based services”, 
do you anticipate those flow rules to be applied to specific SSFs belonging to 
different administrators?  Or can those rules be to the “controller” of the 
SSFs belonging to network providers?  As described by  
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-framework/
 ?


Thanks,
Linda

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] I-D Action: draft-xibassnez-i2nsf-capability-00.txt

[Xialiang (Frank)]

Hi all,
Since draft-xibassnez-i2nsf-capability-00 actually is the -07 version of 
draft-xia-i2nsf-capability-interface-IM, and we believe this draft has 
specified the I2NSF capability information model all needed clearly, as well as 
solving all the related comments and inconsistence issues. At this stage, we 
request the WG to consider if it can be accepted as the WG draft for further 
improvement to be a solid base for other data model related drafts.

Thanks!

B.R.
Frank

> -Original Message-
> From: Xialiang (Frank)
> Sent: Tuesday, November 01, 2016 12:41 AM
> To: i2nsf@ietf.org
> Subject: FW: I-D Action: draft-xibassnez-i2nsf-capability-00.txt
> 
> Hi all,
> The update of draft-xia-i2nsf-capability-interface-IM-06 has been submit just
> now. According to previous discussion, we rename the draft to
> draft-xibassnez-i2nsf-capability-00.
> 
> This draft is a combination of draft-xia-i2nsf-capability-interface-IM-06 and
> draft-baspez-i2nsf-capabilities-00 with a consistent way.
> Please review it and give your comments, thanks!
> 
> B.R.
> Frank
> 
> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, November 01, 2016 12:28 AM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-xibassnez-i2nsf-capability-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Information Model of NSFs Capabilities
> Authors : Liang Xia
>   John Strassner
>   DaCheng Zhang
>   Kepeng Li
>   Cataldo Basile
>   Antonio Lioy
>   Diego R. Lopez
>   Edward Lopez
>   Nicolas BOUTHORS
>   Luyuan Fang
>   Filename: draft-xibassnez-i2nsf-capability-00.txt
>   Pages   : 62
>   Date: 2016-10-31
> 
> Abstract:
>This draft aims at defining the concept of capability. Capabilities
>are data that unambiguously characterize NSFs (Network Security
>Functions). Their correct definition will ease all the management
>and automation that can be. Moreover, it allows the definition of
>Interfaces to manage NSFs.
> 
>This draft is the first trial to merge two previous existing drafts
>on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on
>the capability interface [I-D.draft-xia-i2nsf-capability-interface-
>im-06]. Further work will be needed to homogenize all the concepts
>and incorporate the feedback that will result after its publication.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-xibassnez-i2nsf-capability-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-terminology-02.txt

[Daniel Migault]

Please consider responding to this email rather than the previous one. --
Too many CCs.

Yours,
Daniel

On Wed, Nov 2, 2016 at 6:16 AM, Daniel Migault 
wrote:

> Hi,
>
> I reviewed the document. Please find my comments below.
>
> Yours,
> Daniel
>
>
>
>Metadata:  Data that provides information about other data.
>
> MGLT: This is actually how metadata is defined. However, it might be
> usefull to provide an example, or conplete the definition. I an also
> wondering if I2NSF only defines metadata associated to YANG models. If so
> woudl it be relevant to mention RFC7952 ? The examples do not seem to
> ilustrate what metadata is, instead they mention protocols that use YANG
> for which metadta is defined.
>
>   Examples include IETF network management protocols (e.g.  NETCONF,
>   RESTCONF, IPFIX) or IETF routing interfaces (I2RS).  The I2NSF
>   security interface may utilize Metadata to describe and/or
>   prescribe characteristics and behavior of the YANG data models.
>
>
>Network Security Function (NSF):  Software that provides a set of
>   security-related services.  Examples include detecting unwanted
>   activity and blocking or mitigating the effect of such unwanted
>   activity in order to fulfil service requirements.  The NSF can
>   also help in supporting communication stream integrity and
>   confidentiality.
>
> MGLT: It is not clear to me the relation between function and service. My
> understanding is that service may involve multiple functions. But I believe
> it would be helpful to position these two concepts - at least in this
> definition.
>
>
>Producer:  A Producer is a Role that is assigned to an I2NSF
>   Component that can send information and/or commands to another
>   I2NSF Component.  See also: Consumer, Role.
>
> MGLT: Is Producer equivalent to provider ? If so maybe that would hepl to
> use a single designation.
>
>
>
>
>
> On Sun, Oct 23, 2016 at 9:44 PM,  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Interface to Network Security Functions
>> of the IETF.
>>
>> Title   : Interface to Network Security Functions (I2NSF)
>> Terminology
>> Authors : Susan Hares
>>   John Strassner
>>   Diego R. Lopez
>>   Liang Xia
>>   Henk Birkholz
>> Filename: draft-ietf-i2nsf-terminology-02.txt
>> Pages   : 13
>> Date: 2016-10-23
>>
>> Abstract:
>>This document defines a set of terms that are used for the Interface
>>to Network Security Functions (I2NSF) effort.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-terminology/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-i2nsf-terminology-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-terminology-02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>
>
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Comments/questions about draft-ietf-i2nsf-problem-and-use-cases

[Daniel Migault]

Hi,

I read the doument and here are my comments.

Yours,
Daniel



3.  Problem Space
3.1.  Challenges Facing Security Service Providers
3.1.1.  Diverse Types of Security Functions


   Internal Data and Content Protection:   Examples of this function are
  encryption, authorization, and public/private key management for
  internal database.

   Given the diversity of security functions, the contexts in which
   these functions can be deployed, and the constant evolution of these



Hares, et al. Expires April 8, 2017 [Page 5]

Internet-Draft   I2NSF Problem/Use Case October 2016


   functions, standardizing all aspects of security functions is
   challenging, and most probably not feasible.  Fortunately, it is not
   necessary to standardize all aspects.  For example, from an I2NSF
   perspective, there is no need to standardize on how firewall filters
   are created or applied.

MGLT: Maybe that woudl also be helpful to specify what I2NSF needs to
define. More specifically, I2NSF should define a high level description of
the interface that is implementation and vendor independent. What is not so
clear to me is, in the casse of the firewall what kind of interaction are
in the scope of I2NSF. From reading the gap analysis document it seems to
me that provisionning and configuring the firewall with rules is not in the
scope of I2NSF yet. Instead the I2NSF is interested in capabilities of the
fucntions. Typically the support of IPv6 could be a capability for the
firewall.

3.1.2.  Diverse Interfaces to Control and Monitor NSFs


   A challenge for monitoring is that an NSF cannot monitor what it
   cannot view.  Therefore, enabling a security function (e.g., firewall
   [I-D.ietf-opsawg-firewalls]) does not mean that a network is
   protected.  As such, it is necessary to have a mechanism to monitor
   and provide execution status of NSFs to security and compliance
   management tools.  There exist various network security monitoring
   vendor-specific interfaces for forensics and troubleshooting.

MGLT: "what it cannot view" is not clear to me. It might be helpful to be
more positive and define what it can monitor. That said, what was confusing
for me is whether viewing is achieved by configuring the appropriated
firewall rules or because ther is a need to provide feedbacks or status on
the firewall activity.

3.1.3.  More Distributed NSFs and vNSFs

   The security functions which are invoked to enforce a security policy
   can be located in different equipment and network locations.

   The European Telecommunications Standards Institute (ETSI) Network
   Function Virtualization (NFV) initiative creates new management
   challenges for security policies to be enforced by distributed,
   virtual, and network security functions (vNSF).

   A vNSF has higher risk of failure, migrating, and state changes as
   their hosting VMs are being created, moved, or decommissioned.

 MGLT: Given that statement I believe it would be helpful to understand how
I2NSF is related to that challenge and how it expects to address that
challenge. I also believe that such clarification could be provide for
other issues.



3.1.6.  Lack of Characterization of NSFs and Capability Exchange



   Today, there is no standard method for vendors to describe the
   capabilities of their security functions.  Without a common technical
   framework to describe the capabilities of security functions, service
   providers cannot automate the process of selecting NSFs by different
   vendors to accommodate customer's requirements.

MGLT: I like the current text of this section. It is much clearer than in
the previous version. ;-) and clearly state how I2NSF is expected to
address this issue.





Hares, et al. Expires April 8, 2017 [Page 7]

Internet-Draft   I2NSF Problem/Use Case October 2016


3.1.7.  Lack of Mechanism for NSFs to Utilize External Profiles

   Many security functions depend on signature files or profiles to
   perform (e.g., IPS/IDS signatures, DOTS filters).  Different policies
   might need different signatures or profiles.  Today, the construction
   and use of black list databases can be a win-win strategy for all
   parties involved.  There might be Open Source-provided signature/
   profiles (e.g., by Snort or others) in the future.

MGLT: I am not sure there is a consensus on what DOTS fileters are. I
believe it would hep th ereader to clarify or illustrate what the profile
is. I understand profile as the correlation of observations.


   There is a need to have a standard envelop (i.e., the format) to
   allow NSFs to use external profiles.

MGLT: Would'nt it a YANG models that makes possible the definition of
profiles. A profile would be in that case the speciifc instantiation of a
YANG model (the set of values associated to the model). These models will
be used by I2NSF to derive the actions from the Customer