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]