Re: [Gen-art] Review of draft-ietf-i2nsf-problem-and-use-cases-11

[Alissa Cooper <[e-mail]>]

Dale, thank you for your review. Sue, thanks for your engagement with Dale’s review.

I will be ballotting ABSTAIN as I agree with the assessment from Alvaro and Mirja.

Alissa

> On Mar 14, 2017, at 6:16 PM, Dale Worley <[e-mail]> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> Document:  draft-ietf-i2nsf-problem-and-use-cases-11
> Reviewer:  Dale R. Worley
> Review Date:  2017-03-14
> IETF LC End Date:  2017-03-22
> IESG Telechat date:  [unknown]
> 
> Summary:
> 
>       This draft is basically ready for publication, but has nits
>       that should be fixed before publication.
> 
> All of these nits are editorial.
> 
> 1.  Introduction
> 
>   This document describes the problem statement for Interface to
>   Network Security Functions (I2NSF) as well as some I2NSF use
> cases.
>   A summary of the state of the art in the industry and IETF which
> is
>   relevant to I2NSF work is documented in
>   [I-D.hares-i2nsf-gap-analysis].
> 
> The content of these sentences is very good, but the construction
> seems to be peculiar.  The document doesn't *describe* the problem
> statement, the document *is* a statement.  Similarly,
> hares-i2nsf-gap-analysis *is* a summary of the state of the art.  So
> I
> would use
> 
>   This document is the problem statement for Interface to Network
>   Security Functions (I2NSF) as well as some I2NSF use cases.  A
>   summary of the state of the art in the industry and IETF which is
>   relevant to I2NSF work is [I-D.hares-i2nsf-gap-analysis].
> 
> But maybe you'll prefer to ask the RFC Editor.
> 
>   This document also briefly describes the
>   following use cases summarized by
>   [I-D.pastor-i2nsf-merged-use-cases]:
> 
> This sentence should start a new paragraph, as it's not connected to
> the sentences before it.
> 
> 3.  Problem Space
> 
>   The following sub-section describes ...
> 
> s/sub-section describes/sub-sections describe/
> 
> 3.1.1.  Diverse Types of Security Functions
> 
>   NSFs by different vendors can have
>   different features and have different interfaces.
> 
> It might be worth mentioning somewhere what seems to be a convention:
> the document (or at least, section 3.1) is largely oriented toward
> "service providers" who sell comprehensive network services
> (including
> security functions) to "customers", but who in turn buy security
> functions from "vendors".  Perhaps this could be entered as
> terminology in section 2.
> 
> The reason I mention this is that my background is as an end-user
> (which is common in the IETF), so the term "service provider"
> triggers
> in my mind the idea "someone I buy something from".  And the term
> "vendor" triggers the *same* idea.  But in this draft, the default
> reader is a "service provider" and "vendor" is *not* the same thing.
> 
> This point started to confuse me at the beginning of section 3.1.6.
> 
>   Security Functions in a Demilitarized Zone (DMZ):   Examples of
> this
>      function are firewall/ACLs, IDS/IPS, one or all of AAA services
>      NAT, forwarding proxies, and application filtering.
> 
> The phrase "one or all of AAA services NAT" seems to be incorrect.  I
> suspect there's supposed to be a comma before NAT.
> 
>   Security gateways and VPN concentrators:    Examples of these
>      functions are; IPsec gateways, Secure VPN concentrators that
>      handle bridging secure VPNs, and Secure VPN controllers for
> data
>      flows.
> 
> Unless "Secure VPN" is a name in itself, "secure" shouldn't be
> capitalized.
> 
> 3.1.2.  Diverse Interfaces to Control and Monitor NSFs
> 
>   A challenge for monitoring is that an NSF cannot monitor what it
>   cannot view.  Therefore, enabling a security function (e.g.,
> firewall
>   [I-D.ietf-opsawg-firewalls]) does not mean that a network is
>   protected.  As such, it is necessary to have a mechanism to
> monitor
>   and provide execution status of NSFs to security and compliance
>   management tools.  There exist various network security monitoring
>   vendor-specific interfaces for forensics and troubleshooting.
> 
> This paragraph seems awkward.  Each sentence is reasonable, but the
> connection between them is not clear to me.  Perhaps the third
> sentence has the meaning "... it is necesary to have a mechanism
> ...to
> verify that the NSF is seeing the traffic that is intended".
> 
> The last sentence contains "network security monitoring
> vendor-specific interfaces" which is awkward.  Perhaps
> 
>   There exist various vendor-specific interfaces for network
> security
>   monitoring, forensics, and troubleshooting.
> 
> 3.1.4.  More Demand to Control NSFs Dynamically
> 
>   The Security Service Providers ...
> 
> The capitalization of "security service providers" is inconsistent.
> Some times all three words are capitalized, and some times they're
> not.
> 
> 3.1.5.  Demand for Multi-Tenancy to Control and Monitor NSFs
> 
>   Service providers may need several operational units to control
> and
>   monitor the NSFs, especially when NSFs become distributed and
>   virtualized.
> 
> You may want to explain what an "operational unit" is.  As far as I
> can tell, neither "unit" nor "operational" (in this sense) is used
> elsewhere in this draft.
> 
> 3.1.7.  Lack of Mechanism for NSFs to Utilize External Profiles
> 
>   Many security functions depend on signature files or profiles to
>   perform (e.g., IPS/IDS signatures, DDos Open Threat Signaling
> (DOTS)
>   filters).  
> 
> I think the words "to perform" should be removed.  The sentence makes
> more sense to me without those.  Or, if there is a meaning that needs
> to be specified, "to perform" probably isn't the right choice.  "to
> work" makes sense in this place, but is an informal usage.  Perhaps
> "to function".
> 
>   Today, the construction and use of black list databases
>   can be a win-win strategy for all parties involved.
> 
> "win-win strategy" is a hackneyed phrase.  This is better
> 
>   Today, the construction and use of black list databases
>   can be beneficial for all parties involved.
> 
> However, it's not clear to me what additional information is carried
> by "for all parties involved".  And for that matter, is "today"
> important here?
> 
> I suspect that you mean something like this:
> 
>   Today, black list databases can be beneficial, and in the future
>   there might be open source signatures/profiles ...
> 
> --
> 
>   (e.g., by Snort, Suricata, Bro and Kisnet)
> 
> s/Kisnet/Kismet/
> 
> "Snort, Suricata, Bro and Kisnet" reads like a reference -- I had to
> look them up to discover that they are IDS software!
> 
> But there needs to be some connection between a list of IDS software
> systems and "open source signatures/profiles".  Perhaps:
> 
>   Today, black list databases can be beneficial, and in the future
>   there might be open source signatures/profiles distributed as part
>   of IDS systems (e.g. Snort, Suricata, Bro and Kisnet).
> 
> --
> 
>   There is a need to have a standard envelope (i.e., the format) to
>   allow NSFs to use external profiles.
> 
> This is awkward.  Perhaps
> 
>   There is a need to have a standard format to allow NSFs to use
>   external profiles.
> 
> 3.1.8.  Lack of Mechanisms to Accept External Alerts to Trigger ...
> 
>   I2NSF controller(s) would manage the changing to the affected
>   policies ...
> 
> This could be simplified to "I2NSF controller(s) would change the
> affected policies ...".
> 
>   By monitoring the network alerts from DDoS ...
> 
> Probably s/DDoS/DOTS/.
> 
>   ... I2NSF
>   can feed an alerts analytics engine that could recognize attacks
> so
>   the I2NSF can enforce the appropriate policies.
> 
> Here, "I2NSF" is being used as a noun, whereas the previous usage is
> that it is an adjective, and "I2NSF controller(s)" would be used.
> 
>   ... provide information to the client ...
> 
> I think this is clearer if s/the client/its clients/.  "client" is
> used with two meanings, one is "customer" (e.g., in the definition of
> "Bespoke"), and more commonly as "software client".  If you say "[the
> controller's] clients", it is clear that you're using the second
> meaning.
> 
> 3.1.9.  Lack of Mechanism for Dynamic Key Distribution to NSFs
> 
>   There is a need for a controller to distribute various keys to
>   distributed NSFs.  To distribute various keys, the keys must be
>   created and managed.
> 
> Perhaps combine these as
> 
>   There is a need for a controller to create, manage, and distribute
>   various keys to distributed NSFs.
> 
> --
> 
>   In addition, keys may be used to secure
>   the protocol and messages in the core routing infrastructure (see
>   [RFC4948])
> 
> Probably s/protocol/protocols/.
> 
>   If a device had an abstract key table
>   maintained by security services, a device could use these keys for
>   routing and seurity devices.
> 
> s/seurity/security/
> 
> Typical English usage in this situation is "it could use ...";
> because
> "it" is the subject of the second clause, it is presupposed to be the
> same as the subject of the first clause.
> 
>   Conceptually, there must be an interface defined for routing/
>   signaling protocols to make requests for automated key management
>   when it is being used, and to notify the protocols when keys
> become
>   available in the key table.  One potential use of such an
> interface
>   is to manage IPsec security associations on SDN networks.
> 
> I think you need to add a subject in "... and for XXX to notify the
> protocols ..." for clarity, the omitted noun could be "interface" or
> "protocols".
> 
> The last sentence seems redundant, as security associations have been
> discussed at the beginning of 3.1.9.  Is there a particular reason to
> point out IPsec at this point (since many secured protocols need
> keys)?
> 
>       If protocols share
>       common mechanisms for authentication (e.g., TCP Authentication
>       Option [RFC5925]), then the same mapping may be reused.
> 
> This sentence starts with "protocols [that] share common mechanisms"
> but then mentions only one protocol.  Do you mean
> 
>       If several protocols share a
>       common mechanism for authentication (e.g., TCP Authentication
>       Option [RFC5925]), then the same mapping may be used for all
>       usages of that mechanism.
> 
> --
> 
>   3.  Automated Key management needs to support both symmetric keys
> and
>       group keys via the abstract key service provided by items 1
> and
>       2.
> 
> s/Key/key/
> 
> I think "via the abstract key service provided by items 1 and 2" is
> redundant here.
> 
> 3.2.  Challenges Facing Customers
> 
>   o  Which critical communications are to be preserved during
> critical
>      events and which hosts are continue service,
> 
> "are continue service" seems to be incorrect in some way.
> 
>   o  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),
> 
> "that" should be removed, I think.
> 
> 3.2.2.  Today's Control Requests are Vendor Specific
> 
>   Without a standard technical
>   standard interface that provides a clear technical
> characterization,
>   the service provider faces many challenges:
> 
> Should "standard technical standard interface" be "standard
> interface"
> or "standardized interface"?
> 
>   No standard technical characterization, APIs, or Interface
> 
> I think you want a colon after this phrase to parallel the other
> items
> in the list.
> 
>   Managing by scripts de-jour:    The current practices rely upon
> the
>      use of scripts that generate other scripts which automatically
> run
>      to upload or download configuration changes, log information
> and
>      other things.  These scripts have to be adjusted each time an
>      implementation from a different vendor technology is enabled on
> a
>      provider side.
> 
> The phrase "on a provider side" doesn't read well.  Perhaps "by a
> service provider"?
> 
> 3.3.  Lack of Standard Interface to Inject Feedback to NSF
> 
>   The following sub-section describes the problems and challenges
>   facing customers and security service providers when some or all
> of
>   the security functions are no longer physically hosted by the
>   customer's adminstrative domain.
> 
> s/adminstrative/administrative/
> 
>   As more sophisticated threats arise, enterprises, vendors, and
>   service providers have to rely on each other to achieve optimal
>   protection.  Cyber Threat Alliance (CTA,
>   http://cyberthreatalliance.org/) is one of those initiatives that
> aim
>   at combining efforts conducted by multiple organizations.
> 
> This paragraph doesn't fit well in the flow of the text.  The second
> sentence seems like it's basically a reference, and the link should
> be
> put down in the references.  But I think the point resembles the
> discussion in 3.1.7, that you want to enable organizations to pass
> among themselves new profiles, which the customers or service
> providers can insert into NSFs in a simple way.  Perhaps
> 
>   As more sophisticated threats arise, protection will depend
>   on enterprises, vendors, and service providers being able to
>   cooperate to develop optimal profiles, e.g., through initiatives
>   like [CTA].  
> 
> and then combine with the paragraph which follows:
> 
>   The standard interface to provide security profiles to the NSF
> should
>   interwork with the formats which exchange security profiles
> between
>   organizations.
> 
> 3.5.  Difficulty to Validate Policies across Multiple Domains
> 
>   As discussed in the previous four sections, both service providers
> ...
> 
> Probably s/sections/sub-sections/.
> 
>   ... and customers have needs to express policies and profiles ...
> 
> s/needs/need/
> 
>   This section and the next section (section 3.6) xamine what ...
> 
> s/xamine/examine/
> 
> (Have you spell-checked this draft?)
> 
>   ... happens in two specific network scnearios: ...
> 
> s/scnearios/scenarios/
> 
>   a) multi-domain control of
>   security devices hosted on virtual and non-virtual ...
> 
> There is a noun missing after "virtual and non-virtual".
> 
>   Hosted security service may instantiate NSFs in Virtual Machines
>   ...
> 
> You probably don't want to capitalize "virtual machines" here.
> 
>   To
>   set-up this cross-domain service, the security controller must be
>   able to communicate with NSFs and/or controllers within its domain
>   and across domains to negatiate for the services needed.
> 
> s/set-up/set up/  ("set up" is a verb (more or less), "set-up" is the
> action of setting up or the thing which is set up.)
> 
> s/negatiate/negotiate/
> 
> 3.6.  Software-Defined Networks
> 
>   Software-Defined Networks have changed the landscape of data
> center
>   designs by introducing overlay networks deployed over ToR switches
>   that connect to a hypervisor.
> 
> You probably should spell out "ToR switch"; "top of rack switch" is
> not yet listed in Wikipedia as a meaning of "ToR".
> 
> 4.1.  Basic Framework
> 
>   Integrity of the NSF:   by ensuring that the NSF is not
> compromised;
> 
>   Isolation:   by ensuring the execution of the NSF is
> self-contained
>      for privacy requirements in multi-tenancy scenarios.
> 
>   Provenance of NSF:    Customers may need to be provided with
> strict
>      guarantees about the origin of the NSF, its status (e.g.,
>      available, idle, down, and others), and feedback mechanisms so
>      that a customer may be able to check that a given NSF or set of
>      NSFs properly conform to the the customer's requirements and
>      subsequent configuration tasks.
> 
> The punctuation and capitalization is inconsistent between the list
> items here.  I suggest changing the first two to (more or less)
> sentences:
> 
>   Integrity of the NSF:   Ensuring that the NSF is not compromised.
> 
>   Isolation:   Ensuring the execution of the NSF is self-contained
>      for privacy requirements in multi-tenancy scenarios.
> 
> Probably s/Provenance of NSF/Provenance of the NSF/.
> 
>   In order to achieve this, the security controller may collect
>   security measurements and share them with an independent and
> trusted
>   third party (via Interface 1) in order to allow for attestation of
>   NSF functions using the third party added information.
> 
> Would this really be via Interface 1?  It looks like Interface 1 only
> goes to the customer's client, not a 3rd party service, and it is
> used
> for passing security requests.  This is made clearer in the next
> paragraph, but it would probably be better to only say that there
> needs to be an interface to 3rd parties for services like this, and
> it
> may be a variant of Interface 1 or it may be a distinct interface.
> 
> 4.2.  Access Networks
> 
>   Figure 3 shows how these virtual
>   access nodes for different types of customers connect connect
> through
>   virtual access nodes an NSF.
> 
> s/connect connect/connect/
> 
> The grammar of the sentence needs fixing also somewhere near "nodes
> an
> NSF".
> 
>   These use cases define the interaction between the operator and
> the
>   vNSFs through automated interfaces, typically by means of
> Business-
>   to-Business (B2B) communications.
> 
> Is "Business-to-Business (B2B) communications" a technical term?  It
> doesn't seem to me to convey any additional information, since most
> of
> the usages envision that NSFs may be provided by outside vendors, so
> pretty much any communication with an NSF may be business-to-business
> communication.
> 
>   Service Provider:   Service requests for policies that protect ...
> 
> There isn't a "Service Provider" illustrated in the figure.  I assume
> that the Service Provider looks much like the other three cases,
> since
> those look very much like each other, but some sort of illustration
> should be provided.  Especially if the Service Provider has further
> customers (presumably further to the left in the figure), that would
> be a more complex architecture.
> 
>   ... may want to get
>   their dedicated NSFs (most likely vNSFs) for direct control
> purposes.
> 
> This is rather informal usage.  Perhaps better:
> 
>   ... may want to contract separately for dedicated NSFs ...
> 
> --
> 
>   In this case, here are the steps to associate vNSFs to specific
>   customers:
> 
> There are two cases discussed in the paragraph before this sentence,
> and it's not obvious which one this sentence is connected to via "In
> this case".  Or does it apply to both?  If it applies to the second
> case only, I suggest splitting the last two sentences off as a
> separate paragraph.  If this sentence applies to all cases in this
> subsection, I suggest removing "In this case".
> 
> 4.3.  Cloud Data Center Scenario
> 
>   The on-demand, dynamic nature of security service delivery
>   essentially encourages that the network security "devices" be in
>   software or virtual form factors, rather than in a physical
> appliance
>   form.
> 
> I think you want to s/form factors/forms/.  (The phrase "form factor"
> seems to be abused to mean many things.)
> 
>   Another example is that IPS/
>   IDS services for investment banking and non-banking traffic may be
>   separated for regulatory reasons.
> 
> Is "investment banking" specific here, or does this statement also
> apply to "banking" generally?  Or is "non-banking traffic" really
> "non-investment-banking traffic" (in which case calling it "other
> traffic" is probably better)?
> 
> 4.3.2.  Firewall Policy Deployment Automation
> 
>   Even though most vendors support similar firewall features, the
>   actual rule configuration keywords are different from vendors to
>   vendors, making it difficult for automation.
> 
> Probably s/actual rule/specific rule/ or even just "specific".
> 
> 4.3.3.  Client-Specific Security Policy in Cloud VPNs
> 
>   Clients of service provider-operated cloud data centers not only
> need
>   to secure Virtual Private Networks (VPNs), but also [X] virtual
> security
>   functions that apply the clients' security policies.  
> 
> There's an understood verb at the location marked [X].  I think it's
> supposed to be "to secure", and if so, the usage is correct.  But
> it's
> hard to read, so I think it would be better to not omit the verb.
> 
> 4.4.  Preventing Distributed DoS, Malware and Botnet attacks
> 
>   Many networks such as Internet of
>   Things (IoT) networks, Information-Centric Networks (ICN), Content
>   Delivery Networks (CDN), Voice over IP packet networks (VoIP), and
>   Voice over LTE (VoLTE) are also exposed to such attacks.
> 
> This seems to be just a specialization of the preceding sentences.
> Does it add more information?  (E.g., perhaps there are special
> considerations for each of these types of networks, in which case it
> might be useful to state that.)
> 
> 4.5.  Regulatory and Compliance Security Policies
> 
>   Organizations are not only supposed to protect their networks
> against
>   attacks, but they should also adhere to various industry
> regulations:
> 
> It's probably better to s/should also/must also/!
> 
> 7.  Security Considerations
> 
>   Having a secure access to control and monitor NSFs is crucial for
>   hosted security services.
> 
> Probably s/a secure/secure/.
> 
>   Therefore, proper secure communication
>   channels have to be carefully specified for carrying controlling
> and
>   monitoring traffic between the NSFs and their management entity
> (or
>   entities).
> 
> I think you can condense this to "management entity(ies)", but you
> probably should talk to the RFC Editor about it.
> 
>   In addition, the Flow security policies specified by customers can
>   conflict with providers' internal security policies which may
> allow
>   unauthorized traffic or unauthorized changes to flow polices (e.g.
>   customers changing flow policies that do not belong to them).
> 
> I don't think you want to capitalize "flow" here.
> 
> It's not clear to me what "which may allow unauthorized ..." applies
> to.  It seems like there's an important issue in just
> 
>   In addition, the Flow security policies specified by customers can
>   conflict with providers' internal security policies
> 
> It seems that solving I2NSF requires a clear understanding of how the
> customer's policies and the provider's policies interact.  (I would
> think something is allowed only if both policies allow it, but the
> reality may be more complex.)
> 
> The rest of the sentence seems redundant given the discussion in the
> rest of document.
> 
>   Therefore, it is crucial to have proper AAA [RFC2904] to authorize
>   access to the network and access to the I2NSF management stream.
> 
> It seems to me that this is a rather generalized need for I2NSF, and
> not connected to the previous sentences.  So I would omit "Therefore"
> and put it as a separate paragraph.
> 
> [END]
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art