Subject: [I2nsf] FW: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Jan 2015 09:31:54 +0000

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, January 05, 2015 9:11 PM
> To: [email-masked]
> Subject: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling
> 
> 
> FYI, if you hoping for some kind of BoF in March, now's the time to start
> talking to a relevant AD.
> 
> Cheers,
> S.
> 
> 
> -------- Forwarded Message --------
> Subject: IETF 92 - Working Group/BOF/IRTF Scheduling
> Date: Mon, 05 Jan 2015 10:41:51 -0800
> From: IETF Agenda <[email-masked]>
> Reply-To: IETF Agenda <[email-masked]>
> To: Working Group Chairs <[email-masked]>
> CC: [email-masked]
> 
> -----------------------------------------------------------------
> IETF 92 – Dallas, TX, USA
> Meeting Dates: March 22 – 27, 2015
> -----------------------------------------------------------------
> 
> We are accepting scheduling requests for all Working Groups, BOFs, and
> Research Groups starting today.
> 
> NOTE: There is an option for an experimental room set for IETF 92. This set
> will include a boardroom style at the front and classroom seats behind it.
> Please check the box on the session request form if your working group is
> willing to participate (subject to availability).
> 
> The milestones and deadlines for scheduling-related activities are as
> follows:
> Cut-off dates are subject to change.
> 
> •	2015-01-05 (Monday): Working Group and BOF scheduling begins. To
> request a Working Group session, use the IETF Meeting Session Request
> Tool.
> •	2015-02-06 (Friday): Cut-off date for requests to schedule Working
> Group meetings at UTC 23:59. To request a Working Group session, use the
> IETF Meeting Session Request Tool.
> •	2015-02-06 (Friday): Cut-off date for BOF proposal requests to Area
> Directors at UTC 23:59. To request a BOF, please see instructions on
> Requesting a BOF.
> •	2015-02-13 (Friday): Cut-off date for Area Directors to approve BOFs
> at UTC 23:59.
> •	2015-02-20 (Friday): Preliminary agenda published for comment.
> •	2015-02-25 (Wednesday): Cut-off date for requests to reschedule
> Working Group and BOF meetings UTC 23:59.
> •	2015-02-27 (Friday): Final agenda to be published.
> •	2015-03-09 (Monday): Draft Working Group agendas due by UTC
> 23:59,
> upload using IETF Meeting Materials Management Tool.
> •	2015-03-16 (Monday): Revised Working Group agendas due by UTC
> 23:59,
> upload using IETF Meeting Materials Management Tool.
> •	2015-04-17 (Friday): Proceedings submission cutoff date by UTC
> 23:59,
> upload using IETF Meeting Materials Management Tool.
> •	2015-05-11 (Monday): Proceedings submission corrections cutoff
> date by
> UTC 23:59, upload using IETF Meeting Materials Management Tool.
> 
> 
> ==========================================================
> =====
> For your convenience, comprehensive information on requesting meeting
> sessions is presented below:
> 
> 1. Requests to schedule Working Group sessions should be submitted using
> the "IETF Meeting Session Request Tool," a Web-based tool for submitting all
> of the information required by the Secretariat to schedule your sessions.
> The URL for the tool is:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_secr_sreq_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZ
> H64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sPWtCxB7
> cN6z_Fb662fQnngtXZQ-AsDBKbE34ridg&s=i1jq2PqahpA6pKWQVGfAAN9y-
> qPFrJNGgH4BclnUhuE&e=
> 
> Instructions for using the tool are available at:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_wg_request-2Dtool-
> 2Dinstructions.html&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR3
> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sPWtCxB7cN6z_Fb662fQnng
> tXZQ-AsDBKbE34ridg&s=5EeRExhOH4yMqX-
> Sx3JqPl_VEsIOPirf8qEn4fJsv34&e=
> 
> If you require an account on this tool, or assistance in using it, then please
> send a message to [email-masked].  If you are unable to use the tool,
> then you may send your request via e-mail to [email-masked], with a copy
> to the appropriate Area Director(s).
> 
> Requests to schedule BOF sessions must be sent to [email-masked] with a
> copy to the appropriate Area Director(s).
> 
> When submitting a Working Group or BOF session request by e-mail, please
> include the Working Group or BOF acronym in the Subject line.
> 
> 2. BOFs will NOT be scheduled unless the Area Director approves the BOF.
> The proponents behind a BOF need to contact a relevant Area Director,
> preferably well in advance of the BOF approval deadline date. The AD needs
> to have the full name of the BOF, its acronym, suggested names of chairs, an
> agenda, full description of the BOF and the information covered in item 4.
> Please read RFC 5434 for instructions on how to drive a successful BOF effort.
> The approval depends on, for instance, Internet-Drafts and list discussion on
> the suggested topic. BOF agenda requests, if approved, will be submitted to
> the IETF Secretariat by the ADs.
> 
> 3. A Working Group may request either one or two sessions.  If your Working
> Group requires more than two sessions, then your request must be
> approved by an Area Director.  Additional sessions will be assigned, based on
> availability, after Wednesday, February 25th, 2015, the cut-off date for
> requests to reschedule a session.
> 
> 4. You MUST provide the following information before a Working Group or
> BOF session will be scheduled:
> 
> a. Working Group or BOF full name with acronym in brackets:
> b. AREA under which Working Group or BOF appears:
> c. CONFLICTS you wish to avoid, please be as specific as possible:
> d. Expected Attendance:
> e. Special requests:
> f. Number of sessions:
> g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours
> 
> For more information on scheduling Working Group and BOF sessions, please
> refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures"
> (https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_rfc_rfc2418.txt&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH6
> 4Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sPWtCxB7cN
> 6z_Fb662fQnngtXZQ-
> AsDBKbE34ridg&s=8gXThkuRACrs4Zb1HItc2Y0V04SnkzmZC1NdcyJh_i4&e= ).
> 
> ==========================================================
> =====
> 
> Submitting Session Agendas
> 
> For the convenience of meeting attendees, we ask that you submit the
> agendas for your Working Group sessions as early as possible.  Draft Working
> Group agendas are due Monday, March 9th, 2015 at UTC 23:59.
> Revised Working Group agendas are due no later than Monday, March 16th,
> 2015 at UTC 23:59.  The proposed agenda for a BOF session should be
> submitted along with your request for a session.  Please be sure to copy your
> Area Director on that message.
> 
> Please submit the agendas for your Working Group sessions using the "IETF
> Meeting Materials Management Tool," a Web-based tool for making your
> meeting agenda, minutes, and presentation slides available to the
> community before, during, and after an IETF meeting.  If you are a BOF chair,
> then you may use the tool to submit a revised agenda as well as other
> materials for your BOF once the BOF has been approved.
> 
> The URL for the tool is:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_secr_proceedings_&d=AwIGaQ&c=BFpWQw8bsuK
> pl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sP
> WtCxB7cN6z_Fb662fQnngtXZQ-
> AsDBKbE34ridg&s=ZaOtFwWSBU4UGECVA6JMGoTHBLYubbRPZ0VmSLiVP7A
> &e=
> 
> Additional information about this tool is available at:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_wg_meeting-
> 2Dmaterials.html&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sPWtCxB7cN6z_Fb662fQnngt
> XZQ-
> AsDBKbE34ridg&s=IZHOSGbbPXaYMDnGp6iXi_DT96UUFVlCGqLHg8thCtk&e=
> 
> Agendas submitted via the tool will be available to the public on the "IETF
> Meeting Materials" webpage as soon as they are submitted.
> 
> The URL for the "IETF 92 Meeting Materials" Web page is:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_meeting_92_materials.html&d=AwIGaQ&c=BFpW
> Qw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA
> &m=_6sPWtCxB7cN6z_Fb662fQnngtXZQ-
> AsDBKbE34ridg&s=US9EO5O9JUXt2VcAmcosguNu6d4ShBbZ9UsbPDfabyk&e
> =
> 
> If you are a Working Group chair, then you already have accounts on the
> "IETF Meeting Session Request Tool" and the "IETF Meeting Materials
> Management Tool."  The same User ID and password will work for both tools.
> If you are a BOF chair who is not also a Working Group chair, then you will be
> given an account on the "IETF Meeting Materials Management Tool" when
> your BOF has been approved.  If you require assistance in using either tool,
> or wish to report a bug, then please send a message to:
> [email-masked].
> 
> ==========================================================
> =====
> For your convenience please find a list of the IETF Area Directors with their e-
> mail addresses below:
> 
> IETF Chair
> Jari Arkko <[email-masked]>
> 
> Applications Area (app)
> Barry Leiba <[email-masked]>
> Pete Resnick <[email-masked]>
> 
> Internet Area (int)
> Brian Haberman <[email-masked]> Ted Lemon
> <[email-masked]>
> 
> Operations & Management Area (ops)
> Benoit Claise <[email-masked]>
> Joel Jaeggli <[email-masked]>
> 
> Real-time Applications and Infrastructure Area (rai) Richard Barnes
> <[email-masked]> Alissa Cooper <[email-masked]>
> 
> Routing Area (rtg)
> Alia Atlas <[email-masked]>
> Adrian Farrel <[email-masked]>
> 
> Security Area (sec)
> Stephen Farrell <[email-masked]> Kathleen Moriarty
> <[email-masked]>
> 
> Transport Area (tsv)
> Spencer Dawkins  <[email-masked]> Martin Stiemerling
> <[email-masked]>
> 
> 
> ==========================================================
> =
> 91st IETF Meeting Attendance Numbers
> 
> 6lo – 77
> 6man - 86
> 6tisch - 50
> ace - 70
> actn - 119
> alto  - 12
> anima - 86
> appsawg/apparea - 104
> aqm – 60
> arcmedia (BoF) - 21
> avtcore - 58
> avtext – 17
> bess – 82
> bess (2nd session) - 19
> bfd – 43
> bier (BoF) - 163
> bmwg - 25
> ccamp - 42
> cdni – 49
> clue – 22
> clue (2nd session) - 18
> core - 55
> core (2nd session) – 68
> dane - 137
> dclcrg (RG BoF) – 34
> detnet (BoF) - 87
> dhc – 35
> dice - 82
> dime - 15
> dispatch - 34
> dmm - 31
> dnsop - 145
> dnssd – 70
> dprive – 131
> dtn – 45
> ecrit - 21
> eppext – 39
> grow - 42
> homenet - 103
> httpauth - 35
> httpbis - 114
> httpbis (2nd session) – 161
> i2nsf - 102
> i2rs - 179
> ianaplan – 79
> iccrg (RG) - 44
> icnrg (RG) - 52
> idr – 91
> idr (2nd session) - 64
> intarea (AG) - 41
> ippm - 31
> ipsecme - 30
> IRTF Open Meeting - 100
> isis - 38
> jose - 32
> kitten - 29
> lime - 63
> lisp - 30
> lmap - 46
> lwig - 32
> manet - 21
> mboned - 41
> mif – 40
> mile - 23
> mmusic - 43
> mmusic (2nd session) - 43
> mpls - 88
> mpls (2nd session) - 78
> mptcp - 49
> netconf - 87
> netmod – 72
> netmod (2nd session) - 35
> ntp (combined with tictoc) - 18
> nvo3 – 123
> nwcrg (RG) - 19
> oauth - 51
> opsawg/opsarea - 37
> ospf – 55
> pals - 72
> pce – 64
> pcp - 26
> pim - 41
> ppsp - 16
> precis - 25
> radext - 11
> rmcat - 50
> rtcweb - 107
> rtcweb (2nd session) - 111
> rtgarea (AG) - 97
> rtgwg - 82
> saag (AG) - 153
> sacm - 31
> sacm (2nd session) - 26
> scim - 14
> sdnrg (RG) – 213
> sfc - 179
> sidr - 55
> sipcore - 37
> siprec - 20
> softwire - 47
> spring - 90
> stir - 38
> straw - 26
> taps - 40
> tcpinc - 44
> tcpm - 34
> tictoc (combined with ntp) - 18
> tls - 95
> tram - 39
> trans - 36
> trill - 15
> tsvwg - 40
> tsvwg (2nd session) - 47
> uta - 113
> v6ops - 105
> v6ops (2nd session) – 80
> xrblock - 12
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_saag&d=AwIGaQ&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_6sPWt
> CxB7cN6z_Fb662fQnngtXZQ-AsDBKbE34ridg&s=ej35SkqZaXSqLBhlj7yy4d-
> qtb39k6fiNSXwrXQ73Ag&e=

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 6 Jan 2015 21:32:53 +0000

