Framework for Interface to Network Security Functions
draft-ietf-i2nsf-framework-10

[Ballot comment]
I am not sure what the "addr" field in the Packet Content Matching Capability Index for IPv6 means (i.e. what protocol field it corresponds to) and I think it should be clarified.

[Ballot comment]
I am not sure what the "addr" field in the Packet Content Matching Capability Index for IPv6 means, but I think it should be clarified.

[Ballot comment]
As Alissa mentioned in her Ballot, the long-term archival value of this draft is not clear to me either.

There are some places where it is not clear what the intent of the document is wrt the references; are they examples, recommendations or do they represent a stronger pillar in the i2nsf work.  Just to highlight one of them:


I’m not sure what is the intent with rfc5575 (Dissemination of Flow Specification Rules) is in 9.2.  I’m confused because the reference is Normative, but the text sounds as if FlowSpec was an example:

  9.2.  Registration Categories

  Developers can register their NSFs using Packet Content Match
  categories.  The IDR (Inter-Domain Routing) Flow Specification
  [RFC5575] has specified 12 different packet header matching types.
  More packet content matching types have been proposed in the IDR WG.
  I2NSF should re-use the packet matching types being specified as much
  as possible.  More matching types might be added for Flow-based NSFS.
  Tables 1-4 below list the applicable packet content categories that
  can be potentially used as packet matching types by Flow-based NSFs:


Also, the tables present categories that go beyond what FlowSpec covers.  Where does the other information come from?  Is there work that can reused there?  What about IPFIX (that seems more appropriate than FlowSpec)?

To be clear, I like very much the fact that the text advocates for reuse.  It is just not clear what the expectation is with regards to rfc5575 or other proposed work in the idr WG.  Is the expectation that the matching types be used in i2nsf systems?  What about other related extensions that may be developed in idr, are there specific requirements or considerations that the idr WG should take into account?  From the archive, it looks like idr hasn’t reviewed (or been notified of) this document…

Note that if the mention of rfc5575 is just an example, then I think some of the text could be made clearer (and the reference should be Informative).

[Ballot comment]
(1) I think there are some errors in Table 1, or perhaps there are just formatting issues that have me confused. It looks like TCP, SCTP, DCCP, UDP, and HTTP are listed under Layer 3. I can't tell if there is meant to be a difference between header fields separated by slashes versus those separated on different lines. There seems to be an extra column in front of the HTTP fields -- what does that signify? Why is TRAM profile in particular included as an example here?

(2) Tables 2-4 also seem to be specified in a significant amount of detail, given that context and actions themselves are defined in detail in a different individual draft. This makes it hard to understand the implications of some of the fields. E.g., the "GPS coords" field -- whose GPS coords does this refer to? It seems like the fields in these tables either need to be explained more, or they should be removed. 

(3) I'm not going to stand in the way of publication but it's not clear to me why this document needs to be an RFC. Much of the content seems like a generic narrative that describes how NSFs could work but doesn't really lay out any concrete constraints about how they should work that would lead to greater interoperability.

[Ballot comment]
-2: If no 2119 keywords are used, please remove the boilerplate. But if you do need to keep it, please use the updated boilerplate from 8174, since there are a number of lower case versions of 2119 keywords.

-6.2: first bullet: I am always worried about text advising that "closed environments" have lower security requirements. That has proven false so many times we really shouldn't be encouraging it. This is especially worrisome since the first paragraph of section 11 talks about the importance of "trustworthy, robust, and fully secured access".

[Ballot discuss]
I have two points below:

1) The first one should be easy to address:
"Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the
  Stream Control Transmission Protocol (SCTP) will need to be evaluated
  for applicability. "
This sentence is not correct; MPTP and SCTP do not provide any redundancy mechanisms; they simply just provide a reliable transport as TCP does. Therefore I would just remove this sentence here.

Further, on this paragraph, it is not clear to me why you say that reliable transport is needed. Especially for some monitoring purposes, unreliable transport might be acceptable as well. Or do you think that all communication for security systems have always to be reliable? I don't think this document discusses things in detail enough to make such an assessment.

2) This second is a very high level concern and I'm not sure if balloting discuss on this is the right thing to do but I definitely would like to get some feedback from the group to better understand this document before publication:

This document seem not very security specific to me. To say this in a somehow sloppy way: I have the feeling that if you would just remove the word "security" everywhere in the text, it would still be the same document. I checked the charter and the charter is also not very concrete about what to expect, besides motivating the needed interfaces with the need for in-network security function. However, if there is nothing security specific about this, what's the difference to the usually control plane architecture as usually deployed with the use of NETCONF? And I am actually wondering if this is the right wg to write such a document.

Further, I would at least have expected that this framework mandates for high control plan security given we are talking about the configuration and deployment of security function. However, it does not. It does rarely provide any concrete recommendation here, and basically leaves the door open to used these interfaces without authentication which I think is not acceptable.

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

The IANA Services Operator has reviewed draft-ietf-i2nsf-framework-08, 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

Document Writeup for draft-ietf-i2nsf-framework-07

> (1) What type of RFC is being requested?
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This document is requested for publication as an Informational RFC.

This is appropriate for a framework that does not define any protocol
elements.

This is clearly indicated on the title page.

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

This document describes the framework for the Interface to Network
Security Functions (I2NSF), and defines a reference model (including
major functional components) for I2NSF.  Network security functions
(NSFs) are packet-processing engines that inspect and optionally
modify packets traversing networks, either directly or in the context
of sessions to which the packet is associated.

> Working Group Summary:

There was nothing exceptional in the WG processing for this document.
There was careful debate resulting in a number of changes and careful
synchronisation with other WG documents.

> Document Quality:

