Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases

Note: This ballot was opened for revision 11 and is now closed.

Warren Kumari No Objection

Comment (2017-05-09 for -15)
No email
send info
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.

Alvaro Retana Abstain

Comment (2017-04-11 for -12)
No email
send info
[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 I won't stand in the way of publication and am ABSTAINing instead.

(Kathleen Moriarty; former steering group member) Yes

Yes (2017-05-10)
No email
send info
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.

(Adam Roach; former steering group member) No Objection

No Objection (2017-04-26 for -12)
No email
send info
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.

(Alia Atlas; former steering group member) No Objection

No Objection (2017-04-26 for -12)
No email
send info
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.

(Ben Campbell; former steering group member) No Objection

No Objection (2017-05-10)
No email
send info
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.]

(Benoît Claise; former steering group member) No Objection

No Objection ()
No email
send info

(Alissa Cooper; former steering group member) Abstain

Abstain (2017-04-11 for -12)
No email
send info
I agree with Alvaro and Mirja.

(Deborah Brungard; former steering group member) Abstain

Abstain (2017-04-11 for -12)
No email
send info
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 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".

(Eric Rescorla; former steering group member) (was No Objection) Abstain

Abstain (2017-04-07 for -12)
No email
send info
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.

(Mirja Kühlewind; former steering group member) (was Discuss) Abstain

Abstain (2017-04-27 for -13)
No email
send info
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).

(Suresh Krishnan; former steering group member) Abstain

Abstain (2017-04-11 for -12)
No email
send info
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.

(Terry Manderson; former steering group member) Abstain

Abstain (2017-04-23 for -12)
No email
send info
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.