[I2nsf] I-D Action: draft-ietf-i2nsf-framework-06.txt

[internet-drafts]

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   : Framework for Interface to Network Security Functions
Authors : Diego R. Lopez
  Edward Lopez
  Linda Dunbar
  John Strassner
  Rakesh Kumar
Filename: draft-ietf-i2nsf-framework-06.txt
Pages   : 22
Date: 2017-07-02

Abstract:
   This document describes the framework for the Interface to Network
   Security Functions (I2NSF), and defines a reference model (including
   major functional components) for I2NSF.  Network security functions
   (NSFs) are packet-processing engines that inspect and optionally
   modify packets traversing networks, either directly or in the context
   of sessions to which the packet is associated.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-framework-06
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-framework-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-framework-06


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] FW: New Version Notification for draft-xia-i2nsf-security-policy-object-01.txt

[Linqiushi (Jessica, SCC)]

Hi all,

We have submitted an update to the policy object draft. This draft describes a 
list of policy objects that can be used in policy rules to provide 
re-usability. 

The major changes in this version are as follows: 
- Provide a minimal set of policy objects and attributes
- Add examples for possible values of object attributes
- Add Appendix to show an example of application scenario for the defined 
policy objects

Your review and comments are warmly welcome!

Best Regards,
Qiushi Lin

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2017年7月3日 10:30
收件人: Linqiushi (Jessica, SCC); Xialiang (Frank); Linqiushi (Jessica, SCC); 
Xialiang (Frank)
主题: New Version Notification for draft-xia-i2nsf-security-policy-object-01.txt


A new version of I-D, draft-xia-i2nsf-security-policy-object-01.txt
has been successfully submitted by Qiushi Lin and posted to the IETF repository.

Name:   draft-xia-i2nsf-security-policy-object
Revision:   01
Title:  Policy Object for Interface to Network Security Functions 
(I2NSF)
Document date:  2017-07-02
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/internet-drafts/draft-xia-i2nsf-security-policy-object-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-xia-i2nsf-security-policy-object/
Htmlized:   
https://tools.ietf.org/html/draft-xia-i2nsf-security-policy-object-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xia-i2nsf-security-policy-object-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-xia-i2nsf-security-policy-object-01

Abstract:
   This document describes policy object used in the Interface to
   Network Security Functions (I2NSF) policy rules to provide re-
   usability and defines essential attributes for each policy object.


  


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.

The IETF Secretariat

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

[I2nsf] Framework Draft, section 6.2

[John Strassner]

Section 6.2 says:

   o  When multiple instantiations of one single NSF appear as one
  single entity to the Security Controller, the policy provisioning
  has to be sent to the NSF Manager, which in turn disseminates the
  polices to the corresponding instantiations of the NSF, as shown
  in Figure 2 below.


I have no idea what an "NSF Manager" is. It is not defined in the
Terminology draft. The closest term in the terminology draft is
"I2NSF Management System".

However, for some reason, this reminds me of the VNFM in ETSI NFV.
If that is true, then I2NSF Management System is NOT the same thing.

I think that "NSF Manager" could be an EMS, as well as other types of
management engines. It is NOT the "I2NSF Management system".
However, I don't know what to call it, so I made the following
temporary hack:

   o  When multiple instantiations of one single NSF appear as one
  single entity to the Security Controller, the Security Controller
  may need to either get assistance from other entities in the
  I2NSF Management System, and/or delegate the provisioning of the
  multiple instantiations of the (single) NSF to other entities in
  the I2NSF Management System. This is shown in Figure 2 below.



-- 
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Framework Draft Comments From Adrian

[John Strassner]

Hi Adrian,

thanks for the thorough review. Your comments are addressed below. Please
note that I can NOT find reviews of this draft by Christian and Med. I did
search the archive. I found comments on the terminology draft from
Christian.

regards,
John

ALL comments were accepted, except as noted below.


In 2.2, the term used in
is "I2NSF Consumer"

I suggest you write
   Consumer: Equivalent to "I2NSF Consumer"


This should be I2NSF Consumer according to the terminology draft, so I made
that change throughout this document.


---

I'm struggling a little with 

3.3.  Registration Interface

   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have an interface for vendors to define the capabilities of their
   NSFs.  This Interface Group is called the Registration Interface
   Group.

   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the Registration Interface Group.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities SHOULD be notified to security controllers via the
   Registration Interface Group.

There is definitely an ambiguity about this. Is the section talking
about the "Registration Interface Group"? What are the component
interfaces in this group?


Terminology defines an Interface Group, but not a Registration Interface
Group. I have changed this to "I2NSF Registration Interface".
Here is the rewritten paragraph:
3.3.  I2NSF Registration Interface
   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have a dedicated interface for vendors to define the capabilities of
   (i.e., register) their NSFs.  This Interface is called the
   I2NSF Registration Interface.
   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the I2NSF Registration Interface.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities should be notified to security controllers via the
   I2NSF Registration Interface.

---

6.1.  Network Connecting I2NSF Users and I2NSF Controller

   [TBD: should we add the Remote Attestation to this section?]

I think you have added remote attestation and can remove this note.


Not yet - see earlier note. Since there are at least two different
approaches to remote attestation in the IETF, I think the WG still needs to
decide what to do here. I see no reason why we can't push this framework
draft forward and then have the remote attestation work (which still isn't
even a WG draft) add on and augment later. Hence, no action has yet been
taken.


---

6.2

   The network connection between the Security Controller and NSFs can
   rely either on:

Should you be making clear that in the open environment anything from a
few up to all of the NSFs can be hosted in external administrative
domains.  Thus "closed" is very tightly defined, and "open" is anything
that is not completely closed.