Thanks Dan for forwarding this announcement. Hope everyone has rested well over the holidays.

Just to refresh people's memory on the focused I2NSF use case extracted from use cases presented by Diego Lopez (Telefonica), MinPeng Qi (China Mobile: use case #2 &#3), and Nic Leymann (Deutsche Telecom))at the Nov BoF:

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.

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

Here are potential types of I2NSF clients:
•       Enterprise security administrators
•       Application Controller
–       e.g. Video Conference Mgr/Controller sends real time security policies for specific flows
•       Security functions send requests for more sophisticated functions when detect something suspicious

Potential Work Items:

•       Content (Information/Data Model or APIs) traversed through the interface:
–       Information model for security policies
–       Data model (e.g. Yang model) for security policies,
–       Focus on the common policies (among various vendors),
•       Mechanism for carrying vendor specific policies
–       The secure mechanism to carry the content
–       Secure transport, e.g. TLS
•       Authentication and registration mechanism
–       Who is legitimate to issue security policies.

We need contributions on information/data model for common security functions, abstract protocol description to show what information needs to be passed from where to where, protocol requirement, the actual protocol, etc.

Let’s have a good 2015.

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 06, 2015 3:32 AM
To: [email-masked]
Subject: [I2nsf] FW: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling

> To: [email-masked]<mailto:[email-masked]>
> FYI, if you hoping for some kind of BoF in March, now's the time to
> start talking to a relevant AD.
>
> Cheers,
> S.
>
>
> From: IETF Agenda <[email-masked]<mailto:[email-masked]>>
> Reply-To: IETF Agenda <[email-masked]<mailto:[email-masked]>>
> To: Working Group Chairs <[email-masked]<mailto:[email-masked]>>
> CC: [email-masked]<mailto:[email-masked]>
>
> NOTE: There is an option for an experimental room set for IETF 92.
> This set will include a boardroom style at the front and classroom seats behind it.
> Please check the box on the session request form if your working group
> is willing to participate (subject to availability).
>
> Group meetings at UTC 23:59. To request a Working Group session, use
> the IETF Meeting Session Request Tool.
> 1. Requests to schedule Working Group sessions should be submitted
> using the "IETF Meeting Session Request Tool," a Web-based tool for
> submitting all of the information required by the Secretariat to schedule your sessions.
> The URL for the tool is:
>
> If you require an account on this tool, or assistance in using it,
> then please send a message to [email-masked]<mailto:[email-masked]>.  If you are unable
> to use the tool, then you may send your request via e-mail to
> [email-masked]<mailto:[email-masked]>, with a copy to the appropriate Area Director(s).
>
> Requests to schedule BOF sessions must be sent to [email-masked]<mailto:[email-masked]> with
> a copy to the appropriate Area Director(s).
>
> When submitting a Working Group or BOF session request by e-mail,
> please include the Working Group or BOF acronym in the Subject line.
>
> preferably well in advance of the BOF approval deadline date. The AD
> needs to have the full name of the BOF, its acronym, suggested names
> of chairs, an agenda, full description of the BOF and the information covered in item 4.
> The approval depends on, for instance, Internet-Drafts and list
> discussion on the suggested topic. BOF agenda requests, if approved,
> will be submitted to the IETF Secretariat by the ADs.
>
> 3. A Working Group may request either one or two sessions.  If your
> Working Group requires more than two sessions, then your request must
> be approved by an Area Director.  Additional sessions will be
> assigned, based on availability, after Wednesday, February 25th, 2015,
> the cut-off date for requests to reschedule a session.
>
> 4. You MUST provide the following information before a Working Group
> or BOF session will be scheduled:
>
> For more information on scheduling Working Group and BOF sessions,
> please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures"
> agendas for your Working Group sessions as early as possible.  Draft
> Working Group agendas are due Monday, March 9th, 2015 at UTC 23:59.
> submitted along with your request for a session.  Please be sure to
> copy your Area Director on that message.
>
> Please submit the agendas for your Working Group sessions using the
> "IETF Meeting Materials Management Tool," a Web-based tool for making
> your meeting agenda, minutes, and presentation slides available to the
> community before, during, and after an IETF meeting.  If you are a BOF
> chair, then you may use the tool to submit a revised agenda as well as
> other materials for your BOF once the BOF has been approved.
>
> The URL for the tool is:
>
> Agendas submitted via the tool will be available to the public on the
> "IETF Meeting Materials" webpage as soon as they are submitted.
>
> If you are a Working Group chair, then you already have accounts on
> the "IETF Meeting Session Request Tool" and the "IETF Meeting
> Materials Management Tool."  The same User ID and password will work for both tools.
> If you are a BOF chair who is not also a Working Group chair, then you
> will be given an account on the "IETF Meeting Materials Management
> Tool" when your BOF has been approved.  If you require assistance in
> using either tool, or wish to report a bug, then please send a message to:
> [email-masked]<mailto:[email-masked]>.
>
> For your convenience please find a list of the IETF Area Directors
> with their e- mail addresses below:
>
> IETF Chair
> Jari Arkko <[email-masked]<mailto:[email-masked]>>
>
> Applications Area (app)
> Barry Leiba <[email-masked]<mailto:[email-masked]>>
> Pete Resnick <[email-masked]<mailto:[email-masked]>>
>
> Internet Area (int)
> Brian Haberman <[email-masked]<mailto:[email-masked]>> Ted Lemon
> <[email-masked]<mailto:[email-masked]>>
>
> Benoit Claise <[email-masked]<mailto:[email-masked]>>
> Joel Jaeggli <[email-masked]<mailto:[email-masked]>>
>
> <[email-masked]<mailto:[email-masked]>> Alissa Cooper <[email-masked]<mailto:[email-masked]>>
>
> Routing Area (rtg)
> Alia Atlas <[email-masked]<mailto:[email-masked]>>
> Adrian Farrel <[email-masked]<mailto:[email-masked]>>
>
> Security Area (sec)
> Stephen Farrell <[email-masked]<mailto:[email-masked]>> Kathleen Moriarty
> <[email-masked]<mailto:[email-masked]>>
>
> Transport Area (tsv)
> Spencer Dawkins  <[email-masked]<mailto:[email-masked]>> Martin Stiemerling
> <[email-masked]<mailto:[email-masked]>>
>
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Jan 2015 08:46:53 +0000

