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

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Fri, 20 Nov 2015 02:22:38 +0000

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.

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

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

*         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

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

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

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 20 Nov 2015 22:06:53 +0000

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: [email-masked]
Cc: Linda Dunbar; Jayaraghavendran k; [email-masked]
Subject: Comments on draft-dunbar-i2nsf-problem-statement-05

Hi Authors,

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

[Linda] Good point. Has been added.

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

*       Adding new section :

[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"?

[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."

   implementation:

      routing/other protocols.

With Regards

Anil S N

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 21 Nov 2015 12:28:06 +0000

Hi,

A couple of comments in line below…

On 20 Nov 2015, at 03:22 , Anil Kumar S N (VRP Network BL) <[email-masked]<mailto:[email-masked]>> wrote:
•         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…

DRL> I disagree. Terms like IDS, AAA, ACL or CA are well defined elsewhere, have been of common usage for quite a while, and there is no advantage in redefining them in this document. For what is worth, we could need to define terms like “network” or “TCP”… There may be others like VNFpool that would need a definition because they are by no means widespread, though in those case we should first consider whether the term makes sense in the document, which I’d say it is not the case for “VNFpool” in particular.

•         Adding new section :

   implementation:

      routing/other protocols.

DRL> As Linda said, you should clarify what is the purpose for this. The intent of I2NSF is not to define new security functions, but to define an interface to them. And I’d say you are proposing the definition of a new key management service to be used by routing and other protocols.

Be goode,

--
"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
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Sumandra Majee <[email-masked]>
Date: Sat, 21 Nov 2015 19:09:09 +0000

Agree that FW IDS IPS etc are commonly understood network component and trying to define them here might lead to more confusion. Having a section for abbreviation is ok.

Sent from my iPhone

On Nov 21, 2015, at 4:28 AM, DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

•         Adding new section :

   implementation:

      routing/other protocols.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Mon, 23 Nov 2015 04:03:46 +0000

Hi Linda,

Reply is inline.

Thanks & Regards
Anil S N

From: Linda Dunbar
Sent: 21 November 2015 06:07
To: Anil Kumar S N (VRP Network BL); [email-masked]
Cc: Jayaraghavendran k; [email-masked]
Subject: RE: Comments on draft-dunbar-i2nsf-problem-statement-05

Anil,

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

Hi Authors,

[[Anil >>]] Sounds good

*         Adding new section :

[[Anil >>]] Agreed, Will rephrase; Idea is that there are many key management methods and KDF (key derivation function) exist

but there is a need for standardizing the interface to provision and manage it.  Here any two communicating protocols could use same KDF

to deterministically derive keys and  to communicate. The reference to session should have been two communicating entities.

Which will enhances the security by reducing life time of a key used and non repetitive of the keys for a very long time which is very much important for control plane packets.

Derived keys may be extended to IPsec/VPN  data packet.

Since the lack of such management framework/interface limited service providers to use keys with very longer lifetime or a key chain with a set of key which were repeated in a cycle.

We would like to address above issue with I2NSF framework. Please correct me if I am wrong.

[[Anil >>]] How about below text :

3.1.9 Lack of framework/standard interface to provisioning the usage of Key Derivation Function (KDF) and managing KDF

A Key Derivation Function (KDF) or Key Derivation Algorithm is intended to be used in two ways:

(1) to derive a long-term Master Secret from a short-lived shared secret

(2) to derive secure channel session keys from a shared secret and a seed.

There is a need for a framework to ensure secure exchange of initial secrete between managing entity and managed entity (NSF).

There is a need for a framework/standard interface in provisioning two communicating protocols to use KDF as their key source for

Specific period of time or for a set of interaction.

There is also need for framework/standard interface in controlling and managing KDF used between two communicating protocols

The Provisioning and Managing framework could be extended to data plane too.

With Regards

Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Mon, 23 Nov 2015 05:03:35 +0000

Hi Diego,

                Please see inline for response.

Thanks & Regards
Anil S N

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

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: 21 November 2015 20:28
To: Anil Kumar S N (VRP Network BL)
Cc: [email-masked]; Jayaraghavendran k; [email-masked]; Linda Dunbar
Subject: Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05

Hi,

DRL> I disagree. Terms like IDS, AAA, ACL or CA are well defined elsewhere, have been of common usage for quite a while, and there is no advantage in redefining them in this document. For what is worth, we could need to define terms like “network” or “TCP”… There may be others like VNFpool that would need a definition because they are by no means widespread, though in those case we should first consider whether the term makes sense in the document, which I’d say it is not the case for “VNFpool” in particular.
[[Anil >>]]  Sorry my apologies Diego, I should have commented better, I meant to add these under abbreviation section. I didn’t mean to redefine it.

•         Adding new section :

   implementation:

      routing/other protocols.

DRL> As Linda said, you should clarify what is the purpose for this. The intent of I2NSF is not to define new security functions, but to define an interface to them. And I’d say you are proposing the definition of a new key management service to be used by routing and other protocols.
[[Anil >>]] Intention is not to define new security function, intension is to utilize I2NSF as interface/managing framework to utilize KDF for protocol.
I have replied in detail to Linda’s mail.

Be goode,

Dr Diego R. Lopez
Telefonica I+D