-----Original Message-----
From: I2nsf [mailto:[email protected]] On Behalf Of Rafa Marin Lopez
Sent: Monday, October 3, 2016 5:33 PM
To: [email protected]
Cc: Rafa Marin Lopez
Subject: [I2nsf] Comments/questions about draft-ietf-i2nsf-problem-and-use-cases
Dear all:
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
past).
-----------------------
Section 3.1.1
[Rafa]
-Security Functions in a DMZ. You refer to authentication and authorization but
also AAA. Is this not redundant?
Sue: New text
Security Functions in a DMZ: Examples of this
function are firewall/ACLs, IDS/IPS, one or all of AAA services
NAT, forwarding proxies, and application filtering.
These functions may be physically on-premise
in a server provider's network at the DMZ spots or located in a
"virtual" DMZ.
[Rafa #2]
- 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 #2] Can you suggest an example NSF with flow protection. I will be gald
[Rafa #3 Section 3.1.10]
- 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
(https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-00). 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 #3]:
I have modified the text to state:
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. One
potential use of such an interface is to manage IPSec security associations on
SDN networks.
[Rafa #4:]
- 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 #4]: I have changed the text
[Rafa #5]
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]: I agree. I have removed the first sentence. I believe this addresses
your comment.
[Rafa #6]
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]: You are right. I have changed the following paragraph to mention the
distribution of keys.
Interface 1 is used for receiving security requirements from client
and translating them into commands that NSFs can understand and
execute. The security controller also passes back NSF security reports
(e.g., statistics) to the client which the control has gathered from
NSFs. Interface 2 is used for interacting with NSFs according to
commands (e.g. enact policy and distribute key), and collecting
status information about NSFs.
[Rafa #7]
Section 7.
When you mention AAA, are you referring to https://tools.ietf.org/html/rfc2904
?
[Sue # 7]: I've included a reference to the AAA document at that point.
Rafa - Thanks for all the comments - Let me know if the above resolution works
for you. I'll respond to your other message, and then send you a copy of the
file.
-------------------------------------------------------
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: [email protected]
-------------------------------------------------------
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