Hi Linda,

Thanks! Good status recap.

Yes, at this point in time we need contributions.

Do you plan to update draft-dunbar-i2nsf-problem-statement to bring it in line with what we learned at the BOF and in the discussions that followed and include some of the information below?

Regards,

Dan

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 11:33 PM
To: Romascanu, Dan (Dan); [email-masked]
Cc: Joseph Salowey
Subject: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Here are potential types of I2NSF clients:
·         Enterprise security administrators
·         Application Controller
·         e.g. Video Conference Mgr/Controller sends real time security policies for specific flows
·         Security functions send requests for more sophisticated functions when detect something suspicious

Potential Work Items:

·         Content (Information/Data Model or APIs) traversed through the interface:
·         Information model for security policies
·         Data model (e.g. Yang model) for security policies,
·         Focus on the common policies (among various vendors),
·         Mechanism for carrying vendor specific policies
·         The secure mechanism to carry the content
·         Secure transport, e.g. TLS
·         Authentication and registration mechanism
·         Who is legitimate to issue security policies.

Let’s have a good 2015.

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 06, 2015 3:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] FW: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FMV1AzVbSrYVpGmC7j9_4ilahba6FEECYVI6HkAB0nc&s=6lIeBK2RG6dAu9F4FFTcKz9I2fJISy7-WS03FwBWfA0&e=>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Jan 2015 16:32:24 +0000

