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

["Susan Hares" <[e-mail]>]

Kathleen: 

Time is moving toward the deadline.  I will check the abbreviations and
grammar and submit this draft as a response. 

Sue 

-----Original Message-----
From: I2nsf [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Saturday, March 4, 2017 6:41 PM
To: 'Kathleen Moriarty'; '[e-mail]'
Subject: Re: [I2nsf] AD review of draft-ietf-i2nsf-problem-and-use-cases

Kathleen: 

Would you let me know if this is on the right track.  I will go through and
check all abbreviations and grammar - but I wanted to make sure this works
for you.  I've attached a diff as well between 9 and 10. 

Sue 

-----Original Message-----
From: I2nsf [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
Sent: Friday, February 17, 2017 10:08 PM
To: [e-mail]
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.

#1 - section 3.1.9 

>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.

Replacement: 
           3 Automated Key management MUST support both symmetric keys and
              group keys via the abstract key service provided by items 1
and 2. 
              I2NSF controllers within the NSF required to exchange data
with NSFs
              may exchange data with individual NSFs using individual
symmetric keys or 
              with a group of NSFs simultaneously using an IP group address 
              secured by a group security key(s).  


Section 3.2 top 
>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),"

Replaced with: 
            Which critical communications are to be preserved during
            critical events and which hosts are continue service,<

            What signaling information is passed to a controller that
            during a Distributed Denial of Service in order to ask for 
             mitigation services (within the scope DOTS working group),


#3 - section 3.2.2 

>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.


#4 - section 3.2.2. 

>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.

New Paragraph - at end of 3.2.2
New:/In contrast, as figure 1 shows, if a firewall/IPS interface standard
exists the customer would be able to send the request to a security
management system  and the security management would send it via a I2NSF
standard interface. 
Service providers could now utilize the same standard interface interface to
represent firewall/IPS services implemented using products from many
vendors.
/

#5 Section 3.2:  Is efficiency the word you intended in the following
sentence or was it some other property?

Old/   The customer also
   lacks the ability to perform "what-if" scenarios to assess the
   efficiency of the delivered security service.
/
New/ The customer also lacks the ability to perform 
     "what-if" scenarios to assess the efficacy of the delivered security
service. 
     /

Comment: Efficacy - indicates both efficiency and ability to correctly
perform the work. 


#6 - Section 3.2.3: Could you break the last sentence into 2?  And do you
mean efficiency or something else?
I've re-written this section: 
 
/New:
3.3  Difficult to Monitor the Execution of Desired Policies 

          How a policy is translated into technology-specific actions is
          hidden from the customers. However, customers still need ways to
          monitor the delivered security service that results from the
          execution of their desired security requirements, guidelines and
          expectations.  Customers want to monitor existing policies to
determine 
          such things as: which policies are in effect, how many security
attacks are being 
          prevented, and how much bandwidth efficiency does security
enforcement cost. 
	
         Today, there is no standard way for customers to get these details 
          from the security service which assure the customer that their 
          specified security policies properly enforced by the security
functions
          in the provider domain. 
	
          Getting this monitoring information from the security system also
helps 
          the customer to plan for the future using "what-if" scenarios
          with real data. A tight loop between the data gathered from
security 
          systems and the "what-if" scenario planning can reduce the 
          time to design and deploy workable security policies that deal
with new threats. 

        It is the objective of the I2NSF work to provide a standard way 
        to get the information that security service assurance systems need
to 
        provide customers an evaluation about the current security systems,
and 
        to quickly plan for future security policies using "what-if"
scenarios
        based on today's information
/

Sue: Could you provide me feedback on this text?  

#7 - Section 3.3 also feels repetitive.  Reducing text in the earlier
section will help to resolve this issue.

Sue: I've re-ordered section 3 to try to address your concerns.  


-------------------
#8 - Section 4.2: The beginning 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.
/
Sue: I've changed to your text. 


#9 - 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

Enterprise: "service requests for enterprise flow security policies and
managed security services
			
            Flow security policies identify and block malicious activities
            during access to (or isolation from) web sites or social media
applications.  
	Managed security services for an enterprise may include detection 
            and mitigation of external and internal threats.  
	External threats can include application or phishing attacks,
malware,
	botnet, DDoS, and others.

#10 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.

Sue: Merged last 2 paragraphs to: 

         Even though most vendors support similar firewall features, the
          actual rule configuration keywords are different from vendors to
          vendors, making it difficult for automation. Automation works best
          when it can leverage a common set of standards that will work
across
          NSFs by multiple vendors and utilize dynamic key management.  

#11 - Section 4.3.4: I wouldn't refer to DLP as a 'new' class of service.
Removed


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