See my comments on the fixes below. I'm going to resolve other comments,
and then send out version 2. Please review version 2 went it uploads to see
if I understood all your comments.
I have reviewed draft-ietf-i2nsf-problem-and-use-cases and I have a few
comments/questions (my apologies if these have been already discussed in the
-Security Functions in a DMZ. You refer to authentication and authorization
but also AAA. Is this not redundant?
[Sue]: Yes, I have changed it.
-At first sight, there is no example of NSFs with flow based protection.
That is, those that participate in the establishment of a security
association to protect data traffic.
[Sue]: You are right, I have augmented the paragraph.
- A general comment about this section is that the text seems to pay
attention to routing. In our case, for example, we have an I-D to manage
IPSec SAs based on SDNs
I guess this use case we present in our I-D is somehow included in the text
"Conceptually, there must be an interface defined for routing/signaling
protocols." but I am not sure. Could you clarify?
[Sue]: I2NSF should include both IPSEC SAs and routing in section 3.1.10.
- A suggestion I have is to revise this paragraph:
"While there are many key management methods and
key derivation functions (KDF), there is a lack of standard interface
to provision and manage keys."
There is a lack not only to provision and manage keys but also to specify
additional information (e.g. low level policies) or to fill certain
information to manage, in the end, a security association. Additionally, I
am not sure about the initial sentence "While there are many key management
methods and key derivation functions (KDF)". what do you mean with this?
Perhaps a possible modification would say:
--> While there are many key management methods and
cryptographic suites (e.g. encryption algorithms, key derivation
functions, etc.), there is a lack of standard interface
to provision and manage security associations.
[Sue]: I accept this rewrite for version -02.txt
Regarding this paragraph:
"The ability to utilize keys when routing protocols send or receive
messages will be enhanced by having an abstract key table maintained
by a security service. Conceptually, there must be an interface
defined for routing/signaling protocols to make requests for
automated key management when it is being used, to notify the
protocols when keys become available in the key table."
In my opinion, it seems going into a solution space: "an abstract key table"
and a mechanism to "pull" the keys, is this correct?. Why using this key
table? Why using pull method so that the protocols know when the keys are
available in the table?. Also, the text refers to routing protocols at the
beginning. I would say that there must be an interface to configure security
associations of any nature, no?.
[sue]: yes, it is an example. I will add text that indicates this is an
example. Good catch on a confusing text.
Section 4. In the use cases, there is no explicit text where key
distribution is required. One may think that section 4.3.2 and, most
probably, 4.3.3 may be related with key management (section 3.1.10). I
mention this because our I-D focused on key management for IPSec SAs and
VPNs is a term that may be associated to this.
[Sue]: I've added text in version 2. Please confirm that
When you mention AAA, are you referring to
[sue]: RFC 2904 fits. Was it important to tie this down to the RFC level?
If so, I can add this RFC.
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es
I2nsf mailing list