Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases
draft-ietf-i2nsf-problem-and-use-cases-16

[Ballot comment]
The document has been changed to informational.  The ballot writeup was not changed as that would have reset all of the ballots.
The edits made from the initial IESG review have, IMO, significantly helped to improve the document that reads more of a problem statement/overview now and is hopefully a helpful document to anyone coming into the working group or using the work later.

[Ballot comment]
I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons.

[Update: Thanks for addressing my other comment.]

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

[Ballot comment]
I found the document to provide a useful overview and introduction - I think that documents which provide an introduction to a technology are useful, as they set the stage for users and implementers to understand how everything ties together.

I thank the authors for writing it.

I also note that this is part of the I2NSF charter, and was written to satisfy this.

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

[Ballot comment]
I don't see value in the publication of this document in the RFC series. I can see that this document was useful for discussion in the working group but I don't know why it needs to be published as RFC. Also there is quite some redundancy everywhere in the document as well as between the problem statement and use case part. Spelling out requirements for the protocol design based on the analysis of these problems and use cases (which was already a bit attempted from time to time in the doc) would have been more useful but does still not have an archivable value that justifies publication as RFC in the IETF stream (indicating IETF consensus).

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

[Ballot comment]
I agree with Mirja's DISCUSS, which appears to have been mostly addressed. The IESG writeup appears to need updating to match the new document's intended status.

I am voting No Objection rather than Abstaining for the reasons Ben outlines in his No Objection.

[Ballot comment]
Given that the WG charter gave i2nsf the decision about whether to publish as an RFC and that this is Informational, I am fine with this document being published as an RFC.  I think that it will serve as useful background to folks considering the i2nsf work and understanding the motivations for standardizing interfaces that have previously been vendor-specific.

[Ballot comment]
I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons.

I also agree that this should be informational.

I have a few additional comments on the odd chance this draft progresses:

-2:
--  B2B describes a business model. I don't see how that is useful for IETF discussion unless it implies specific technical characteristics. If it does, them please describe them.
Bespoke": In other usages, "bespoke" often implies positive thing, which I don't think the draft intends. I think the work "customized" would better fit the usage herein.

-3: "The "Customer-Provider" relationship may be between any two parties. The parties can be in different firms or different domains of the same firm."
There again seem to be implied business models here. Is it technically relevant if organizations qualify as "firms"?

- 3.1.1:
-- Consider adding DMZ to the glossary
-- "Centralized or Distributed security functions" seems out of place. The rest of the section describes kinds of security functions; this describes the design of security functions.

- 3.2.1, first sentence: The second instance of "deploy" seems like a strange usage. Should this be "use"?

-3.5, title: s/Difficulty/Difficult

-3.6: "SDN-inferred agility"
Should that be SDN "implied" or "conferred" agility?

- 4.2:
-- "typically by means of Business- to-Business (B2B) communications."
Again, does B2B imply some technical characteristics of the communication? Otherwise, how is this different than just "communication"?
-- Figure 3: Please define or cite a definition for Evolved Packet Core.

-7: Are there no privacy related requirements?

[Ballot comment]
I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons.

I have a few additional comments on the odd chance this draft progresses:

-2:
--  B2B describes a business model. I don't see how that is useful for IETF discussion unless it implies specific technical characteristics. If it does, them please describe them.
Bespoke": In other usages, "bespoke" often implies positive thing, which I don't think the draft intends. I think the work "customized" would better fit the usage herein.

-3: "The "Customer-Provider" relationship may be between any two parties. The parties can be in different firms or different domains of the same firm."
There again seem to be implied business models here. Is it technically relevant if organizations qualify as "firms"?

- 3.1.1:
-- Consider adding DMZ to the glossary
-- "Centralized or Distributed security functions" seems out of place. The rest of the section describes kinds of security functions; this describes the design of security functions.

- 3.2.1, first sentence: The second instance of "deploy" seems like a strange usage. Should this be "use"?

-3.5, title: s/Difficulty/Difficult

-3.6: "SDN-inferred agility"
Should that be SDN "implied" or "conferred" agility?

- 4.2:
-- "typically by means of Business- to-Business (B2B) communications."
Again, does B2B imply some technical characteristics of the communication? Otherwise, how is this different than just "communication"?
-- Figure 3: Please define or cite a definition for Evolved Packet Core.

-7: Are there no privacy related requirements?

[Ballot comment]
I appreciate the work that has gone into the document for the exercise of defining the problem and use-cases, however I question the value of publishing this document as an RFC, but I will not block its path should other ADs consider it of use. I am taking an abstain position.

[Ballot comment]
Agree with my Abstaining co-ADs and don't think this document should be published on the Standards track but I will not stand in the way of publication.

