Subject: [I2nsf] I2NSF IETF 91 Minutes

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 Nov 2014 10:50:45 -0800

I uploaded minutes form the I2NSF BOF meeting in Honolulu to
http://www.ietf.org/proceedings/91/minutes/minutes-91-i2nsf.  There are a
few places where speaker names are missing or may be misspelled so check
over the notes and let me know if there are any corrections.  Thanks to
Jean Mahoney for taking excellent notes.

Cheers,

Joe

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 20 Nov 2014 22:51:52 +0000

To move I2NSF forward, we need to converge to a few solid use cases that require tangible work by IETF. After some offline discussions with the drafts authors, we categorize the use cases into the following. For each category, the work needed by I2NSF includes: a) define/provide a general language capable of describing various security functions and associated policies/configuration of reference data; and b) define/re-use protocols to transport such information.

Summary of the use cases presented at the BOF:

1.       Need an “Intent Driven” or “Users and Apps oriented” interfaces to configure, monitor, or validate (a.k.a. OAM) network security functions instead of today’s ports/links oriented methods. The Network Security functions under consideration include FW, IDS/IPS, Honeypot, etc.     This “Intent Driven” interface can be used by

-          Clients utilizing this interface to configure their leased virtual network security functions that are hosted and managed by the operators. Those types of services are made relatively easier by virtualized infrastructure.

-           Operators using this interface to manage their own distributed or/and virtual network security functions.

[*]      Supported by use cases presented by Diego Lopez (Telefonica), MinPeng Qi (China Mobile: use case #2 &#3), and Nic Leymann (Deutsche Telecom).

Clients can either use operators’ WebPortal, or their internal WebPortals (which have back-end restful APIs to operators domain).

2.       Need interface to describe what types of authentication that is needed for different UE devices (e.g. 2G, 3G, LTE, etc). The goal is for operators to instantiate the needed authentication function instances based on the demand, with the proper service description. E.g. the service description could be “one-way”, “mutual”, or “mutual with certificate” shown in the figure below:

[*]     Supported by the Use Case #1 of MinPengQi (China Mobile)

Use Cases described by people at microphone:

3.       Applying Security Functions to content stored in Cloud, such as offering encrypted data in the cloud.

[*]     Stated by Sam Hartman

4.       Privacy of data passing the virtualized environment

5.       Security Threats introduced by virtualization (Diego Lopez)

6.       Integrate security capability into virtualization platform (Edward)
Best regards,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Thursday, November 20, 2014 12:51 PM
To: [email-masked]
Subject: [I2nsf] I2NSF IETF 91 Minutes

I uploaded minutes form the I2NSF BOF meeting in Honolulu to http://www.ietf.org/proceedings/91/minutes/minutes-91-i2nsf.  There are a few places where speaker names are missing or may be misspelled so check over the notes and let me know if there are any corrections.  Thanks to Jean Mahoney for taking excellent notes.

Cheers,

Joe

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 22 Nov 2014 02:08:21 +0000

Use case 1 shows a convincible motivation of I2NSF. In the next step, maybe we could do a detailed analysis on this use case in order to identify  1) the security functions and parameters which need to be presented in a standard way, 2) the requirements that the protocol needs to fulfill.

But before moving forward, I think we need to reach a consensus about the scope of this work first.

发件人: I2nsf [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2014年11月21日 6:52
收件人: Joseph Salowey; [email-masked]
主题: [I2nsf] Summary of the use cases being discussed at the I2NSF BOF

Best regards,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Thursday, November 20, 2014 12:51 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] I2NSF IETF 91 Minutes

Cheers,

Joe

---

From: "Minpeng Qi" <[email-masked]>
Date: Sat, 22 Nov 2014 17:52:33 +0800

Hi Linda,

Thanks for making progress. I’m fine with these categories. 

Some open discussions are raised for category 1 figure:

1.       In the closed mode, as there are interfaces for client<->OSS/BSS and OSS/BSS<->vNSF(with agent), why do we need an interface for client<->vNSF. What is the benefit? 

2.       The interfaces client<-> vNSF and OSS/BSS<-> vNSF are covered with I2NSF scope. And the interface client<->OSS/BSS is not covered. Should we to keep it out of I2NSF scope?

3.       Why do we need an explicit adapter here? My understanding the adapter plays a role in translate potential standard I2NSF messages into vendor-specific commands to operate vNSF. They must be developed by same vendor, and the interface is not open to others. Should the interface adapter<->vNSF be covered in I2NSF? If not, could we considered both adapter and vNSF should be seen as a whole? 

BRs,

Minpeng                                        

 

