Re: [I2nsf] Secdir telechat review of draft-ietf-i2nsf-framework-08

2017-11-12 Thread John Strassner 
Dear Daniel,

thank you for performing this review. The following changes will be
implemented in version 9 of this I-D, to be released on Monday 11/13.
In particular,


Change the last paragraph in section 4,
from:
   The above threats may be mitigated by requiring the use of an AAA
   framework for all users to access the I2NSF environment. This could
   be further enhanced by requiring attestation to be used to detect
   changes to the I2NSF environment by authorized parties.

to:
   The use of authentication, authorization, accounting, and audit
   mechanisms is recommended for all users and applications to access
   the I2NSF environment. This can be further enhanced by requiring
   attestation to be used to detect changes to the I2NSF environment
   by authorized parties. The characteristics of these procedures will
   define the level of assurance of the I2NSF environment.

Change section 6.1
from:
6.1.  Network Connecting I2NSF Users and the I2NSF Controller

   ...
   Upon successful authentication, a trusted connection between the
   user and the I2NSF Controller (or an endpoint designated by it) will
   be established.  All traffic to and from the NSF environment ...

to:
6.1. Network Connecting I2NSF Users and the I2NSF Controller

   ...
   Upon successful authentication, a trusted connection between the
   user and the I2NSF Controller (or an endpoint designated by it) will
   be established. This means that a direct, physical point-to-point
   connection, with physical access restricted according to access
   control, must be used. All traffic to and from the NSF environment...

Change 6.2:
from:
6.2.  Network Connecting the I2NSF Controller and NSFs
   ...

to:
6.2.  Network Connecting the I2NSF Controller and NSFs

   ...
   Therefore, the transport mechanism used to carry the control messages
   and monitoring information should provide reliable message delivery.
   TCP is the obvious current choice, but others such as Multipath TCP
   (MPTCP) and the Stream Control Transmission Protocol (SCTP) would
   be applicable as well.  Latency requirements for control message delivery
   must also be evaluated.
   ...
   I2NSF needs to rely on the use of standard I2NSF 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.

to:
   ...
   Therefore, the transport mechanism used to carry management data and
   information must be secure. It does not have to be a reliable
   transport; rather, a transport-independent reliable messaging
   mechanism is required, where communication can be performed reliably
   (e.g., by establishing end-to-end communication sessions and by
   introducing explicit acknowledgement of messages into the
   communication flow). Latency requirements for control message
   delivery must also be evaluated. Note that monitoring does not
   require reliable transport.
   ...
   The network connection between the I2NSF Controller and NSFs will
   use the trusted connection mechanisms described in section 6.1.
   Following these mechanisms, the connections need to rely on the use
   of properly verified 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.

In addition, please see other changes to this thread (yesterday and this
morning, local time Singapore)

best regards,
John

On Tue, Oct 24, 2017 at 3:48 PM, Daniel Franke  wrote:

> Reviewer: Daniel Franke
> Review result: Not Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments
> were written primarily for the benefit of the security area directors.
> Document
> editors and WG chairs should treat these comments just like any other last
> call
> comments.
>
> This document is too broad and too vague for any reasonable security
> review to
> be possible. It expresses a desire to define a framework which satisfies
> certain requirements and use cases, but does not actually define anything
> concrete. At its most specific, the document gives parametricity
> constraints
> that future definitions must satisfy, such as being agnostic to network
> topology. This doesn't give me much to go on.
>
> The security considerations section is brief, calling out the need for
> access
> control and for protecting the confidentiality and integrity of data.
> Again,
> with so few specifics, there's not much more to be said.
>
> I do not think it is useful to anyone to publish this document as an RFC,
> not
> even an informational one. It is perfectly fine, when specifying an
> intricate
> suite of protocols, to have a separate document that gives a broad
> architectural overview of them all without delving into the specifics
> necessary
> for

Re: [I2nsf] Secdir telechat review of draft-ietf-i2nsf-framework-08

2017-10-25 Thread Linda Dunbar 
Daniel, 

Thank you for your time reviewing this document. Obviously our opinions on the 
value of publication are different from the WG consensus. 
The draft-ietf-i2nsf-framework describes the framework that glues together 
multiple detailed drafts describing different aspects of Interface to Network 
Security functions, such as   draft-ietf-i2nsf-capability-00,  
draft-abad-i2nsf-sdn-ipsec-flow-protection-03, 
draft-hares-i2nsf-capability-data-model-04, 
draft-kim-i2nsf-nsf-facing-interface-data-model-03, etc. 

