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.
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.
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.
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 ...
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...
...
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.
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.
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.
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.
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@xxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/i2nsf
--
regards,
John