Dan,

Yes, we will update the problem statement.

Linda

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, January 07, 2015 2:47 AM
To: Linda Dunbar; [email-masked]
Cc: Joseph Salowey
Subject: RE: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Hi Linda,

Regards,

Dan

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 11:33 PM
To: Romascanu, Dan (Dan); [email-masked]<mailto:[email-masked]>
Cc: Joseph Salowey
Subject: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 8 Jan 2015 01:35:04 +0000

Hi all,
From our understanding of the “Intent Driven” interface between the client and vNSF, we try to propose an initial information model of vNSF configuration policy for more discussion, as followed:

A vNSF configuration policy IM can be described as:

<tenant> <user_group> <service_group> <action><track> <condition>

Therein,

tenant

user_group

service-group

action

track

condition

Definition

a specific user/user group under one tenant

identify the traffic that need to be enforced the policy rules

network behaviors enforced on selected traffic

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

Example 1: John is permitted to access facebook from 20:00 to 22:00
< user_group > John
<service-group> facebook
<action> permit
<condition> From 20:00 to 22:00

Example 2: Department A of Company H is denied to access QQ from 8:00 to 18:00
<tenant> Company H
< user_group > Department A
<service-group> QQ
<action> deny
<condition> From 8:00 to 18:00

Of course, the only goal of above content is just to arise the more specific and detailed discussion of the solution, to help us get a more clear picture of the possible work and scope of this WG. So, any of your comments and thoughts and warmly welcome~~

B.R.
Frank
From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 07, 2015 5:33 AM
To: Romascanu, Dan (Dan); [email-masked]
Cc: Joseph Salowey
Subject: [I2nsf] I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Jan 2015 16:59:18 -0900

There's been a bunch of work done over the years on authorization
and policy languages in the IETF and elsewhere.  Policy languages
can be trickier than you might think, potentially being highly
sensitive to policy rule ordering, etc. and needing a formal
process (let's call it "logic") for making sure that rule
application has deterministic outcomes.  There are many
policy languages out there already based on some form of predicate
logic.

I continue to be confused by what's being proposed (if that
is indeed what's going on - I can't really tell) - it seems to
me that there's not a lot here that's peculiar to virtualized,
network-provided, decomposed security services.  "John's
Facebook use is limited to whatever hours" and "Department A of
Company H may not access <whatever>" are run-of-the-mill firewall
rules.

It seems to me that if you really want to make use of IETF time
and resources, it may be more productive to focus on how you're
going to transport these rules between which network elements
and how this is different from what other virtualized network
services do.  I can't imagine that looking at policy languages
and inventing a new policy grammar is going to be fruitful
for anybody involved.

I really think that you should hold off on having another BOF
until you've got a specific proposal that is at least partially
baked.  It absolutely is not in the best interest of moving
work forward to have an unsuccessful BOF.  It decreases the
likelihood of work being chartered rather than increases it.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 8 Jan 2015 02:37:36 +0000

Melinda, 

Please consider this scenario:

An Application Controller (e.g. Web Conference controller) needs to inform the network to apply certain security policies to "John's WebEx session". Network is not aware of "who is John" ahead of time. So you can't use the traditional Policy setting for John's conference call. 

When "John" initiates the "Web Conference" call to the "Web Conference Controller", the "Web Conference Controller" can use the I2NSF interface to pass the needed security polices for John's conference to the network. 

It would be great that I2NSF can reuse some of " many policy languages out there already based on some form of predicate logic". Can you list some?

Thank you. 
Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, January 07, 2015 7:59 PM
To: [email-masked]
Subject: Re: [I2nsf] I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

There's been a bunch of work done over the years on authorization and policy languages in the IETF and elsewhere.  Policy languages can be trickier than you might think, potentially being highly sensitive to policy rule ordering, etc. and needing a formal process (let's call it "logic") for making sure that rule application has deterministic outcomes.  There are many policy languages out there already based on some form of predicate logic.

I continue to be confused by what's being proposed (if that is indeed what's going on - I can't really tell) - it seems to me that there's not a lot here that's peculiar to virtualized, network-provided, decomposed security services.  "John's Facebook use is limited to whatever hours" and "Department A of Company H may not access <whatever>" are run-of-the-mill firewall rules.

It seems to me that if you really want to make use of IETF time and resources, it may be more productive to focus on how you're going to transport these rules between which network elements and how this is different from what other virtualized network services do.  I can't imagine that looking at policy languages and inventing a new policy grammar is going to be fruitful for anybody involved.

