Subject: [I2nsf] comments on draft-merged-i2nsf-framework-01

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Jun 2015 13:52:50 +0000

Hi,

Thanks for the good work. It shows a lot of progress. Here are a few comments:

1.       The introduction section mentions SDN/NFV. First, please expand. Then please provide some context or reference or examples on how 'I2NSF facilitates SDN/NFV control'. These may come later in the document, not necessarily (or batter not) in the Introduction.

2.       We have an inconsistency in terminology between this I-D and draft-lopez-i2nsf-packet-00. In section 3.3 we refer to it for the definition of the flow based NSF, but actually that I-D speaks only about packet-based NSFs. This needs to be resolved. I would even copy the definition of 'flow-based' here for clarity, and with the assumed risk of duplication.

3.       In section 5.1 - is the [ACL-MODEL] supposed to be one among many possible examples of Capability Layer Provisioning and Monitoring? If so it would be good to say it explicitly, and maybe to move all the text after the first three paragraphs to a different section 5.1.1

4.       In section 5.2 - 'I2NSF will not standardize the Service Layer security policies.' - this is fine. Maybe it's good to say something here about the relationship with SUPA - because SUPA (if approved and chartered) seems to be a good candidate to play in this space

5.       Section 6 - please expand CPP, CPNP and provide an example or a reference for what is meant here by 'security as a service' - this term may have different meanings for different people.

6.       Section 8 - as we said earlier that NSFs may be vNSFs, management of NSFs may include management of resources as well as orchestration of vNSFs. All are out-of-scope but it's good to make sure that we are aware and exclude them by design.

Regards,

Dan

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Jun 2015 17:14:00 +0000

Dan,

Thank you very much for the comments. Answers to your questions are inserted below.

From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, June 08, 2015 8:53 AM
To: [email-masked]
Subject: [I2nsf] comments on draft-merged-i2nsf-framework-01

Hi,

1.       The introduction section mentions SDN/NFV. First, please expand. Then please provide some context or reference or examples on how 'I2NSF facilitates SDN/NFV control'. These may come later in the document, not necessarily (or batter not) in the Introduction.
[Linda] done for the 02 version.

[Linda] We discussed this before and have agreed to use Flow-Based because the NSFs under consideration include "Object" (which is the contextual information associated with states of flows.).

3.       In section 5.1 - is the [ACL-MODEL] supposed to be one among many possible examples of Capability Layer Provisioning and Monitoring?

[Linda] the answer is "No" as described in the Section 5.1:
The functional profiles (or signatures) for NSFs are not present in [ACL-MODEL] because the functional profiles are unique to specific NSFs. Most vendors' IPS/IDS, and HoneyPot have their proprietary functions/profiles. One of the goals of I2NSF is to have common envelop format for exchanging or sharing profiles among different organizations to achieve more effective protection against threats.

If so it would be good to say it explicitly, and maybe to move all the text after the first three paragraphs to a different section 5.1.1

[Linda] I2NSF's Gap analysis has a section on comparing with SUPA. Is it good enough?

[Linda] done in 02 version.

[Linda]  Thanks. To make it clear, how about we explicitly put them in bullets?

Management of NSFs usually include
- life cycle management and resource management of vNSFs
- configuration of devices, such as address configuration, device internal attributes configuration, etc,
- signaling, and
- policy provisioning.
I2NSF will only focus on the policy provisioning part, i.e. the last bullet listed above.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Jun 2015 17:22:26 +0000

Hi Linda,

Thanks for the answer. See below.

Regards,

Dan

DR - this is fine, but then we need to update draft-lopez-i2nsf-packet. It does not define Flow-Based.

DR - no because the connection is specific here. I2NSF considers this interface out of scope. We should point here to SUPA as a possible alternate place in the IETF where it can be done.

DR - very good

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Jun 2015 19:12:39 +0000

Dan,

How about this statement inserted in Section 5.2  to address SUPA :

"I2NSF will not standardize the Service Layer security policies. IETF SUPA - Shared Unified Policy Automation, if approved and chartered, seems to be a good candidate to play in this space".

Linda
From: Romascanu, Dan (Dan) [mailto:[email-masked]]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Jun 2015 19:14:36 +0000

Yes, works well.

Thanks and regards,

Dan

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, June 08, 2015 10:13 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: comments on draft-merged-i2nsf-framework-01

Dan,

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Jun 2015 20:32:38 +0000

Dan,

Reading through the draft-lopez-i2nsf-packet draft again, I feel the proposed "Packet-Based" approach doesn't really conflict with the "Flow-based NSF".

The draft is advocating "using Packet-Based approach to provision Flow-Based NSFs".
I2nsf Problem Statement has this definition for Flow-based NSF:
 "Flow-based Network Security Function: A NSF that inspects network flows according to a policy intended for enforcing security properties.  Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).

What do you think?

Linda

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, June 08, 2015 12:22 PM
To: Linda Dunbar; [email-masked]
Subject: RE: comments on draft-merged-i2nsf-framework-01

Hi Linda,

Regards,

Dan

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 9 Jun 2015 06:22:34 +0000

Hi,

Anyway, one thing is the proposed charter, and another thing an I-D still in its initial stage. We'll have time to make the draft converge with the charter once refined (and approved!) The important point here is that there is a common understanding about the proposed target among the community.

Be goode,

On 8 Jun 2015, at 22:32 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Dan,

Reading through the draft-lopez-i2nsf-packet draft again, I feel the proposed “Packet-Based” approach doesn’t really conflict with the “Flow-based NSF”.

The draft is advocating “using Packet-Based approach to provision Flow-Based NSFs”.
I2nsf Problem Statement has this definition for Flow-based NSF:
 “Flow-based Network Security Function: A NSF that inspects network flows according to a policy intended for enforcing security properties.  Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).

What do you think?

Linda

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, June 08, 2015 12:22 PM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: RE: comments on draft-merged-i2nsf-framework-01

Hi Linda,

Regards,

Dan

2.       We have an inconsistency in terminology between this I-D and draft-lopez-i2nsf-packet-00. In section 3.3 we refer to it for the definition of the flow based NSF, but actually that I-D speaks only about packet-based NSFs. This needs to be resolved. I would even copy the definition of ‘flow-based’ here for clarity, and with the assumed risk of duplication.

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Jun 2015 09:58:09 +0000

Hi Linda,

I did not say that there is a conflict, I said that the terminology is not consistent. In draft-lopez-i2nsf-packet the word 'flow' appears only in the context of 'Open-flow', however draft-merged-i2nsf-framework-00 makes the claim (in 3.1) that

     [Packet-based-NSF] advocates that the
     flow based security functions can be categorized by

This is not accurate. [Packet-based-NSF] a.k.a draft-lopez-i2nsf-packet makes no statement about flow based security functions, it even does not use the term.

If flow-based NSF is defined in draft-dunbar-i2nsf-problem-statement, than this reference should be used.

Thanks and Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 08, 2015 11:33 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: [I2nsf] Does it make sense to say: using Packet based approach for Flow-Based NSF provisioning? (was RE: comments on draft-merged-i2nsf-framework-01

Dan,

What do you think?

Linda

Hi Linda,

Regards,

Dan