This framework is not directly implementable, but it underpins the work
of the working group. At least one vendor is building a system based on
the work of the working group and following this framework as an
architecture. There has also been experimentation at IETF hackathons
that is consistent with this framework.

> Personnel:

Yoav Nir  is the Document Shepherd.
Kathleen Moriarty  is the Responsible AD.

> (3) Briefly describe the review of this document that was performed
>    by the Document Shepherd. If this version of the document is not
>    ready for publication, please explain why the document is being
>    forwarded to the IESG.

This revision and the previous revision were reviewed by the document
shepherd. All comments arising from the reviews have been addressed.
The document is ready for publication.

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

No. The WG is small, but there were a good number of sound reviews.

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

Not required, but a wider security view might be wise.

> (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?

There is a continuous debate on the value and purpose of publishing
framework documents. This document is specifically noted as a
deliverable in the WG charter. The WG debated the value of publication
and decided that it would be helpful to have this document published.

> (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?

The authors have been explicitly reminded of their responsibilities
under BCP 78 and 79. By placing their names as authors of the document
they have acknowledged those BCPs and agreed to comply with the terms of
the IETF's IP policies.

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

No IPR has been disclosed against this document.

> (9) How solid is the WG consensus behind this document?

Good.
There has been review and supporting positions across the WG.

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

None known.

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

idnits complains about unnecessary RFC 2119 boilerplate. That can
safely be removed by the RFC Editor.

There is also an extraneous space spotted by idnits

> (12) Describe how the document meets any required formal review
>      criteria.

Nothing requiring formal review.

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

They most surely have.

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

All normative references are to published RFCs.

> (15) Are there downward normative references?

No downrefs.

> (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.

A null IANA section is correctly included.

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

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

No such section, no such review.

The following Last Call announcement was sent out (ends 2017-10-25):

From: The IESG
To: IETF-Announce
CC: Yoav Nir , draft-ietf-i2nsf-framework@ietf.org, i2nsf@ietf.org, ynir.ietf@gmail.com, Adrian Farrel , Kathleen.Moriarty.ietf@gmail.com, i2nsf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Framework for Interface to Network Security Functions) to Informational RFC


The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document: - 'Framework for
Interface to Network Security Functions'
  as Informational RFC

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-10-25. 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 framework for the Interface to Network
  Security Functions (I2NSF), and defines a reference model (including
  major functional components) for I2NSF.  Network security functions
  (NSFs) are packet-processing engines that inspect and optionally
  modify packets traversing networks, either directly or in the context
  of sessions to which the packet is associated.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/ballot/


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

Document Writeup for draft-ietf-i2nsf-framework-07

> (1) What type of RFC is being requested?
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This document is requested for publication as an Informational RFC.

This is appropriate for a framework that does not define any protocol
elements.

This is clearly indicated on the title page.

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

This document describes the framework for the Interface to Network
Security Functions (I2NSF), and defines a reference model (including
major functional components) for I2NSF.  Network security functions
(NSFs) are packet-processing engines that inspect and optionally
modify packets traversing networks, either directly or in the context
of sessions to which the packet is associated.

> Working Group Summary:

There was nothing exceptional in the WG processing for this document.
There was careful debate resulting in a number of changes and careful
synchronisation with other WG documents.

> Document Quality:

This framework is not directly implementable, but it underpins the work
of the working group. At least one vendor is building a system based on
the work of the working group and following this framework as an
architecture. There has also been experimentation at IETF hackathons
that is consistent with this framework.

> Personnel:

Adrian Farrel  is the Document Shepherd.
Kathleen Moriarty  is the Responsible AD.

> (3) Briefly describe the review of this document that was performed
>    by the Document Shepherd. If this version of the document is not
>    ready for publication, please explain why the document is being
>    forwarded to the IESG.

This revision and the previous revision were reviewed by the document
shepherd. All comments arising from the reviews have been addressed.
The document is ready for publication.

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

No. The WG is small, but there were a good number of sound reviews.

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

Not required, but a wider security view might be wise.

> (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?

There is a continuous debate on the value and purpose of publishing
framework documents. This document is specifically noted as a
deliverable in the WG charter. The WG debated the value of publication
and decided that it would be helpful to have this document published.

> (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?

The authors have been explicitly reminded of their responsibilities
under BCP 78 and 79. By placing their names as authors of the document
they have acknowledged those BCPs and agreed to comply with the terms of
the IETF's IP policies.

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

No IPR has been disclosed against this document.

> (9) How solid is the WG consensus behind this document?

Good.
There has been review and supporting positions across the WG.

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

None known.

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

idnits complains about unnecessary RFC 2119 boilerplate. That can
safely be removed by the RFC Editor.

There is also an extraneous space spotted by idnits

> (12) Describe how the document meets any required formal review
>      criteria.

Nothing requiring formal review.

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

They most surely have.

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

All normative references are to published RFCs.

> (15) Are there downward normative references?

No downrefs.

> (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.

A null IANA section is correctly included.

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

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

No such section, no such review.

Notification list changed to "Adrian Farrel" <adrian@olddog.co.uk>, Yoav Nir <ynir.ietf@gmail.com>, Adrian Farrel <adrian@olddog.co.uk> from "Adrian Farrel" <adrian@olddog.co.uk>, Yoav Nir <ynir.ietf@gmail.com>

Request for posting confirmation emailed to previous authors: "Anil Lohiya" , "Joe Parrott" , "Edward Lopez" , "Xiaojun Zhuang" , "Seetharama Durbha" , "Linda Dunbar" , "Diego Lopez" , "Rakesh Kumar" , i2nsf-chairs@ietf.org, "John Strassner" , "Ram Krishnan"