I really think that you should hold off on having another BOF until you've got a specific proposal that is at least partially baked.  It absolutely is not in the best interest of moving work forward to have an unsuccessful BOF.  It decreases the likelihood of work being chartered rather than increases it.

Melinda

[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Jan 2015 18:02:24 -0900

On 1/7/15 5:37 PM, Linda Dunbar wrote:
> When "John" initiates the "Web Conference" call to the "Web
> Conference Controller", the "Web Conference Controller" can use the
> I2NSF interface to pass the needed security polices for John's
> conference to the network.

I think a major part of the problem you're having identifying
interesting work is that you haven't described what you mean
by "network" here.  If what you mean by "network" is an outsourced
security service, it's not clear to me that there wouldn't be the
same relationship between that service and network users that
there would be between a local service and network users.
Among the many things that are underdescribed and underspecified
are whether what's under discussion is
 . provisioning security devices
 . provisioning configuration to non-local security
   devices
 . dynamic application of local policy to non-local
   security devices
and so on.  So far, approximately none of those look like
problems that are peculiar to "network security as a service."

> It would be great that I2NSF can reuse some of " many policy
> languages out there already based on some form of predicate logic".
> Can you list some?

I think it would be a fairly serious mistake to try to undertake
the development of a policy language - I'm still unclear on exactly
what it is that you'd like to work on but I don't think that
you should be trying to identify an authorization language or decide
that it's something you'd like to work on until it's very clear that
you actually need one.

Are there product people that you can work with on this?  They
should have a clear idea of what they need and what their
interoperability requirements are.

Melinda

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 8 Jan 2015 04:26:55 +0000

Hi Melinda,
Thanks for your quick comments, please see my response inline:

B.R.
Frank

> Sent: Thursday, January 08, 2015 9:59 AM
> To: [email-masked]
> There's been a bunch of work done over the years on authorization and
> policy languages in the IETF and elsewhere.  Policy languages can be trickier
> than you might think, potentially being highly sensitive to policy rule
> ordering, etc. and needing a formal process (let's call it "logic") for making
> sure that rule application has deterministic outcomes.  There are many
> policy languages out there already based on some form of predicate logic.
> 
[Frank] : Understand and I think the above works can provide us a good base. We absolutely do not want to reinvent a wheel.

> I continue to be confused by what's being proposed (if that is indeed what's
> going on - I can't really tell) - it seems to me that there's not a lot here that's
> peculiar to virtualized, network-provided, decomposed security services.
> "John's Facebook use is limited to whatever hours" and "Department A of
> Company H may not access <whatever>" are run-of-the-mill firewall rules.
> 
[Frank] : I think the policy Information Model is just part of the whole work. Beyond it, our works also include the definition of the whole framework, the transport mechanism, authentication mechanism, security mechanism, etc. In addition, my personal thought is new "network security as a service" scenarios bring new requirements that configuration/management information model between user/operator and vNSFs needs to be more flexible, simple and infrastructure-independent, comparing to the traditional physical network security device's configuration. This will greatly ease vNSF operator's management burden and usage complexity of users.

> It seems to me that if you really want to make use of IETF time and resources,
> it may be more productive to focus on how you're going to transport these
> rules between which network elements and how this is different from what
> other virtualized network services do.  I can't imagine that looking at policy
> languages and inventing a new policy grammar is going to be fruitful for
> anybody involved.
> 
> I really think that you should hold off on having another BOF until you've got
> a specific proposal that is at least partially baked.  It absolutely is not in the
> best interest of moving work forward to have an unsuccessful BOF.  It
> decreases the likelihood of work being chartered rather than increases it.
> 
> Melinda
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 8 Jan 2015 22:59:32 +0000

Melinda, 

Replies to your comments are inserted below:

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2015 9:02 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [I2nsf] I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

On 1/7/15 5:37 PM, Linda Dunbar wrote:
> When "John" initiates the "Web Conference" call to the "Web Conference 
> Controller", the "Web Conference Controller" can use the I2NSF 
> interface to pass the needed security polices for John's conference to 
> the network.

I think a major part of the problem you're having identifying interesting work is that you haven't described what you mean by "network" here. 

[Linda] The word "network" used in the above example is referring to a hook (or a "socket") for the Application Controller to pass down the specific security policies with regard to "John's conference flow" traversing through the network. When some encrypted conferences can't pass through the existing firewalls in the network, the "security policies" for "John's conference flow" could be "PASS" (of cause with the needed identifier in the packets to differentiate other traffic originated from John's device). 

 If what you mean by "network" is an outsourced security service, 

[Linda] under this scenario (i.e. outsourced security service), we assume that the traffic have to traverse (or be steered through) the security devices managed by the "Outsourced Security Service ". The requested security polices by the clients are passed to the "Outsourced Security Service Controller or management system". 

it's not clear to me that there wouldn't be the same relationship between that service and network users that there would be between a local service and network users.
Among the many things that are underdescribed and underspecified are whether what's under discussion is  . provisioning security devices  . provisioning configuration to non-local security
   devices
 . dynamic application of local policy to non-local
   security devices
and so on.  

[Linda] I2NSF is to specify clients (or application) oriented Information Model and the mechanism to carry them for the needed security functions to be applied to clients' traffic. It is not the intent of I2NSF to describe how those Information Model is translated to specific security devices configuration because the detailed configuration depends on where the device is, the vendor, etc. 

So far, approximately none of those look like problems that are peculiar to "network security as a service."
[Linda] Agree. I see I2NSF provides some tools for the "Network Security as a service". But the actual services require much more. 

> It would be great that I2NSF can reuse some of " many policy languages 
> out there already based on some form of predicate logic".
> Can you list some?

I think it would be a fairly serious mistake to try to undertake the development of a policy language - I'm still unclear on exactly what it is that you'd like to work on but I don't think that you should be trying to identify an authorization language or decide that it's something you'd like to work on until it's very clear that you actually need one.

[Linda] I don't think that I2NSF is to develop some "policy languages". Here are the potential work items:

Content (or APIs) traversed through the interface: 
- Information model for security policies
- Data model (e.g. Yang model) for security policies, 
- Focus on the common policies (among various vendors), 
- Mechanism for carrying vendor specific policies

The secure mechanism to carry the content
- Secure transport, e.g. TLS

Authentication and registration mechanism (utilize existing mechanisms)
- Who is legitimate to issue security policies.  

Are there product people that you can work with on this?  They should have a clear idea of what they need and what their interoperability requirements are.
[Linda] Yes. On the product side, it is called the North Bound Interface to security controller(s). 

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 20 Jan 2015 21:50:28 +0000

I2NSF group:

Role Based Access Control (RBAC) and Role Based Security was adopted as an ANSI/INCITS standard a few years ago: http://csrc.nist.gov/groups/SNS/rbac/index.html

What do you think of using RBAC as the starting point for I2NSF? We can start with simple functions, e.g. FW, as described by Frank in earlier email, even though some details will need to be adjusted to conform with RBAC format

Cheers, Linda

From: Xialiang (Frank)
Sent: Wednesday, January 07, 2015 7:35 PM
To: Linda Dunbar; Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]
Subject: RE: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 20 Jan 2015 20:46:29 -0500

Hi Linda,

A cursory search of the literature and R&D
suggests that there is considerable available
material on this subject in a cloud computing
virtualisation environment.  A little explicitly
relating to NFV.  See, e.g., attached NFV SEC 003.
It might be useful to pull some of this material
together, analyze and summarize.

--tony

On 2015-01-20 4:50 PM, Linda Dunbar wrote:
>
> What do you think of using RBAC as the starting point for I2NSF? We 
> can start with simple functions, e.g. FW, as described by Frank in 
> earlier email, even though some details will need to be adjusted to 
> conform with RBAC format
>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 21 Jan 2015 08:40:48 +0000

Hi,

A couple of remarks to Linda's proposal and Tony's reply...

@Linda: As far as I understand it, I2NSF is intended to provide an OAM interface to virtualized security services, including selection and attestation. RBAC would only be applicable to define what action can be done by any of the agents (user, operator, service provider...) and therefore build an authorization model, but to model the intent-driven interface...

@Tony: Definitely NFV SEC 003 is a valuable input both for the authorization and the attestation phases, but again we need to advance in the interface and the protocols to implement all the vNSF OAM mechanisms.

Be goode,

On 21 Jan 2015, at 02:46 , Tony Rutkowski <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda,

--tony

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

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"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: Linda Dunbar <[email-masked]>
Date: Wed, 21 Jan 2015 16:43:30 +0000

Diego,

OAM (Operation, Administration and Management includes configuration, fault monitoring, management etc.

The configuration aspect of I2NSF's OAM should focus on the needed behavior (or user/application intent, the descriptor) of the security functions, instead of links/ports oriented.  Same applies to fault monitoring, and management of the virtual security functions.  The security function intent descriptor can be achieved by one Security function or multiple, which is transparent to users/applications.

It is somewhat like North Bound Interface. Different vendors have their own  adapter (or controller) to translate those intent driven security function descriptors to their own vendor specific configurations.

With RBAC, the Security function descriptor can be somewhat like:

Maybe the fault monitoring or management can be structured in the similar fashion.

Linda

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 2:41 AM
To: [email-masked]
Cc: Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; [email-masked]; John Strassner
Subject: Re: [I2nsf] How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi,

Be goode,

Hi Linda,

--tony

Dr Diego R. Lopez
Telefonica I+D

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

---

From: John Strassner <[email-masked]>
Date: Mon, 26 Jan 2015 21:39:13 +0000

Hi Tony,

Currently, there is no entity in NFV that can perform RBAC (or other similar variations, such as ABAC) functions. There is some ongoing research that is being conducted; I'm happy to try and do a brief survey if others will join in.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Tuesday, January 20, 2015 5:46 PM
To: Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]; John Strassner
Subject: Re: [I2nsf] How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi Linda,

--tony

---

From: John Strassner <[email-masked]>
Date: Mon, 26 Jan 2015 22:02:58 +0000

Hi Diego,

Thanks for your comments. As you point out, RBAC itself is about access control. It is not itself declarative/intent-based/goal-driven. That being said, there is no reason why an intent-based interface could not "under the covers" utilize RBAC functionality. For example, if you view RBAC as creating a "sandbox" for a given user's session, then you can make informed decisions about the user's activity without having to burden the system with low-level details.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 12:41 AM
To: [email-masked]
Cc: Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; [email-masked]; John Strassner
Subject: Re: [I2nsf] How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi,

Be goode,

Hi Linda,

--tony

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 27 Jan 2015 16:31:14 +0000

Hi John,

We are in full agreement here. RBAC could become a tool for implementing the intent and verifying declarations, or even a model for reasoning about it and assessing on the feasibility of a intent combination, such as end user-enterprise-network provider in a corporate network environment, or parent-child in a home environment, to give a couple of examples.

Be goode,

On 26 Jan 2015, at 23:02 , John Strassner <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Thanks for your comments. As you point out, RBAC itself is about access control. It is not itself declarative/intent-based/goal-driven. That being said, there is no reason why an intent-based interface could not “under the covers” utilize RBAC functionality. For example, if you view RBAC as creating a “sandbox” for a given user’s session, then you can make informed decisions about the user’s activity without having to burden the system with low-level details.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

Hi,

Be goode,

Hi Linda,

--tony

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Tue, 27 Jan 2015 18:49:53 +0000

Great! I look forward to working with you and your team Diego!

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Tuesday, January 27, 2015 8:31 AM
To: John Strassner
Cc: [email-masked]; Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; [email-masked]
Subject: Re: [I2nsf] How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi John,

Be goode,

Hi Diego,

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Hi,

Be goode,

Hi Linda,

--tony

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Thu, 29 Jan 2015 21:49:24 +0000

Before I dive into writing a draft or two, I’d like to clarify something.

This wg (and indeed, many other wgs in many other fora) are all talking about “intent-driven” policy. To me, this is a declarative approach that specifies the goals of the policy, as opposed to the specific steps taken by the policy.

The thing that confuses me is that I don’t really see a true intent-driven interface springing forth. To me, the phrase “intent-driven” should be at a higher level of abstraction that a traditional declarative programming language, such as Prolog. I’m not suggesting that it has to be as free form as a restricted natural language, but how much emphasis, if any, should we place on this? For example, the following contrived statement:
    set permissions(group.users.John.service.facebook, agent1, values=rwxd, time=0900-1800)
is, imho, not even close to what we want. It is basically an imperative statement that tells you to use agent 1 to give John the ability to read, write, execute, and delete Facebook services. On the other hand, something like:
    Session.John.FacebookAdmin = True  (or Session.John.Role.Add(FacebookAdmin) may be even better)
is much closer to we want. I haven’t specified how to give John Facebook permissions, I have indirected that through a Role.

If this is a non-goal, sorry for wasting everyone’s time. I just get confused when the word “intent-driven” or “intent-based” is used.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar
Sent: Tuesday, January 20, 2015 1:50 PM
To: Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]; John Strassner
Subject: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 29 Jan 2015 22:28:46 +0000

