Hello,
Thank you for your work on this draft. I can see that a lot effort
has gone into it from the beginning of the I2 NSF work. I have some
recommendations for changes before starting IETF last call. I hope
you find these comments helpful to improve the document.
Section 3.1.9:
Are there more details on the security requirements around #3:
3. Automated Key management must support both symmetric keys and
group keys via the service provided by items 1 and 2.
Section 3.2: The work in DOTS is limited to DDoS and not all attack
types and the following text reads as if it were all attack types:
"o Which critical communications are to be preserved during critical
events (DOTS working group is standardizing),
o Which hosts are to continue service even during severe security
attacks (DOTS working group is standardizing),"
Once I reached section 3.2.2, the bulleted section felt redundant. I
don't think the text was explicitly stated elsewhere, but the positive
direction of the same material is expressed and that should be enough
IMO. This is just an opinion to consider if you'd like to tighten up
the document a bit.
The last paragraph of 3.2.2 could be argued as a selling point to
differentiate between another firewall vendor. Object oriented
configuration tools were my personal favorite. This was provided
through an interface that would generate the configs to push out to
multiple firewalls. It can be a selling point to be different. You
may be better off dropping this claim.
Section 3.2: Is efficiency the word you intended in the following
sentence or was it some other property?
The customer also
lacks the ability to perform "what-if" scenarios to assess the
efficiency of the delivered security service.
Section 3.2.3: Could you break the last sentence into 2? And do you
mean efficiency or something else?
It is the objective of the I2NSF work to provide a standard way to
get security service assurance of a customers specific security
policies which provides enough information for customers to perform
"what-if" scenarios to assess efficiency of delivered security
services.
Section 3.3 also feels repetitive. Reducing text in the earlier
section will help to resolve this issue.
Section 4.2: The begininning of this screams of censorship. Although
your intended use case is innocent enough with parental controls,
there is lots of opportunity for abuse expanding to other types of
censorship we don't typically support in protocols. I recommend
reducing this to the threat management descriptions.
OLD:
Residential: service requests for parental control, content
management, and threat management.
Parental control requests may include identity based filters for
web content or usage. Content management may include identifying
and blocking malicious activities from web contents, mail, or
files downloaded. Threat management may include identifying and
blocking botnets or malware.
NEW:
Residential: service requests for threat management.
Threat content management may include identifying
and blocking malicious activities from web contents, mail, or
files downloaded. Threat management may also include identifying and
blocking botnets or malware.
Enterprise section: I recommend that you also tighten up this language
so it is not about content censorship in any way.
access to (or isolation from)
various web sites or social media applications
Section 4.3.2:
I'm having a little trouble with the following sentence and think the
point is made in the previous 2 sentences, so I think it is safe to
drop:
Without automation, it is virtually
impossible for clients to dynamically specify their desired rules for
their traffic.
Then the following sentence is more of a requirement, but is in the
use case section, so should it be written a little differently?
Another feature that aids automation of firewalls that must be
covered in automation is dynamic key management.
Section 4.3.4: I wouldn't refer to DLP as a 'new' class of service.
Nits:
General - check acronyms to just expand on first use. I think there
are a few cases where acronyms are redefined multiple times in the
document.
Section 3.1.1
s/IP-sec gateways/ IPsec gateways/
Last sentence in this section could be written more clearly, I get
what it is saying, but it could be improved:
'There exist various network security monitoring
vendor-specific interfaces for forensics and troubleshooting.'
Section 3.1.9
s/IPSec/IPsec/
Section 3.4: Last line
s/raise raise/raise/
Section 3.5:
s/standrd/standard/
Section 4.3.2
I think this is the first place I saw FWs in the docuemnt. It's easy
enough to just spell it out, so please do!
--
Best regards,
Kathleen
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
