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 ---------------------------------------------------------------------------------------------------------------------------------- Dan Romascanu - how many people have read the charter? 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.