Skip to main content

Minutes IETF99: i2nsf
minutes-99-i2nsf-01

Meeting Minutes Interface to Network Security Functions (i2nsf) WG
Date and time 2017-07-18 11:30
Title Minutes IETF99: i2nsf
State Active
Other versions plain text
Last updated 2017-07-31

minutes-99-i2nsf-01
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]