Dale:
Thank you for the review. Please see my comments below.
Sue
-----Original Message-----
From: I2nsf [mailto:i2nsf-bounces(_at_)ietf(_dot_)org] On Behalf Of Dale Worley
Sent: Tuesday, March 14, 2017 6:17 PM
To: gen-art(_at_)ietf(_dot_)org
Cc: i2nsf(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-i2nsf-problem-and-use-cases(_dot_)all(_at_)ietf(_dot_)org
Subject: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11
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].
Dale
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.
Thank you for finding these errors. I also needed to change
I-D.hares-i2nsf-gap-analysis to draft-ietf-i2nsf-gap-analysis.
3. Problem Space
The following sub-section describes ...
s/sub-section describes/sub-sections describe/
Thank you - sorry to have missed it.
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.
I've added this text: Security Service Provider: A provider of security
services to the customers (end-users or enterprises) using NSF equipment
purchased from vendors or created by the service provider.
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.
Good catch. I will fix.
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.
Good point. I will fix.
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.
New paragraph is below. Is it better
New/
A challenge for monitoring prior to mitigation of a security intrusion
is that an NSF cannot monitor what it cannot view. Therefore, enabling a
security function to mitigate an intrusion
(e.g., firewall <xref target="I-D.ietf-opsawg-firewalls"></xref>)
does not mean that a network is protected if there is no monitoring
feedback.
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, but an industry standard interface could
provide monitoring across avariety of NSFs.
/
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.
Thanks for catching this - I will fix it.
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.
Thanks for catching this vagueness.
The point the service provides may have to deploy multiple controllers.
How about:
Service providers may need to deploy several NSF controllers to control and
monitor the NSFs, especially when NSFs become distributed and
virtualized.
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".
[removed "to perform")
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).
All good comments, but my recollection was the WG wanted to underscore the
strategy was good for all parties.
Therefore, here's the new paragraph
New/
Today, black list databases can be a beneficial
strategy for all parties involved, but in the future there might be
open Source-provided signature/profiles distributed as part of IDS systems
(e.g., by Snort, Suricata, Bro and Kismet).
/
--
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.
This part hit many discussions. How about
New/ There is a need to have a standard envelope (i.e., a message 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 ...".
New/ I2NSF controller(s) would control any changes to affected policies
(e.g., forwarding and routing, filtering, etc.)./
The I2NSF controls the change (whether others change the policies or not).
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.
New/
By monitoring the network alerts regarding DDoS attacks (e.g. from DOTS
servers or clients),
the I2NSF controller(s) can feed an alerts analytics engine
that could recognize attacks so the I2NSF can enforce the
appropriate policies.
/
... 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.
New/ DDoS mitigation is enhanced if the provider's network security
controller can monitor, analyze, and investigate the abnormal
events
and provide information to the customer or change the network
configuration automatically
/
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.
I've made this change.
In addition, keys may be used to secure
the protocol and messages in the core routing infrastructure (see
[RFC4948])
Probably s/protocol/protocols/.
I've made this change.
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.
New sentences:
/ If a device had an abstract key table maintained by security services, it
could use these
keys for routing and security devices. /
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".
Grammatically - I disagree . The clauses "to make request...." and "to
notify" are infinitive clauses which modify the direct object (an interface)
which are linked together in a list.
However, rather than debate this syntax with others - I've changed the
syntax to a cl
New/
Conceptually, there must be an interface defined for routing/signaling
protocols
that can: a) make requests for automated key management when it is being
used. and
b) notify the protocols when keys become available in the key table.
/
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)?
The WG felt it needed an example here. If it is OK, I'm going to leave
this in for another round of editing.
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.
Thank you. I've changed to this sentence.
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/
--Thank you.
I think "via the abstract key service provided by items 1 and 2" is
redundant here.
It may be redundant, but as I recall it was important to some of the
authors.
--------------
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.
New/Which critical communications are to be preserved during
critical events and which hosts will continue services over the
network,/
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.
Removed.
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"?
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.
Thank you.
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/
Note: Sentence was removed.
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?)
Not this one. I'm afraid I rushed the -11 out in response to query. I
lived to regret this fact.
... 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".
Noun is NSFs
Hosted security service may instantiate NSFs in Virtual Machines
You probably don't want to capitalize "virtual machines" here.
Changed.
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.)
The text should be "to set up" an infinitive verb setting up an infinitive
clause, or it can be considered a prepositional phrase "to set up ..."
Anyway, thank you for the editing.
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".
Start here
-----------------
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.
Dale: While this make be clearer, it was the WGs final comments. I'll see
what the IESG says.
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".
Sue: Fixed
These use cases define the interaction between the operator and the
vNSFs through automated interfaces, typically by means of
Business- to-Business (B2B) communications.
Dale: 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.
New/These use cases define the interaction between the operator and the
vNSFs through automated interfaces which support the business
communications
between customer and provider or between two business entities./
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.
Sue: Service Provider added to the network
... 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 ...
Sue: Thank you - changed.
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".
Done - split off the second 2 sentences.
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.)
Done - corrected to "forms"
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)?
Sue: Good point.
New /
Another example is that IPS/IDS services which splits traffic into
investment banking traffic and other data traffic to comply with
regulatory restrictions for transfer of investment banking information/
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".
Sue:
New/
Even though most vendors support similar firewall features, the
specific rule configuration keywords are different from vendors to
vendors, making it difficult for automation.
/
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.
Sue: You are right. The negation in the sentence makes this difficult.
New /Clients of service provider-operated cloud data centers
need to secure Virtual Private Networks (VPNs) and virtual
security functions that apply the clients' security policies./
Now the direct objection into a list (VPNs + virtual security functions).
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.)
Changed to:/
Many networks
which carry groups of information (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 remote attacks. There are many examples of
remote attacks on these networks, but the following examples will illustrate
the
issues. A malware attack on an IoT network which carries sensor readings and
instructions may attempt to
alter the sensor instructions in order to disable a key sensor.
A malware attack VoIP or VoLTE networks is software that attempts to place
unauthorized
long-distance calls. Botnets may overwhelm nodes in ICN and CDN networks so
that
the networks cannot pass critical data.
/
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/!
Thanks for noticing.
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.
I will ask the RFC Editor about this point.
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.
Agreed,
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.
Good catch.
_______________________________________________
I2nsf mailing list
I2nsf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/i2nsf