Subject: [I2nsf] AD review of draft-ietf-i2nsf-problem-and-use-cases

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 17 Feb 2017 22:07:38 -0500

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

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 18 Feb 2017 08:05:22 -0500

Kathleen: 

Thank you for these comments. I will work on a revision of the document to
address these points.   I hope to have the new draft on Monday. 

Sue Hares

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Friday, February 17, 2017 10:08 PM
To: [email-masked]
Subject: [I2nsf] AD review of draft-ietf-i2nsf-problem-and-use-cases

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:

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:

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

Section 3.2.3: Could you break the last sentence into 2?  And do you mean
efficiency or something else?

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:

NEW:

Enterprise section: I recommend that you also tighten up this language so it
is not about content censorship in any way.

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:

Then the following sentence is more of a requirement, but is in the use case
section, so should it be written a little differently?

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

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-masked]
https://www.ietf.org/mailman/listinfo/i2nsf