John,

Thanks for the questions.
The HP hosted “Intent driven summit” is very broad covering various intents for networks (VPN, QoS, etc).

I2NSF is very narrowly focused, only for the security policies for those security functions:

·       Firewall

·       DDOS/Anti-DOS

·       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

·       Access control/Authorization/Authentication

·       Remote identity management

·       Secure Key management

Here is one example of the security policy intent:

-          Video Conference Controller dynamically informs the network to by-pass FW for traffic with specific identifier (Header, length, metadata value, etc) for a specific time span (during the call).

Then the functional layer interface has to specify the specify matching & actions for the specific FW instances.

Linda

From: John Strassner
Sent: Thursday, January 29, 2015 3:49 PM
To: Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; John Strassner; Natale, Bob
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar
Sent: Tuesday, January 20, 2015 1:50 PM
To: Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>; John Strassner
Subject: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)
Sent: Wednesday, January 07, 2015 7:35 PM
To: Linda Dunbar; Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 30 Jan 2015 03:48:00 +0000

Hi John,
I totally agree with you.
I think you point out the key point and the basic principle that should considered by I2NSF. The intent-driven interface for security function device can be a new work in IETF, and has great value for operators and customers.
I believe we can get a better understanding and good design after we have enough use case and requirement analysis, if we keep on working in the right direction~~