*       Supported by use cases presented by Diego Lopez (Telefonica), MinPeng Qi (China Mobile: use case #2 &#3), and Nic Leymann (Deutsche Telecom). 

 

*      Supported by the Use Case #1 of MinPengQi (China Mobile)

*      Stated by Sam Hartman

Best regards, 

Linda 

Cheers,

Joe

---

From: Youjianjie <[email-masked]>
Date: Mon, 24 Nov 2014 07:54:20 +0000

Hi Minpeng,

The following inline is my understanding.

Thanks,
Jianjie

发件人: I2nsf [mailto:[email-masked]] 代表 Minpeng Qi
发送时间: 2014年11月22日 17:53
收件人: Linda Dunbar; 'Joseph Salowey'; [email-masked]
主题: [I2nsf] 答复: Summary of the use cases being discussed at the I2NSF BOF

Hi Linda,

1.       In the closed mode, as there are interfaces for client<->OSS/BSS and OSS/BSS<->vNSF(with agent), why do we need an interface for client<->vNSF. What is the benefit?
Jianjie: I think these three interfaces have several combinations, for example, [client<->OSS/BSS, OSS/BSS<->vNSF] and [client<->vNSF, vNSF <->OSS/BSS]. They can be applicable for difference use cases.

2.       The interfaces client<-> vNSF and OSS/BSS<-> vNSF are covered with I2NSF scope. And the interface client<->OSS/BSS is not covered. Should we to keep it out of I2NSF scope?
Jianjie: If for [client<->OSS/BSS, OSS/BSS<->vNSF] case, maybe the information communicated via client<->OSS/BSS interface should also be considered.

3.       Why do we need an explicit adapter here? My understanding the adapter plays a role in translate potential standard I2NSF messages into vendor-specific commands to operate vNSF. They must be developed by same vendor, and the interface is not open to others. Should the interface adapter<->vNSF be covered in I2NSF? If not, could we considered both adapter and vNSF should be seen as a whole?
Jianjie: This depends on how we define the adapter, vNSF, etc. The adapter can be regarded as a logical mapping function, which could be co-located with vNSF or standalone. If the adapter and the vNSF are separated, I think the interface between them are not in the scope. I agree with you that both adapter and vNSF can be seen as a box.

BRs,
Minpeng

发件人: I2nsf [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2014年11月21日 6:52
收件人: Joseph Salowey; [email-masked]<mailto:[email-masked]>
主题: [I2nsf] Summary of the use cases being discussed at the I2NSF BOF

Best regards,

Linda

Cheers,

Joe

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 24 Nov 2014 18:13:12 +0000

Min Peng,

 “In the closed mode, as there are interfaces for client<->OSS/BSS and OSS/BSS<->vNSF(with agent), why do we need an interface for client<->vNSF. What is the benefit?”

That is a good question! I think it is the GUI interface for clients. (but we need to double check with Diego).

Answers to other questions are inserted below:

From: Minpeng Qi [mailto:[email-masked]]
Sent: Saturday, November 22, 2014 3:53 AM
To: Linda Dunbar; 'Joseph Salowey'; [email-masked]
Subject: 答复: [I2nsf] Summary of the use cases being discussed at the I2NSF BOF

Hi Linda,

2.       The interfaces client<-> vNSF and OSS/BSS<-> vNSF are covered with I2NSF scope. And the interface client<->OSS/BSS is not covered. Should we to keep it out of I2NSF scope?
[Linda] I would think it is the simple GUI interface.

3.       Why do we need an explicit adapter here? My understanding the adapter plays a role in translate potential standard I2NSF messages into vendor-specific commands to operate vNSF. They must be developed by same vendor, and the interface is not open to others. Should the interface adapter<->vNSF be covered in I2NSF? If not, could we considered both adapter and vNSF should be seen as a whole?
[Linda] That is good suggestion. I don’t anticipate Adapter<->vNSF to be covered by I2NSF. They would be vendor specific. “adapter” box is only to show that it terminates the standard interface defined by I2NSF.

Linda

BRs,
Minpeng

Best regards,

Linda

Cheers,

Joe

---

From: "Minpeng Qi" <[email-masked]>
Date: Tue, 25 Nov 2014 22:45:35 +0800

Hi Jianjie,

For the interface, I have the same opinion that it could be more detailed different use case. 

And for adapter, IMHO, no matter adapter and vNSF are separate or co-located, the interface will always not be seen by 3rd party except device provider. As a result, we could consider the adapter and device as an implementation issue. And we can merge them into one box, which represents a standard I2NSF related interface based device.

BRs,

Minpeng

发件人: I2nsf [mailto:[email-masked]] 代表 Youjianjie
发送时间: 2014年11月24日 15:54
收件人: Minpeng Qi; Linda Dunbar; 'Joseph Salowey'; [email-masked]
主题: [I2nsf] 答复: 答复: Summary of the use cases being discussed at the I2NSF BOF

Hi Minpeng,

Thanks,

Jianjie

Hi Linda,

BRs,

Minpeng                                        

 

 

 

*      Stated by Sam Hartman

Best regards, 

Linda 

Cheers,

Joe

---

From: "Minpeng Qi" <[email-masked]>
Date: Tue, 25 Nov 2014 22:51:38 +0800

Hi Linda,

For client<->vNSF interface, as I replied a little earlier to Jianjie, it could be used in a different use case. So let’s wait Diego’s clarification.

But client<->OSS/BSS interface, I have a slightly different opinion based the discussion with Jianjie. Client, OSS/BSS, vNSF(with agent) could play a different role in this system. I don’t think OSS/BSS is just proxy for client to transfer message to vNSF. So it could not be seen as GUI interface. What is more, if we leave such interface as implementation issue, it may bring complexity for clients.

For adapter, as I replied to Jianjie, the adapter and device could be merged together.

BRs,

Minpeng 

发件人: Linda Dunbar [mailto:[email-masked]] 
发送时间: 2014年11月25日 2:13
收件人: Minpeng Qi; 'Joseph Salowey'; [email-masked]
主题: RE: [I2nsf] Summary of the use cases being discussed at the I2NSF BOF

Min Peng, 

 

Hi Linda,

Linda

BRs,

Minpeng                                        

 

 

 

*      Stated by Sam Hartman

Best regards, 

Linda 

Cheers,

Joe