Here is the rewrite:
   o  Open environments, where one or more NSFs can be hosted in one or
  more external administrative domains that are reached via secure
  external network connections.  This requires more restrictive
  security control to be placed over the I2NSF interface.  The
  information over the I2NSF interfaces shall be exchanged used
  trusted channels as described in the previous section.

   When running in an open environment, I2NSF needs to rely on
   interfaces to properly verify peer identities (e.g., through an AAA
   framework).  The implementations of identity management functions,
   as well as the AAA framework, are out of scope for I2NSF.


---

I can't help thinking that section 9.2 is way too detailed for this
document. I don't think there is anything wrong in what it says, but it
looks more like an information model for a specific capability exchange
than something that belongs in a general framework.

Can you see whether there is a different document that this belongs in?


This COULD be folded into the Capability Interface document, and then this
(the Framework) document could reference the Capability interface document.
However, that document is not yet accepted by the WG. So, would you like me
to:

   1) leave as is, so the Framework document can proceed to last call, or
   2) move this entire section to the Capability document, or
   3) do something other than 1) or 2)?



-- 
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] comments about I2NSF framework draft://答复: Progress with draft-ietf-i2nsf-framework-05

[John Strassner]

Here is my proposed resolution to these points:

1. nits: P18 " Table 1: Subject Capability Index " should change to " Table
1: Packet Content Matching Capability Index ",  P19, " Table 2: Object
Capability Index " should change to " Table 2: context matching Capability
Index ";
[Rakesh]  Makes sense to me. We should take this.

Done. Also fixed captions of Tables 3 and 4. :-)



2. Section 11 of Security Considerations: this section is a little bit
simple without considering the possible threats like: unauthenticated
connections between users and controller, and between controller and NSFs,
DoS attacks from malicious users or NSFs, etc;
[Rakesh] In my opinion, this is just a framework document. Any specific of
security considerations (such as you pointed out) should go into each
individual drafts covering client, regigttration and NSF interfaces.  If
you think it would help, we could add something like this to the section 11.

I agree with Frank. I think we should add text before we go to last call.
Let's discuss in Prague. No action for now (but am still going through
comments).



3. question: should section 7.3 move to the I2NSF gap analysis draft?
[Rakesh] I don’t have very strong opinion one way or other but it gives
some context to other sections. It is good to have.

I think it should stay here. No action taken.



4. I think remote attestation function should be described as a part into
the whole I2NSF framework;
[Rakesh] I agree with you.

Disagree. There is major work to be done in remote attestation. We have at
least two different approaches that will (hopefully) be merged in the near
future. This would delay the last call of this document by...pick a date..6
months minimum imho.

I don't see why remote attestation cannot reference and augment this draft.
No action taken.



5. Section 3.2, by my understanding, notification is just part of the
monitor functions, such as: syslog, netconf. Is it necessary to divide them
into two interfaces?
[Rakesh] In larger scheme of things, everything can be combined into one
but it is good to show differentiation since each set serve different
purpose and may require different operational characterstics.

I do not read the text this way. First, it describes THREE, not two,
interfaces. Second, none of the three categories are mentioned again in the
entire document. I read this as explanatory text to help the reader develop
a better conceptual understanding of the document.
No action taken.



regards,
John

On Thu, May 25, 2017 at 1:15 PM, Rakesh Kumar  wrote:

> Hi Frank,
>
> Thanks for your review and support. We will make changes to the draft
> based on your comments and any other comments we receive in next few days.
> Please see my take on your comments below.
>
> Thanks
> Rakesh
>
> On 5/21/17, 8:32 PM, "I2nsf on behalf of Xialiang (Frank)" <
> i2nsf-boun...@ietf.org on behalf of frank.xiali...@huawei.com> wrote:
>
> Hi Adrian, I2NSFers,
> I reviewed the latest draft again and thinks it's in a very good shape
> now. So, it can be a foundation for all the other drafts.
>
> Of course, I also have some comments about it as below:
> 1. nits: P18 " Table 1: Subject Capability Index " should change to "
> Table 1: Packet Content Matching Capability Index ",  P19, " Table 2:
> Object Capability Index " should change to " Table 2: context matching
> Capability Index ";
> [Rakesh]  Makes sense to me. We should take this.
>
> 2. Section 11 of Security Considerations: this section is a little bit
> simple without considering the possible threats like: unauthenticated
> connections between users and controller, and between controller and NSFs,
> DoS attacks from malicious users or NSFs, etc;
> [Rakesh] In my opinion, this is just a framework document. Any specific of
> security considerations (such as you pointed out) should go into each
> individual drafts covering client, regigttration and NSF interfaces.  If
> you think it would help, we could add something like this to the section 11.
>
> 3. question: should section 7.3 move to the I2NSF gap analysis draft?
> [Rakesh] I don’t have very strong opinion one way or other but it gives
> some context to other sections. It is good to have.
>
> 4. I think remote attestation function should be described as a part into
> the whole I2NSF framework;
> [Rakesh] I agree with you.
>
> 5. Section 3.2, by my understanding, notification is just part of the
> monitor functions, such as: syslog, netconf. Is it necessary to divide them
> into two interfaces?
> [Rakesh] In larger scheme of things, everything can be combined into one
> but it is good to show differentiation since each set serve different
> purpose and may require different operational characterstics.
>
>
> B.R.
> Frank
>
> -邮件原件-
> 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Adrian Farrel
> 发送时间: 2017年5月19日 1:49
> 收件人: i2nsf@ietf.org
> 主题: [I2nsf] Progress with draft-ietf-i2nsf-framework-05
>
> Hi WG,
>
> I am about to do a document