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

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 <dafranke@akamai.com> 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 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
>

-- 
regards,
John