Subject: Re: [I2nsf] Comyou earlier on this topic: ments/questions about draft-ietf-i2nsf-problem-and-use-cases

From: "Susan Hares" <[email-masked]>
Date: Wed, 9 Nov 2016 21:31:44 -0500

Gabriel: 

I believe responded to you before on this topic, but I am resending the information – in case I forgot.  Please let me know if the resolution of these comments is ok for you.

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Gabriel Lopez
Sent: Thursday, October 6, 2016 6:56 AM
To: Rafa Marin Lopez
Cc: [email-masked]
Subject: Re: [I2nsf] Comments/questions about draft-ietf-i2nsf-problem-and-use-cases

Dear all, please find some comments to the text

Gabriel [#1] 

• Section 3.1.1

• Security gateways or VPNs concentrators could also be add to the list.

[Sue: added to the list  

Gabriel [#2] 

• “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. 

Sue [#2]: The following text is added to this sentence: 

“For example, from an I2NSF perspective, there is no need to standardize how every firewall's filtering is created or applied.  Some features in a specific vendor's filtering may be unique to the vendor's product so it is not necessary to standardize these features.

What is needed is a standardized interface to control and monitor the rule sets that NSFs use to treat packets traversing through. And standardizing interfaces will provide an impetuous for standardizing established security functions.”

[Gabriel #3]: 

• Does it means I2NSF aims to standardize the interface to control firewalls filters rather than the own firewalls filters? (just to clarify) –

[Sue:]  My understanding is this the main goal of I2NSF.  IMO, you will end up defining filters (in NETMOD, I2RS or I2NSF) that make up the very basic functions because it is necessary building block to create capability interface, inter-Cloud DDoS, and other I2NSF data models. 

(note – I did not add additional text). 

[Gabriel #3]: 

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

[Sue]:  I’ve changed the 3.1.9 text enough that I would like you to look at the resulting document. I have tried to take out any solutions.   We’ll need to iterate on this text.  I will send a copy of the text to the list.

[Gabriel #4]

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

[Sue]:Good point.  I’ve changed the text to: 

Without a standard interface that provides clear technical characterization of the I2NSF services, the service provide faces many challenges: 

[Gabriel #5] 

• Section 3.1.7 and section 3.4 both talks about IDS/IPS/etc. profiles. Could they be combined or referenced?

[Sue #5]:  Due to different NSF products, I would like to keep these separated.  Can you suggest a reference? 

[Gabriel #6]:  • Should 3.3 be 3.2.4? and 3.4 be 3.2.5? and 3.5 be 3.2.6?

[Sue #6]: On this topic, may we leave the format as is.  The basic format has been argued over so I really do not want to restart the format discussion. 

Thanks for all the create comments.  I will send the text version to the list once get to the Hotel in Seoul, Korea.   I expect you will see it by about 9am CET.  

Just my two cents.

Best regards, Gabi.

El 3 oct 2016, a las 23:33, Rafa Marin Lopez <[email-masked]> 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-masked]
-------------------------------------------------------

_______________________________________________
I2nsf mailing list
[email-masked]
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:  <mailto:[email-masked]> [email-masked]