In addition, several recent industry initiatives are referencing I2NSF to guide 
their next step work. Such as ONUG (Open Network User Group) Software Defined 
Security Services and Linux Foundation’s OSC (Open Security Controller).  This 
is one example that IETF is leading the industry.
Without publishing draft-ietf-i2nsf-framework, it is not easy for the industry 
other initiatives to utilize the specifications (in many pieces) published by 
IETF. 

Linda Dunbar


-Original Message-
From: Daniel Franke [mailto:dafra...@akamai.com] 
Sent: Tuesday, October 24, 2017 5:49 PM
To: sec...@ietf.org
Cc: i2nsf@ietf.org; draft-ietf-i2nsf-framework@ietf.org; i...@ietf.org
Subject: Secdir telechat review of draft-ietf-i2nsf-framework-08

Reviewer: Daniel Franke
Review result: Not Ready

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG. These comments 
were written primarily for the benefit of the security area directors. Document 
editors and WG chairs should treat these comments just like any other last call 
comments.

This document is too broad and too vague for any reasonable security review to 
be possible. It expresses a desire to define a framework which satisfies 
certain requirements and use cases, but does not actually define anything 
concrete. At its most specific, the document gives parametricity constraints 
that future definitions must satisfy, such as being agnostic to network 
topology. This doesn't give me much to go on.

The security considerations section is brief, calling out the need for access 
control and for protecting the confidentiality and integrity of data. Again, 
with so few specifics, there's not much more to be said.

I do not think it is useful to anyone to publish this document as an RFC, not 
even an informational one. It is perfectly fine, when specifying an intricate 
suite of protocols, to have a separate document that gives a broad 
architectural overview of them all without delving into the specifics necessary 
for implementation. RFC 4251, which outlines the SSH protocol, is a good 
example of this. But, crucially, RFC 4251 was published simultaneously with 
4252-4256, which provided all those specifics. This document has nothing 
similar as a companion; everything it describes is simply aspirational. I do 
not see any value in publishing an RFC full of unfulfilled aspirations.

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

Re: [I2nsf] Secdir telechat review of draft-ietf-i2nsf-framework-08

2017-10-25 Thread Linda Dunbar 
Daniel, 

Thank you for your time reviewing this document. Obviously you opinions on the 
value of publication are different from the WG consensus. 
The draft-ietf-i2nsf-framework describes the framework that glues together 
multiple detailed drafts describing different aspects of Interface to Network 
Security functions, such as   draft-ietf-i2nsf-capability-00,  
draft-abad-i2nsf-sdn-ipsec-flow-protection-03, 
draft-hares-i2nsf-capability-data-model-04, 
draft-kim-i2nsf-nsf-facing-interface-data-model-03, etc. 

In addition, several recent industry initiatives are referencing I2NSF to guide 
their next step work. Such as ONUG (Open Network User Group) Software Defined 
Security Services and Linux Foundation’s OSC (Open Security Controller).  This 
is one example that IETF is leading the industry.
Without publishing draft-ietf-i2nsf-framework, it is not easy for the industry 
other initiatives to utilize the specifications (in many pieces) published by 
IETF. 

Linda Dunbar


-Original Message-
From: Daniel Franke [mailto:dafra...@akamai.com] 
Sent: Tuesday, October 24, 2017 5:49 PM
To: sec...@ietf.org
Cc: i2nsf@ietf.org; draft-ietf-i2nsf-framework@ietf.org; i...@ietf.org
Subject: Secdir telechat review of draft-ietf-i2nsf-framework-08

Reviewer: Daniel Franke
Review result: Not Ready

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG. These comments 
were written primarily for the benefit of the security area directors. Document 
editors and WG chairs should treat these comments just like any other last call 
comments.

This document is too broad and too vague for any reasonable security review to 
be possible. It expresses a desire to define a framework which satisfies 
certain requirements and use cases, but does not actually define anything 
concrete. At its most specific, the document gives parametricity constraints 
that future definitions must satisfy, such as being agnostic to network 
topology. This doesn't give me much to go on.

The security considerations section is brief, calling out the need for access 
control and for protecting the confidentiality and integrity of data. Again, 
with so few specifics, there's not much more to be said.

I do not think it is useful to anyone to publish this document as an RFC, not 
even an informational one. It is perfectly fine, when specifying an intricate 
suite of protocols, to have a separate document that gives a broad 
architectural overview of them all without delving into the specifics necessary 
for implementation. RFC 4251, which outlines the SSH protocol, is a good 
example of this. But, crucially, RFC 4251 was published simultaneously with 
4252-4256, which provided all those specifics. This document has nothing 
similar as a companion; everything it describes is simply aspirational. I do 
not see any value in publishing an RFC full of unfulfilled aspirations.

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