Minutes for I2NSF at IETF-93
minutes-93-i2nsf-2

I2NSF BOF @ IETF 93

Date: Tuesday 21 July 2015
Time: 1300-1500  Afternoon Session I
Room: Berlin/Brussels
Chairs: Dan Romascanu, Joseph Salowey
Revision 0.1
============================================

Admin - Note Well, Blue Sheets, Notes takers
--------------------------------------------

Note Takers - Susan Hares, Joe Parrott
Jabber scribe - Yoav Nir

No agenda bashing

Introduction of I2NSF BOF (Chairs, 10 min)
------------------------------------------

Joe S introduced i2nsf - industry is moving more toward virtualisation of nsfs
and automated configuration of these. Charter has been more focussed since last
BoF (IETF#91) This is the 2nd BoF and a wg forming BoF.

Merged Use cases (10 min)
-------------------------

Diego Lopez presented the use cases
The proposed charter addresses any kind of security function (both virtual and
physical) Instantiation, configuration, updating, collecting status and
validation are the main scenarios to be considered Two scenarios:
        a) cloud datacentre -
        b) access network - additional problems of how to identify users and
        identify what functions are associated with them (i.e. services and
        functions have to follow the user)

Stefan Santesson - how are you planning to get crypto proof that the message
has not been tampered with? DL - we are looking at a model from the TCG SS -
would that mean talking to something outside of the software? DL - not
necessarily

Kevin (Kenny?) Smith - seem like a sensible set of reqs for any nvf node - are
we planning to take this to nfv in general? DL - we want to focus on security
function, but no reason not to extend

Dean Bogdanovic - the client is the administrator?
DL - the client is the user

Yoav Nir (question from jabber) - does the sec controller take part in setting
up the path between the client and nsf DL - sometimes but the sec controller is
not intended to be the sfc controller

problem space (10 min)
----------------------

Lindar Dunbar presented problem statement
Different vendors speak different languages but want common expression.  A
first step could be to develop common syntax. Next step would be to establish
how to express commonly used rules for virtual networks. Scope has been
focussed on the problems facing providers - now much smaller scope

no clarification questions

Gap analysis
https://datatracker.ietf.org/doc/draft-hares-i2nsf-gap-analysis/
----------------------------------------------------------------

Sue Hares presented Gap analysis
Network management system may be running other protocols - e.g. SACM, DOTS +
I2NSF Other groups (ETSI NFV, OPNFV Moon project & CSA) are concerned with EMS
to VNF interfaces

Jamal Salim - are you proposing to use netconf or yang?  OPNFV etc. already
have a model Dan R: This goes beyond clarification questions. SH - aware of
some work but this need to be decided Dean Bogdanovic - the point of acl model
is to describe what you can do.

Potential solutions
-------------------

Framework For Interfaces To NSFs
https://datatracker.ietf.org/doc/draft-merged-i2nsf-framework/
--------------------------------------------------------------

Ed Lopez presented the framework
NSFs do not operate relative to standards unlike other network elements.  So
how do we define interfaces to devices which have no standardised interfaces?
We know nsfs are going to process packets - hence 'packet-based paradigm'

Linda Dunbar presented the capability index

Sam Hartman - draft is too abstract.  can you give me a concrete example of
subject, object... EL - customer has children and wants to provide web blocking
- subject would be the raw packets, the object indicates the service requested
by the customer, the function is web blocking and the action is to forward
packets if accepted. Sam: Was it the destination addresses? Edward:  The
destination address [web-stie], the key is the Sam: What is the function?
Edward: the web-site filter. Sam: The function is web-filter, subject: they
have kids, the Edward: The action is packet filtering. Kathleen Moriarty -
please could you provide more examples on the list?

Sumandra Majee - are we looking at streams or packets?
EL - the network provides streams, we're only looking at the packets in that
stream SM - are you suggesting that vendors need to change their data-plane? EL
- as part of the capability exchange, the network would know there is a
security function available (no name) - question around files and e-mails EL -
many systems deal with files and e-mail differently but they are elements of
the nsfs Dean Bogdanovic - where do you do the translation from policies to
device configs? EL - this would be in the security controller

Capability interface Information model
https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/
-------------------------------------------------------------------------