B.R.
Frank

From: John Strassner
Sent: Friday, January 30, 2015 5:49 AM
To: Linda Dunbar; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; John Strassner; Natale, Bob
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 30 Jan 2015 08:10:59 +0000

Hi Linda,

- First, +1 to John’s clarifications about the meaning of intent-driven policy (by whatever label).

- Second, I think you should have used a “for example” qualifier or similar on your list of security functions that I2NSF will be able to address … e.g., I could see intent-driven policies related to logging/notification/auditing being germane as well.

- Third, I think we still have significant terminological problems (centered on “service”, “function”,  and “capability”), but believe they can be resolved relatively easily. My working assumption is that we need (and would want) to align out terminology with the broader set of technologies at play … NFV, VNF, NFVI, SDN, SFC, NSV … which must be considered from both  the provider and consumer perspectives (and possibly others). Unless you and others on the list feel that we’re good as is, I’ll take a stab at documenting recommended usage. I suspect it’s the failure to keep the bigger picture in focus that might be causing us to use terminology in an unduly parochial way.

- Lastly, what is the feeling of the group about trying to integrate the I2NSF, SUPA, and IBNemo efforts … possibly with additional special collaboration with SFC WG … and, once consolidated (whether organizationally or at least programmatically), with outreach to the IRTF NFV and SDN WGs for future support…? I do understand that those first three IETF groups have different goals and perspectives but I can imagine a Venn intersection area that we should collectively harmonize as early in the process as possible (IMHO).

Avanti,
BobN

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, January 29, 2015 5:29 PM
To: John Strassner; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey; Natale, Bob
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

John,

·       Firewall

·       DDOS/Anti-DOS

·       Secure Key management

Linda

From: John Strassner

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: 刘福文 <[email-masked]>
Date: Fri, 30 Jan 2015 16:38:25 +0800 (CST)

Hi all,

It might be an interesting direction to study how to apply the RBAC model to I2NSF. But from the page of NIST, there are a quite number of patents related to this technology. 

http://csrc.nist.gov/groups/SNS/rbac/patents.html

The question is:

Is it possibe to use the RBAC model to I2NSF without royalty fee?

Regards

Fuwen Liu

 

----邮件原文----
发件人：Linda Dunbar  <[email-masked]>
收件人：John Strassner  <[email-masked]>,"Xialiang (Frank)" <[email-masked]>,"Romascanu, Dan (Dan)" <[email-masked]>,Joseph Salowey  <[email-masked]>,"Natale, Bob" <[email-masked]>
抄　送: "[email-masked]" <[email-masked]>
发送时间：2015-01-30 06:28:46
主题：Re: [I2nsf] How about using NIST endorsed Role Based Access Controlas the basis for I2NSF (was RE: I2NSF Planning )

John, 

 

·       Firewall

·       DDOS/Anti-DOS 

·       Secure Key management

 

 

Linda

From: John Strassner 
Sent: Thursday, January 29, 2015 3:49 PM
To: Linda Dunbar Xialiang (Frank) Romascanu, Dan (Dan) Joseph Salowey John Strassner Natale, Bob
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

 

 

 

 

regards,

John

 

Futurewei Technologies

US R&D Center

2330 Central Expressway

  Office:  +1.408.330.4923

 

 

From: Linda Dunbar 
Sent: Tuesday, January 20, 2015 1:50 PM
To: Xialiang (Frank) Romascanu, Dan (Dan) Joseph Salowey
Cc: [email-masked] John Strassner
Subject: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

I2NSF group:

 

 

Cheers, Linda

 

From: Xialiang (Frank) 
Sent: Wednesday, January 07, 2015 7:35 PM
To: Linda Dunbar Romascanu, Dan (Dan) Joseph Salowey
Cc: [email-masked]
Subject: RE: I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

Hi all,

 

 

 

Therein, 

tenant 

user_group 

service-group 

action 

track 

condition 

Definition

condition for action

Parameters

Tenant_name

Tenant_ID

Device(s) 

Place(s) 

User(s) 

Service_object(s)

URL(s)

