Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05

[Linda Dunbar <[e-mail]>]

Anil,

Thank you very much for the comments. Reply are inserted below:


From: Anil Kumar S N (VRP Network BL)
Sent: Thursday, November 19, 2015 8:23 PM
To: [e-mail]
Cc: Linda Dunbar; Jayaraghavendran k; [e-mail]
Subject: Comments on draft-dunbar-i2nsf-problem-statement-05

Hi Authors,

          I was reading the draft for understanding and contributing towards I2NSF working group and found few comments :


*       Introduction section :  I think all these use cases are merged as "draft-pastor-i2nsf-merged-use-cases-00" request you to update the same


This document does not elaborate on specific use case. The reader
should refer to [I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile] for a
more in-depth discussion on the I2NSF use cases.

[Linda] you are correct. Actually all of them will be merged together with the problem statement.


*       Requirements Language, terms and acronyms section : We need to describe following abbreviations which are used in the documents as it the first document
to be referred by any newcomer into I2NSF WG

IPS, IDS, ACL, FWs, AAA, CA, VNFpool, Etc...

[Linda] Good point. Has been added.



*       3.1.1. Diverse types of Security Functions Section :  Below statement is contradicting each other, I2NSF wants to standardize the interface to control the behavior of NSF
but doesn't want to standardize the interface which carries the information of firewall filter and its application on specific flow. I Feel we could add more clarity on the scope of I2NSF with respect to
what is under its perview and what is not in this document if at all we want to talk about "what is needed" in this document.

     there is no need to standardize on how a
     firewall filters are created or applied. What is needed is having
     an interface to control and monitor the behavior of NSFs.
[Linda]  What in the I2NSF scope is "Rule Set" to those "Firewall filter".
How about this: "What is needed is having an interface to control and monitor the rule sets that NSFs use to treat packets traversing through."



*       3.1.2.  Diverse Interface to monitor the behavior of NSFs :  Reparsed as below

You Can't Monitor What You Can't See. So 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





*       Adding new section :

3.1.9 Lack of mechanism for Key Management/Deterministic Generation and Provisioning for communicating protocols



[Linda] Do you see it as challenge facing providers? Or the customers?  Do you mean  "Lack of Mechanism for security keys distribution to NSFs by different vendors"?





There is a need for a framework/data model for a key management protocol that may be used to create and manage session



[Linda] You need to provide more wording: Manage What Session? Is it IPSec session ? is VPN session?

What do you think of this

"There is a need for controller to distribute various keys to distributed NSFs."





keys for message authentication and integrity. As of now there is no much focus on an abstraction for keying information that describes the interface

between protocols, operators, and automated key management.



In March 2006, the Internet Architecture Board (IAB) held a workshop

on the topic of "Unwanted Internet Traffic".  The report from that workshop is documented in RFC 4948 [RFC4948].

Section 8.1 of that document states that "A simple risk analysis would suggest that an ideal attack target of minimal

cost but maximal disruption is the core routing infrastructure".  Section 8.2 calls for "Tightening the security of

the core routing infrastructure".



One of the four main steps were identified for that tightening the security for the protocol packets on the wire.

It is concerned with guidelines for describing issues and techniques for protecting the messages between directly communicating peers.



Conceptually, when routing protocols send or receive messages, they

   might need to look up the key to use in this abstract key table.

   Conceptually, there must be an interface defined for a protocols to

   make requests of automated key management when it is being used; when

   keys become available, they might be made available in the key table.

   There might not be any requirement that this abstraction be used for

   implementation:



   1) I2NSF need to design the key table abstraction, the interface between

      key management protocols and routing/other protocols, and possibly

      security protocols at other layers.



   2) For each routing/other protocol, I2NSF need to define the mapping between

      how the protocol represents key material and the protocol-

      independent key table abstraction.  When routing/other protocols share a

      common mechanism for authentication, such as the TCP

      Authentication Option, the same mapping is likely to be reused

      between protocols.  An implementation may be able to move much of

      the keying logic into code related to this shared authentication

      primitive rather than code specific to routing/other protocols.



   3) When designing automated key management for both symmetric keys

      and group keys, we will only need to use the abstractions designed based on

      point 1 above to communicate between automated key management and

      routing/other protocols.



With Regards

Anil S N


"Be liberal in what you accept, and conservative in what you send" - Jon Postel