Subject: [I2nsf] Framework Draft Comments From Adrian

From: John Strassner <[email-masked]>
Date: Sun, 2 Jul 2017 14:38:51 -0700

Hi Adrian,

thanks for the thorough review. Your comments are addressed below. Please
note that I can NOT find reviews of this draft by Christian and Med. I did
search the archive. I found comments on the terminology draft from
Christian.

regards,
John

ALL comments were accepted, except as noted below.

In 2.2, the term used in
is "I2NSF Consumer"

I suggest you write
   Consumer: Equivalent to "I2NSF Consumer"

<jcs>
This should be I2NSF Consumer according to the terminology draft, so I made
that change throughout this document.
</jcs>

---

I'm struggling a little with ....

3.3.  Registration Interface

   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have an interface for vendors to define the capabilities of their
   NSFs.  This Interface Group is called the Registration Interface
   Group.

   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the Registration Interface Group.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities SHOULD be notified to security controllers via the
   Registration Interface Group.

There is definitely an ambiguity about this. Is the section talking
about the "Registration Interface Group"? What are the component
interfaces in this group?

<jcs>
Terminology defines an Interface Group, but not a Registration Interface
Group. I have changed this to "I2NSF Registration Interface".
Here is the rewritten paragraph:
3.3.  I2NSF Registration Interface
   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have a dedicated interface for vendors to define the capabilities of
   (i.e., register) their NSFs.  This Interface is called the
   I2NSF Registration Interface.
   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the I2NSF Registration Interface.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities should be notified to security controllers via the
   I2NSF Registration Interface.
</jcs>
---

6.1.  Network Connecting I2NSF Users and I2NSF Controller

   [TBD: should we add the Remote Attestation to this section?]

I think you have added remote attestation and can remove this note.

<jcs>
Not yet - see earlier note. Since there are at least two different
approaches to remote attestation in the IETF, I think the WG still needs to
decide what to do here. I see no reason why we can't push this framework
draft forward and then have the remote attestation work (which still isn't
even a WG draft) add on and augment later. Hence, no action has yet been
taken.
</jcs>

---

6.2

   The network connection between the Security Controller and NSFs can
   rely either on:

Should you be making clear that in the open environment anything from a
few up to all of the NSFs can be hosted in external administrative
domains.  Thus "closed" is very tightly defined, and "open" is anything
that is not completely closed.

<jcs>
Here is the rewrite:
   o  Open environments, where one or more NSFs can be hosted in one or
      more external administrative domains that are reached via secure
      external network connections.  This requires more restrictive
      security control to be placed over the I2NSF interface.  The
      information over the I2NSF interfaces shall be exchanged used
      trusted channels as described in the previous section.

   When running in an open environment, I2NSF needs to rely on
   interfaces to properly verify peer identities (e.g., through an AAA
   framework).  The implementations of identity management functions,
   as well as the AAA framework, are out of scope for I2NSF.
</jcs>

---

I can't help thinking that section 9.2 is way too detailed for this
document. I don't think there is anything wrong in what it says, but it
looks more like an information model for a specific capability exchange
than something that belongs in a general framework.

Can you see whether there is a different document that this belongs in?

<jcs>
This COULD be folded into the Capability Interface document, and then this
(the Framework) document could reference the Capability interface document.
However, that document is not yet accepted by the WG. So, would you like me
to:

   1) leave as is, so the Framework document can proceed to last call, or
   2) move this entire section to the Capability document, or
   3) do something other than 1) or 2)?
</jcs>

-- 
regards,
John