Dear all, please find some comments to the text
• Section 3.1.1
• Security gateways or VPNs concentrators could also be
add to the list.
• “For example, from an I2NSF perspective, there is no
need to standardize on how firewall filters are created or applied.”. It is not
clear why ones need to be standardized and others no.
• Does it means I2NSF aims to standardize the
interface to control firewalls filters rather than the own firewalls filters?
(just to clarify)
• Section 3.1.9.
• In addition to Rafa’s comments, I suggest this
section should introduce first the security functions where key distribution is
required. For example: securing routing protocols? IPsec flow protection
channels? AAA protocols? Then, to discuss about the different approaches: a
protocol-independent key table? a protocol-based approach?. It seems authors
are proposing some kind of solution, but this is a problem-use-case document.
• Section 3.2.2
• “No standard technical characterization and/or APIs”
and “No standard interface”.
• Both texts talks about “standard interfaces”.
Could they be merger? (just suggesting)
• Section 3.1.7 and section 3.4 both talks about IDS/IPS/etc.
profiles. Could they be combined or referenced?
• Should 3.3 be 3.2.4? and 3.4 be 3.2.5? and 3.5 be 3.2.6?
Just my two cents.
Best regards, Gabi.
> El 3 oct 2016, a las 23:33, Rafa Marin Lopez <[email protected]> escribió:
>
> 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
>
> -Security Functions in a DMZ. You refer to authentication and authorization
> but also AAA. Is this not redundant?
>
> -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.
>
> 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?
>
> - 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.
>
>
> 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?.
>
> 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.
>
> Section 7.
>
> When you mention AAA, are you referring to
> https://tools.ietf.org/html/rfc2904 ?
>
> ---------
>
> Best Regards.
>
>
> -------------------------------------------------------
> 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
-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email protected] <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
