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

[Dale Worley <[e-mail]>]

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]