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]