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

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

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

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

Thanks for addressing my discuss!

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.