Interface to Network Service Functions (I2NSF) Working Group IETF-99, Prague Tuesday July 18, 2017 13:30 - 15:30 (two hours) Room: Athens/Barcelona Chairs: Linda Dunbar linda.dunbar@huawei.com Adrian Farrel adrian@olddog.co.uk AD: Kathleen Moriarty kathleen.moriarty.ietf@gmail.com Scribes: Susan Hares, Frank Xia.   --- Administrivia - Chairs             - Working Group status and progress on milestones Adrian:  Thank you for coming to the I2NSF.  If I am replaced, this will be my last IETF.                  Congratulations to the 1st RFC being published: RFC8192 -- problem statement and use cases. One finished WGLG, others are in the process of WGLG We are asking if client facing requirement draft is ready for WG LC [draft-ietf-i2nsf-client facing-interface-req.]  A design meeting was held this morning to discuss how to align the information model and data model drafts, it has been very helpful! Diego Lopez: We have a place holder in the capability model.  You will need to add the Support for these other models.  All of the models should be based on the capabilities model.  Sue Hares: You are correct!            --- IETF 99 I2NSF Hackathon Report             - Presenter: Jaehoon Paul Jeong Discussion:  Linda: The I2NSF Hackathon team won an award for their work.   Frank: Paul will you do additional hackathons?   Paul: Yes. We have implemented the monitoring data model.  We hope to demo this model and to have additional features at the IETF 100 hackathon.   Linda: We found that the Linux foundation recently launched a Security Controller Project. The goal is to enable user manage end to end security policies for traffic among their workloads hosted in various Data Center. We reached out to them last week, they agreed to align the North Bound Interface and South Bound Interface to data models specified by I2NSF. As of now, they don’t yet have much to present other than the general objective of controlling bunch of security functions to have consistent E2E policies. So removed from the agenda.   Kathleen: Linda are you the liaison for this work?   Linda: Yes.   Kathleen: It is never too early to be in touch with this group.         Diego: We tried to have encourage the Linux team to come and see the running code. They can start with this running code.   (scribe may have missed more).   Linda: We can discuss it offline. Perhaps you can provide some ideas for this team.              --- I2NSF Capability Informational Model [10 mins: 20/120]             - draft-xibassnez-i2nsf-capability               - Presenter: Frank Xia  [see the slides. ]   Discussion: none    Adrian: We are running significantly behind time. If everyone would save 20% of their time, we will not have to cut some one off the end of the agenda.              --- I2NSF Applicability (to fulfill the milestone) [10 mins: 30/120]             - draft-jeong-i2nsf-applicability-00               - Presenter: Jaehoon Paul Jeong Paul: We wish to have this as a WG draft. Discussion: Any questions?  [silence]?            --- NSF Facing Interface Information/Data Model [40 mins: 70/120]                        - draft-zhang-i2nsf-info-model-monitoring-04 [5 mins]               - Presenter: Henk Birkholz Discussion:  Sue: In routing area, it's a challenge to category event, it's happy to see it happens in security area.             - draft-hares-i2nsf-capability-data-model-03 [5 mins]               - Presenter: Sue Hares  Adrian: SFC work should have discussion with SFC WG  Sue: already talked with Joel, will proceed    Kathleen: 2 suggestions:  Need to solve the overlapping problems among some of the drafts. Terminology is very important, however, the current IESG might make it difficult to have an RFC on Terminologies. Maybe merge some mature terminologies with Framework draft to move forward. How to make it move forward more quickly, please figure it out;     Happy to see the testbed network, suggest to have an easy way to visit the code                          - draft-kim-i2nsf-nsf-facing-interface-data-model-02 [10 mins]               - Presenter: Jaehoon Paul Jeong                        - draft-hyun-i2nsf-registration-interface-im-02               draft-hyun-i2nsf-registration-interface-dm-01 [10 mins]               - Presenter: Sangwon Hyun  Diego: it's more about protocol process, not so much about information model and data model.      Second: I see the elements on the screen. You are talking about memory, load, and telemetry.               It would be good to converge the telemetry data information.               It would be good to experiment with the telemetry data.                          - draft-abad-i2nsf-sdn-ipsec-flow-protection-03 [10 min]               - Presenter:  Gabriel Lopez     Bob: This good work.  Inside the corporate it does not always work.           We should have some caveat on the discussion in this work.      Gabriel: We have followed the RFC.  We want to try for the      Yoav: The problem I see with this model. The NSF can be located in a kiosk in some shopping mall with IP addresses assigned by an ISP.     If you have the information only going from the controller to the NSF, it doesn't work.      This is not what you want. There should be a flow of topology from the      NSF to the controller so the controller can build the big picture.           Gabriel: Yes, this is true.  We are trying to provide end-to-end pictures to the code.      It needs this other information.  We are at this point testing the high level controller.      We have to assume that the NSF controller is aware of IP addresses of NSFs, maybe via some kind of registration process. (scribed missed something).      We will try to improve the securing of the topology update (??).            Yoav: The controller need the information.  The question is from the NB interface or the SB interface.  Gabriel: We appreciate the discussion. We should continue this online.      Valery: I am very much concerned how you provide the topology information (?) to the controller.  [missed].  You need to have security to secure the topology.      I do not think it is a good solution to secure IKE.          Gabriel: Security controller made use of netconf in order to secure a challenge to  download a channel.           Adrian: You've made a really good point.  Could you repeat that point.                   --- Client Facing Interface information/data [30 mins: 100/120]                        - draft-ietf-i2nsf-client-facing-interface-req-02 [5 mins]               - Presenter: Nabil Bitar.                [see slides] Sue: group and identity is useful, could you clarify more details? Nabil: decouple from the network layer information, only concerns service layer identity.   Defined the policy based on contacts.   Sue: Thank your the explanation. We will take further clarification to the list.                                            - draft-kumar-i2nsf-client-facing-interface-im-03 [10 mins]               - Presenter: Nabil Bitar                  Nabil Bitar: This is an blueprint for the client-facing interface information model.         There are multi-tenancy, endpoint, threat prevention, telemetry, and security policy objects.          The way to define the policy instance is to create policy blocks.          Diego: There is overlap between drafts on the telemetry.          I was wondering whether it makes sense to the 100 requirements, and          a focus on meta-data.  It looks more like an envelope to a general statement.          My recommendation is that split what you have there and put it in requirements.          Other parts needs to go data model.                    Part 2 - Your document on the capability model is complicated. There are data models         should provide some of this depth.                   Nabil Bitar: I think it is a generic model to working group.  In some requirements,          WGs have only data models.  In other WGs, the informational model and data models exist.          We see the requirements.                   Diego: I will have requirements, information model, and data model.          Adrian: You are agreeing with one another.          Hank: Due to my discussion on my hackathon telemetry, perhaps we could         converge to the data model.          Nabil: converging drafts on telemetry to one data model makes sense.          The pub/sub makes sense.                            - draft-xia-i2nsf-security-policy-object-0 [5 mins]               - Presenter: Qiushi Lin                      [slide content]: Summary of changes: provide a minimal set of objects and attribute.            Discussion of additional policy objects. Draft provide an example.           Questions:  * For ECA model, do event and actions need?         (see Slide                          - draft-jeong-i2nsf-consumer-facing-interface-dm-02 [10 mins]               - Presenter: Jaehoon Paul           --- Other Work : [20 min: 120/120]                 Next steps with SUPA Information model, and work through model for next hackathon     -- Henk Birkhold - Remote attestation      Discussion: 3 types of function.  The implementation had the TUDA Sync-protocol.  TUDA is based on hardware RoT.      questions:  * Why tUDA? is it not more cmoplex - remote attestation may be the simpliest approach. *  Environments that might benefits? IoT has no state, and needs state. Aggregation of state for ioT is key as well.  * Broadcast can be done via encrypted becon.  * Allows for incremental attestation?  * Without hardware, how will it work.  Virtual harwdware without trust.                                - draft-hyun-i2nsf-nsf-triggered-steering-03 [10 mins]               - Presenter: Sangwon Hyun                        - I2NSF document relationship - Chairs [10 mins]