Hello,
Thank you for your work on this document! I know it underwent many
revisions and it can be difficult to merge text pulling together ideas
from numerous contributors. The draft is well written and easy to
understand, thank you for all your hard work, it shows!
Now to a few comments I'd like to see if we can clear up before
starting last call.
Section 5 begins with the following text:
An important concept underlying this framework is the fact that
attackers do not have standards as to how to attack networks, so it
is equally important to not constrain NSF developers to offering a
limited set of security functions. In other words, the introduction
of I2NSF standards should not make it easier for attackers to
compromise the network.
I think the first sentence could be safely dropped and the second
sentence altered to something like the following:
A basic tenet in the introduction
of I2NSF standards is that he standards should not make it easier
for attackers to
compromise the network.
You may get comments on the following point, also in section 5:
o Be seen as endorsing a best common practice for the implementation
of NSFs
But, I am not going to suggest a change yet. I could see further
explanation being needed for the text.
Section 7.1
I'd suggest using a different example for the time constraints, a
business one would be better. The one listed for a home user could
have the reader jump to censorship concerns if this is targeted to
home users. How about an ERP system is allowed to be accessed from
the corporate network only during business hours for a high privileged
class of users? Outside of the times could indicate an attack and
you'd want that access approved if there was an extenuating
circumstance.
Do you plan to allow for rule setting to be extended to home users? I
think that will raise concern as I thought scope was limited to
enterprises with cloud service offerings.
Section 8:
s/I2NSF system can explose/I2NSF system can expose/
Section 11.
Since this is the framework, the security considerations are fine, but
you do need to add a privacy considerations section. I can see a few
possible privacy concerns and there may be more that I am missing.
Privacy of end users with the reporting options. If all of the fields
described in section 10 could be used in reports, you have a lot of
interesting tracking information that is now easily accessible with
quick reports. The ability to leave out identifying information will
be important as will having ways to protect that data at rest as well
as in transit.
I2NSF could also be used in targeted ways toward individuals in attack
scenarios, both an invasion of privacy and a security consideration
for the attack possibilities. If home use is not out-of-scope, you'll
have real issues here and it will be really hard to tackle the
security and privacy concerns.
The I2NSF user information could be sensitive too - meaning the person
doing provisioning. What protects their account information (I think
you have this covered), you may want to state it for privacy reasons.
Thanks!
--
Best regards,
Kathleen
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