[Ballot comment]
Agree with Alvaro, Deborah and Mirja and don't think this document should be published on the Standards track but I will not stand in the way of publication.

[Ballot comment]
Similar to other Abstains, I won't block publication but question the value, especially the current version to be published at this time. The document rambles on descriptions and it is not concise on the problem to be addressed by i2nsf. I recommend holding off on publication until it can be fine tuned, it currently appears to be a cut and paste of many documents. Agree with others the document should be Informational, not Standards track.

Examples, section 5 seems to summarize that i2nsf will only focus on policy provisioning. Yet, section 3.4 discusses capability negotiation and 3.1.2 discusses monitoring mechanisms and execution status of NSFs capabilities. And other sections also infer much more, describing expectations of security controller functionality.

There are several rather overzealous claims: Section 4.4 "botnet attacks could be easily prevented by provisioning security policies using the i2nsf..interface" and section 4.5 "security controller would keep track of ..if there is any policy violation ..proof..in full compliance with the required regulations".

Several sentences don't parse e.g. "thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs".

[Ballot comment]
Similar to other Abstains, I won't block publication but question the value, especially the current version to be published at this time. The document rambles on descriptions and it is not concise on the problem to be addressed by i2nsf. I recommend holding off on publication until it can be fine tuned, it currently appears to be a cut and paste of many documents.

Examples, section 5 seems to summarize that i2nsf will only focus on policy provisioning. Yet, section 3.4 discusses capability negotiation and 3.1.2 discusses monitoring mechanisms and execution status of NSFs capabilities. And other sections also infer much more, describing expectations of security controller functionality.

There are several rather overzealous claims: Section 4.4 "botnet attacks could be easily prevented by provisioning security policies using the i2nsf..interface" and section 4.5 "security controller would keep track of ..if there is any policy violation ..proof..in full compliance with the required regulations".

Several sentences don't parse e.g. "thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs".

[Ballot comment]
[Mirja beat me to the DISCUSS; FWIW, I completely agree that, if published, this document should not be in the Standards Track.]

Because this document only provides background on the problem space and some use cases, I don't think it has the long standing value to be published as an RFC (of any maturity level).  Having a clear understanding of the problem and of the use cases is important for the eventual development of a solution, but in this case no specific path is clearly marked: the language includes a lot of "may be required/need/etc" not resulting in a strong basis to build a solution.

I know that the i2nsf Charter gave the WG the option to not publish this document, and that it is being published anyway...so I won't stand in the way of publication and am ABSTAINing instead.

[Ballot discuss]
This document should be informational. I don't see any reason that this document must be cited normatively by all following document of this wg (as indicated in the shepherd write-up) and even if so that does not justify publication as Standards track if the information in the document is only informational.

[Ballot comment]
As soon as my discuss is resolved I will change to 'Abstain' as I don't see value in the publication of this document. I can see that this document was useful for discussion in the working group but I don't know why it needs to be published as RFC. Also there is quite some redundancy everywhere in the document aa well as between the problem statement and use case part. Spelling out requirements for the protocol design based on the analysis of these problems and use cases (which was already a bit attempted from time to time in the doc) would have been more useful but does still not have an archivable value that justifies publication as RFC in the IETF stream (indicating IETF consensus).

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

[Ballot comment]
I don't have any problem with this document per se, but it's a little
odd how it's written in a vacuum as if there weren't already technologies
which did a lot of the things you are talking about here (e.g., YANG)
and which the WG intends to use. I think this document would be a
lot stronger if it didn't act as if the WG was agnostic and instead
called out what solutions the WG intends to adopt for these.

I'm also somewhat surprised this is being advanced as Standards Track,
given that it doesn't have any normative content, and becaus ehte
writeup says that there isn't commitment to implement this.
I won't hold a DISCUSS on this, but I would suggest it be Informational.


S 2.
  Flow-based NSF:    An NSF which inspects network flows according to a
        security policy.  Flow-based security also means that packets are
        inspected in the order they are received,

This seems over-specific, because sometimes firewalls and the like will
store packets so that it can re-assemble them, in which case it inspects
them in logical not time order.


S 3.1.7.
  Different policies might need different signatures or
  profiles.  Today, the construction and use of black list databases
  can be a win-win strategy for all parties involved.

Well, except for attackers. They are involved.


S 3.1.9; bullet 3.
Symmetric keys and group keys are not the same type of category,
so I can't read this section. What are you trying to say here?


S 3.5.
"xamine" and "scnearios" are misspelled.


S 3.6.
ToR seems to be undefined.