VPN

permit

deny

reject

protect

scan

…… 

Log

Alert

Show

Rate

Time

timeout

Throughput

State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

< user_group > John

<service-group> facebook 

<action> permit

 

<tenant> Company H 

<service-group> QQ

<action> deny

 

 

B.R.

Frank

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 07, 2015 5:33 AM
To: Romascanu, Dan (Dan) [email-masked]
Cc: Joseph Salowey
Subject: [I2nsf] I2NSF Planning (RE: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling)

 

Just to refresh people's memory on the focused I2NSF use case extracted from use cases presented by Diego Lopez (Telefonica), MinPeng Qi (China Mobile: use case #2 3), and Nic Leymann (Deutsche Telecom))at the Nov BoF:

 

 

 

 

·       Application Controller 

 

Potential Work Items:

 

 

Let’s have a good 2015. 

Linda 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 06, 2015 3:32 AM
To: [email-masked]
Subject: [I2nsf] FW: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling

 

> then please send a message to [email-masked].  If you are unable 

> [email-masked], with a copy to the appropriate Area Director(s).

> Requests to schedule BOF sessions must be sent to [email-masked] with 

> Revised Working Group agendas are due no later than Monday, March 

> 16th,

I2nsf mailing list

[email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 30 Jan 2015 16:26:40 +0000

Bob,

Thank you very much for laying out all those concrete items for I2NSF. Agree that we still have significant terminological problems (centered on “service”, “function”,  and “capability”).

It would be great if you can write a draft to documenting recommended usage, terminology on “Services”, “capability”, etc. Thank you.

I see I2NSF is security function focused (much narrower scoped), whereas SUPA/IBNemo efforts are network wide focused (e.g. Intent for an VPN with specific QoS, Intent for bandwidth of some network, etc).

Linda

From: Natale, Bob [mailto:[email-masked]]
Sent: Friday, January 30, 2015 2:11 AM
To: Linda Dunbar; John Strassner; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi Linda,

Avanti,
BobN

John,

•       Firewall

•       DDOS/Anti-DOS

•       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

•       Access control/Authorization/Authentication

•       Remote identity management

•       Secure Key management

Linda

From: John Strassner

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Here are potential types of I2NSF clients:
•       Enterprise security administrators
•       Application Controller
•       e.g. Video Conference Mgr/Controller sends real time security policies for specific flows
•       Security functions send requests for more sophisticated functions when detect something suspicious

Potential Work Items:

•       Content (Information/Data Model or APIs) traversed through the interface:
•       Information model for security policies
•       Data model (e.g. Yang model) for security policies,
•       Focus on the common policies (among various vendors),
•       Mechanism for carrying vendor specific policies
•       The secure mechanism to carry the content
•       Secure transport, e.g. TLS
•       Authentication and registration mechanism
•       Who is legitimate to issue security policies.

Let’s have a good 2015.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 30 Jan 2015 17:05:26 +0000

Maybe  Tim Polk (CC’ed), who is from NIST and was IETF AD before, can give a more clear answer with regard to the NIST’s patents.

In general, IETF only requires disclosure of patents, and only from those who participate in developing the standard.  Those who don't participate don't have to disclose anything, and even when patents are disclosed there's no IETF policy about what license terms, if any, have to be offered.

So if the patent holders don't participate, the best we can do within the IETF process is file a third-party disclosure, which will get the Secretariat to ask the patent holders to make a statement.

Tim may add more.

Linda Dunbar

From: 刘福文 [mailto:[email-masked]]
Sent: Friday, January 30, 2015 2:38 AM
To: Linda Dunbar; John Strassner; Xialiang (Frank); Romascanu. Dan (Dan); Joseph Salowey; Natale. Bob
Cc: [email-masked]
Subject: Patents related to RBAC

Hi all,

The question is:

Regards
Fuwen Liu

----邮件原文----
发件人：Linda Dunbar  <[email-masked]<mailto:[email-masked]>>
收件人：John Strassner  <[email-masked]<mailto:[email-masked]>>,"Xialiang (Frank)" <[email-masked]<mailto:[email-masked]>>,"Romascanu, Dan (Dan)" <[email-masked]<mailto:[email-masked]>>,Joseph Salowey  <[email-masked]<mailto:[email-masked]>>,"Natale, Bob" <[email-masked]<mailto:[email-masked]>>
抄　送: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
发送时间：2015-01-30 06:28:46
主题：Re: [I2nsf] How about using NIST endorsed Role Based Access Controlas the basis for I2NSF (was RE: I2NSF Planning )
John,

•       Firewall

•       DDOS/Anti-DOS

•       Secure Key management

Linda

From: John Strassner

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda

---

From: John Strassner <[email-masked]>
Date: Sat, 31 Jan 2015 22:27:40 +0000

Thanks Bob for the +1.

I’d also like to echo Bob’s “for example” qualifier qualifier – RBAC is a natural fit for logging, accounting, auditing, and notification.

I think Bob’s proposed efforts on terminology is very important, and am happy to help.

I think that being aware of other efforts (e.g., SUPA) makes a lot of sense. That being said, I would urge us to carve out a distinct space, focused on security (which the other groups are not looking at) where we can make important improvements.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Natale, Bob [mailto:[email-masked]]
Sent: Friday, January 30, 2015 12:11 AM
To: Linda Dunbar; John Strassner; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]
Subject: RE: How about using NIST endorsed Role Based Access Control as the basis for I2NSF (was RE: I2NSF Planning )

Hi Linda,

Avanti,
BobN

John,

•       Firewall

•       DDOS/Anti-DOS

•       Secure Key management

Linda

From: John Strassner

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

I2NSF group:

Cheers, Linda

From: Xialiang (Frank)

Hi all,

Therein,

tenant

user_group

service-group

action

track

condition

Definition

condition for action

Parameters

Tenant_name
Tenant_ID

Device(s)
Place(s)
User(s)

Service_object(s)
URL(s)
VPN

permit
deny
reject
protect
scan
……

Log
Alert
Show

Rate
Time
timeout
Throughput
State

Note

Default: *

Default: *

Must be present

Default: Null

Default: Null

B.R.
Frank

Potential Work Items:

Let’s have a good 2015.

Linda