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

[Susan Hares]

Daniel:

 

I believe the 3rd revision will fix most of these problems.   I’ve included 
comments below.  I will send the 3rd revision out once I reach the hotel in 
Seoul Tonight.   Please see my comments below.   I will await your confirmation 
on the comments prior to adding new text into version 3. 

 

Sue 

 

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Wednesday, November 2, 2016 6:00 AM
To: Rafa Marin Lopez
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] Comments/questions about 
draft-ietf-i2nsf-problem-and-use-cases

 

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. 

 

[Sue #1]: I think I’ve done this in the new revision.  Please see if the 
changes address your comments. 



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 #2: "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.  

[Sue #2]:  How about
   A challenge for monitoring is that an NSF cannot monitor what it
   cannot view within the network to determine the status of security policy, 
monitoring or attacks? [I’m going to wait to put this change in until you tell 
me it works better for you.] 

 
   
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 #4]  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.  

[Sue #4]:  The VMs with vNSF must have additional security within the 
hypervisor to address the movements, and the I2NSF devices must operate in an 
environment that knows the monitor service must make before breaking the old VM 
connectivity.  I know these two features must be added.  I’m not sure about 
more.  What do you think?  Can we come up with some text that quantifies the 
challenge. 

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

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 

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

[Gabriel Lopez]

Dear all, please find some comments to the text

• Section 3.1.1
• Security gateways or VPNs concentrators could also be 
add to the list.
• “For example, from an I2NSF perspective, there is no 
need to standardize on how firewall filters are created or applied.”. It is not 
clear why ones need to be standardized and others no.
• Does it means I2NSF aims to standardize the 
interface to control firewalls filters rather than the own firewalls filters? 
(just to clarify)

• Section 3.1.9.
• In addition to Rafa’s comments, I suggest this 
section should introduce first the security functions where key distribution is 
required. For example: securing routing protocols? IPsec flow protection 
channels? AAA protocols? Then, to discuss about the different approaches: a 
protocol-independent key table? a protocol-based approach?. It seems authors 
are proposing some kind of solution, but this is a problem-use-case document.
• Section 3.2.2
• “No standard technical characterization and/or APIs” 
and “No standard interface”.
• Both texts talks about “standard interfaces”. 
Could they be merger? (just suggesting)
• Section 3.1.7 and section 3.4 both talks about IDS/IPS/etc. 
profiles. Could they be combined or referenced?
• Should 3.3 be 3.2.4? and 3.4 be 3.2.5? and 3.5 be 3.2.6?


Just my two cents.

Best regards, Gabi.


> El 3 oct 2016, a las 23:33, Rafa Marin Lopez  escribió:
> 
> Dear all:
> 
> I have reviewed draft-ietf-i2nsf-problem-and-use-cases and I have a few 
> comments/questions (my apologies if these have been already discussed in the 
> past).
> 
> ---
> 
> Section 3.1.1
> 
> -Security Functions in a DMZ. You refer to authentication and authorization 
> but also AAA. Is this not redundant?
> 
> -At first sight, there is no example of NSFs with flow based protection. That 
> is, those that participate in the establishment of a security association to 
> protect data traffic.
> 
> Section 3.1.10
> 
> - A general comment about this section is that the text seems to pay 
> attention to routing. In our case, for example, we have an I-D to manage 
> IPSec SAs based on SDNs 
> (https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-00). 
> I guess this use case we present in our I-D is somehow included in the text 
> “Conceptually, there must be an interface defined for routing/signaling 
> protocols…” but I am not sure. Could you clarify?
> 
> - A suggestion I have is to revise this paragraph:
> 
> “While there are many key management methods and
>   key derivation functions (KDF), there is a lack of standard interface
>   to provision and manage keys.”
> 
> There is a lack not only to provision and manage keys but also to specify 
> additional information (e.g. low level policies) or to fill certain 
> information to manage, in the end, a security association. Additionally, I am 
> not sure about the initial sentence "While there are many key management 
> methods and key derivation functions (KDF)”… what do you mean with this?
> 
> Perhaps a possible modification would say:
> 
> —-> While there are many key management methods and
>   cryptographic suites (e.g. encryption algorithms, key derivation functions, 
> etc…), there is a lack of standard interface
>   to provision and manage security associations.
> 
> 
> Regarding this paragraph:
> 
> “The ability to utilize keys when routing protocols send or receive
>   messages will be enhanced by having an abstract key table maintained
>   by a security service.  Conceptually, there must be an interface
>   defined for routing/signaling protocols to make requests for
>   automated key management when it is being used, to notify the
>   protocols when keys become available in the key table.”
> 
> In my opinion, it seems going into a solution space: “an abstract key table” 
> and a mechanism to “pull” the keys, is this correct?. Why using this key 
> table? Why using pull method so that the protocols know when the keys are 
> available in the table?. Also, the text refers to routing protocols at the 
> beginning. I would say that there must be an interface to configure security 
> associations of any nature, no?.
> 
> Section 4. In the use cases, there is no explicit text where key distribution 
> is required. One may think that section 4.3.2 and, most probably, 4.3.3 may 
> be related with key management (section 3.1.10). I mention this because our 
> I-D focused on key management for IPSec SAs and VPNs is a term that may be 
> associated to this.
> 
> Section 7.
> 
> When you mention AAA, are you referring to 
> https://tools.ietf.org/html/rfc2904 ?
> 
> -
> 
> Best Regards.
> 
> 
> ---
> Rafael Marin Lopez, PhD
>