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

[DIEGO LOPEZ GARCIA <[e-mail]>]

Hi,

A couple of comments in line below…

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

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.

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: [e-mail]
Tel:    [phone]
Mobile: [phone]
----------------------------------


________________________________

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