Figure 3.
I think this dotted circle-thing is intended to tell me that the operator
controls the stuff inside the circle, but I'm not sure. Maybe some
labels would help.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-i2nsf-problem-and-use-cases-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: i2nsf@ietf.org, Adrian Farrel , Kathleen.Moriarty.ietf@gmail.com, i2nsf-chairs@ietf.org, adrian@olddog.co.uk, draft-ietf-i2nsf-problem-and-use-cases@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (I2NSF Problem Statement and Use cases) to Proposed Standard


The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document:
- 'I2NSF Problem Statement and Use cases'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the problem statement for Interface to
  Network Security Functions (I2NSF) as well as some companion use
  cases.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

Request for posting confirmation emailed to previous authors: Susan Hares , Jaehoon Jeong , Christian Jacquenet , i2nsf-chairs@ietf.org, Diego Lopez , Myo Zarny , Rakesh Kumar

> (1) What type of RFC is being requested

Standards Track

> Why is this the proper type of RFC?

This document describes the problem being solved by the work of
the I2NSF working group and will be a normative reference from
all of the protocol work.

> Is this type of RFC indicated in the title page header?

Yes.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
>
>
> Technical Summary:

The demand for hosted (or cloud-based) security services is growing.
To meet the demand, more and more service providers are providing
hosted security solutions to deliver cost-effective managed security
services to enterprise customers.  The Network Security Functions
(NSFs) are provided and consumed in a large variety of environments.
Users of NSFs may consume network security services hosted by one or
more providers, which may be their own enterprise, service providers,
or a combination of both.  This indicates a potential benefit in a
common interface and architecture to access NSFs.

This document describes the problem statement for Interface to
Network Security Functions (I2NSF) as well as some companion use
cases.

> Working Group Summary:

This is the first document coming from the I2NSF WG.  It is the
result of merging material from four separate documents and then
agreeing terminology within the WG.  Later stages of work on the
document have been largely editorial and so the level of interest
has not been high.  However, I am confident that there is solid
support in the WG.

There is no controversy.

The WG had a milestone that read:
| WG decides whether to progress adopted drafts for publication as
| RFCs (use cases, framework, information model, and examination of
| existing secure communication mechanisms)
Discussion led to agreement to drop some documents, but also to pursue
use cases by folding them into this problem statement document as
valuable context.

> Document Quality:

This problem statement is not, of itself, implementable.  The WG has 
participation from a number of implementers/vendors of NSFs who say
they want to work on solutions with a view to providing standardised
interfaces.  The operators who are participating have not committed
to deploy such an interface, but are watching to see how it ends up
because they recognise the potential benefit.

This document attracted several careful reviews during WG last call.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd.
Kathleen Moriarty (kathleen.moriarty.ietf@gmail.com) is the Responsible
Area Director.

> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd.

I reviewed this document during WG last call.
None of my issues was substantive, and all have been addressed.
I believe this revision is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

The review has been a little thin, but not alarmingly so. There were
three careful reviews during WG last call, and the authors have taken
care with the document.

> (5) Do portions of the document need review from a particular or
> from broader perspective. 

If there are additional reviews from the SecDir and OpsDir before
publication, this might be beneficial.

> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?

Note that the document has 6 front page authors.  This is a result of
the substantial draw on no fewer than 4 other documents.  Another 11
people are listed as Contributors in Section 9, so it cannot be claimed
that the front page is Cavalier.

Sections 8 and 10 should be merged.

See the Working Group Summary for a note on why publication of this
document is being pursued.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?

All of the authors and contributors have been made explicitly aware of
their responsibilities under BCP78&79 and have been reminded that as
named authors/contributors they are signing their compliance.

All of the front-page authors have explicitly confirmed that they
have disclosed all relevant IPR of which they are aware.

> (8) Has an IPR disclosure been filed that references this document?

No IPR has been disclosed against this document or any of its
predecessors.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

The WG agrees and there is no dissent. To some extent the content of
this document represents the motivation for the formation of the WG and
the consensus can be measured at that point as well as at WG last call.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

None.

> (11) Identify any ID nits the Document Shepherd has found in this
> document.

idnits is throwing a bogus warning about an unused reference (that is
actually used).

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

> (13) Have all references within this document been identified as
> either normative or informative?

Yes. All references are (correctly) Informative.

> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state?

N/A

> (15) Are there downward normative references?

No.

> (16) Will publication of this document change the status of any
> existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA
> considerations section.

The document correctly contains a null IANA section.

> (18) List any new IANA registries that require Expert Review for
> future allocations.

N/A

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

N/A

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet" , "Myo Zarny"

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet" , "Myo Zarny"

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet" , "Myo Zarny"

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet" , "Myo Zarny"

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Myo Zarny" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet"

Request for posting confirmation emailed to previous authors: "Jaehoon Jeong" , "Susan Hares" , "Myo Zarny" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "Christian Jacquenet"