DaCheng Zhang and Liang Xia presented the information model.

Jamal Salim - why are you talking about yang here?
Dan Romascanu - this isn't a clarification question, please ask at the end.

SDN-based Security Services Using I2NSF
http://datatracker.ietf.org/doc/draft-jeong-i2nsf-sdn-security-services/
------------------------------------------------------------------------

Jaehoon Jeong presented SDN-based security services using I2NSF

Dan Romascanu - what parts of this would be within the proposed scope
JJ - everything between the security controller and the switches

Charter Bashing:
http://www.ietf.org/mail-archive/web/i2nsf/current/msg00458.html<http://www.ietf.org/mail-archive/web/i2nsf/current/msg00458.html>
----------------------------------------------------------------------------------------------------------------------------------

Dan Romascanu - how many people have read the charter?
<show of hands>

Sam Hartman - two things: there was a comment that openstack is application
centric so won't meet out needs, that's not a good enough justification for me
and I need to understand why that's not good enough.  I'm very concerned about
a packet-based framework - the information model reminds me of a least common
denominator firewall language.  Concerned that a packet-based focus is causing
us to encounter the problems we're trying to avoid. DR - aim is to try to get
an information model that is both application and network application. SH - I
like the problem statement DB - I also did not want packet based filter, would
prefer something on flow-base.  What is the difference between i2rs and this?
DR - the definition of flow allows for flexible filtering DB - I want to be
able to have filters to distinguish between types of packets

DR - explained the scope of the proposed charter

Bob Moscovic - I think we need to move up the model from packet.  Packet ends
up limiting us - should be talking about communication flow-based policy. DR -
sounds fine to me BM - should be included in the charter discussion

Linda Dunbar - addressing sams comment on openstack.  We are contributing to
openstack and trying to make sure it is useful to more vendors Sumandra Majee -
this work has enough difference from openstack.  are we talking about a control
plane or a management plane? complicated to operate on control plane SH - have
you just asked whether security controller is expected to rearrange the
data-plane? SM - Yes SH - ive read the charter and im very confused by the
service/capability interfaces. the capability interface is the part where
customer says 'I want thes rules', is that right? DL - No - that is the service
interface. SH - so cap int is between sec cont and nsf, is that what were
standardising? DL - yes SH - I dont think this is very useful KM - I thought we
were also looking from client into sec controller and sec cont ino nsf. SH - I
am interested in the tennant and sec cont DL - when we focussed the charter, we
focus on network cont and the device.  in openflow language this is NBI Jamal -
are you looking at the common interfaces between Dan R - we shoudl standardise
an information model and a set of data models Joe S - there are many ways to
represent the model. Bob M - discussion on inkoving open-flow and sdn.  we will
be creating something here which we can use for devices which arent openflow or
security devices. EL - first I agree with Sam - talking about capabilities
there is work to be done the reson i used the term packet is because security
events can exist between flowws and session so simply defining a flow or
session is not enough Adrian Farrel - chair said you have not decided on a data
model, but your charter says you have opted for yang, is this an error? DR -
Yes LD - I realise some confusing between layers - there was confusion at the
last bof so we've taken away some of the abstractions. SH - please remove all
text from charter relating services.  Are your endpoints the sec cont and the
fw?  Do you think you'll have interoperability between fws.  I think it would
be much better to look at interface between client and sec controller. KM - I
agree it's going to be easier to standardise application to network controller.
DL - As providers we are happy to work on either interface.

Hard Questions
--------------

Does the community think that the problem statement is clear, well-scoped,
solvable, and useful to solve? Yes, Lots of hums Sam: You seem to be in the
rough

Is there support to form a WG with the charter
presented at the BOF (with edits)?
Rough consensus
Lots of hums for yes
A few hums for no

Who would be willing to serve as an editor for the
documents referred in the draft charter?
approx 15

Can we see a show of hands of folk willing to review
documents (or comment on the mailing list)?
about 26

Who is interested in deploying or implementing i2nsf?

~7 to deploy
~11 to implement

KM - there has been significant progress since lst bof, just some editing on
charter needed. DR - should we look at the interface which was declared out of
scope previously? KM - I think so.