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

[Kathleen Moriarty <[e-mail]>]

Hi Sue,

Thanks for your work updating the draft.  I'll respond inline just
where I have a comment.  Most updates look great, so thanks for that.

On Tue, Mar 7, 2017 at 11:34 AM, Susan Hares <[e-mail]> wrote:
> 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,<

Can you fix the grammar at the end of this phrase (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.
>      /

Thanks!

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

Looks good, thank you!

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

Thanks, I think you'll need to add in mention of the "enterprise" as
even this type of filtering on the Internet and outside of Enterprise
restrictions wouldn't be acceptable.  Even then, we may have a hard
time in last call and IESG review.

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

This is better, thanks.

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

Looks good, thanks.

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


Thanks, Sue!  I didn't have time to look at the draft, just the text
provided and we are close, thanks!
-- 

Best regards,
Kathleen