* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

I2nsf Status Pages

Interface to Network Security Functions (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2015-Sep-18 —  

IETF-103 i2nsf minutes

Session 2018-11-07 1540-1710: Boromphimarn 4 - Audio stream - i2nsf chatroom


minutes-103-i2nsf-00 minutes

          Interface to Network Service Functions (I2NSF) Working Group
          IETF-103, Bangkok
          Wed Nov 7, 2018
          15:40 - 17:10 (1.5 hours)
          Room: Boromphimarn 4
            Linda Dunbar      linda.dunbar@huawei.com
            Yoav Nir          ynir.ietf@gmail.com
            Eric Rescorla ekr@rtfm.com
          15:40-15:50 - Agenda bashing, blue sheets, and Note Well
          Document status
          15:50-15:55 I2NSF Hackathon Project - : Jaehoon Paul Jeong 
          15:55-16:05 IPsec Flow Protection (20 min): Gabriel López
           [Yoav] 1st, some crypto algorithm attributes (e.g., des, md5) in yang
          model of Appendix are obsolete and should be pruned. 2nd, there is no
          way for security controller to retrieve the list of supported crypto
          algorithms by a particular NSF, since an individual NSF usually will
          not support the full set of crypto algo, but subset of it.
           [Gabriel] Agree, we need more reviews and improvements from IPSec experts
          for the yang model. For point 2, We have tried to list all elements for
          both case 1 and case 2 in the model. Some options could be supported or
          not in the NSF depends on the operating system or specific application.
           [Frank] There is possibly a third case, the DH key negotiation among
          the peers through the controller, would you consider to describe this
          way in your draft?
           [Gabriel] The draft is more closer proposal to the standard. We think
          this DH way can be integrated into our case 2 with some efforts, and
          propose our idea to Cisco guys one month ago, but not get response. So
          in personal opinion, this proposal will make more sense in a separate
          document or try to integrate with our draft.
           [David] One issue is about scalability. I think the centralized
          controlled DH calculation and state machine execution by controller has
          the scalibility problems, especially when you have a large number of
          nodes.We can discuss on it more.
          16:05- 16:15: Security Risks of sharing IPsec key: Yoav Nir
          Discussion on IPsec optimization in SDWAN environment, especially the 
          security risks, which are to be included in the document
           [Rafa] We are assuming the SDN controller is a trusted entity. If the
          controller is under the control of attacker, not only the problem in
          case 2 will happen, other attacks could happen. Case 1 is definitely
          aclear case. The DH way complicates the design, but case 2 has a very neat
          and clear design, and is easy to implement. I am not aware of the random
          source argument. The TLS connection between controller and NSFs are not
          only for IPSec configurations, but also for a lot of other management
          and routing configurations. So, it is not a specific problem for IPSec
          configuration, is a general problem.
           [Yoav] Trust is contextual. I trust the SDN controller and the TLS
          connection to transport various kinds of configurations, but don't trust
          the SDN controller to store and delete traffic keys on time.
           [Hu] I don't like case 2 or case 3. We already have case 1 (ikev2),
          and which is the most secure way. There is no value or advantage of case
          2 and case 3 compared to case 1.
           [Valery] I don't like case 2. Considering the delay, failure issues of
          rekey process, case 2 is more complicated and less reliable than case 1.
           [David] Respond to the comments why we don't just do in case 1. For
          building and deploying really large SDN networks, we found IKEv2
          way didn't scale the way we need. We use a central controller to
          distribute keying material and we've come up with a DH-based approach
          that scales to the way we need.
           [Yoav] As an individual, I want to mention that there are already SDN
          products on the market and they are much closer to case 2 than case 1.
           [Gabriel] 1st, I agreed with Yoav comment about the motivation of case
          2, which is from the market. 2nd, we have to clarify that the security
          controller has to be a trusted entity, that's an essential premise for
          everything. 3rd, security controller has to have the world view of the
          newwork, so that it can work. Which means the security of controller
          is not a specific problem for IPSec, but a general problem for the SDN
           [Rafa] I have similar comments with Gabi's. one Additional comment,
          regarding to transporting keys from the controller to the NSF, there are a
          lot of secure key transport protocols existing and you can implement that
          actually when you send a key. Of course we are saying we are distributing
          keys through a secure channel. Yoav mentioned in his slides 4 that the
          traffic key should be stored in the cryptographic boundary but in the
          case 2 especially, the cryptography boundary is everywhere, such as
          controller and NSFs. And we assume that NSFs in case 2 are very limited
           [Tero] Case 1 will not leak out the traffic keys between the two
          nodes. If we have traffic keys stored as in case 2, the keys leak will
          result in the protection failure of early traffic. This is a worse case.
           [Hu] If the controller is compromised, we should minimize the impact to
          our traffic. That's an important difference we need to consider between
          case 1 and case 2. 
          David's presentation about I2NSF Flow protection.
           [Rafa] For case 2, we should follow the right procedure according to
          the real work of the kernels we have seen. It can have more optimization,
          but we don't see the scalability issue for our new case 2 solution with
          the DH way integrated. Of course, case 1 is the right one, you don't
          need to change it to other thing.
           [Linda] Therefore, it is better to document all the issues associated
          with Case 2. 
           [David] I would like to add Case 3 for IKA exchange via Controller. I
          will write some text out in the mailing list. 
           [Yoav] IPsecme group: please review the Appendix A to see any attributes
          can be removed. 
          16:15-16:45 – WG adopted Data Model & Information Models  discussion
            I2NSF Capability information model draft – Frank Xia
            I2NSF Data Models (15 min) - Presenter: Jaehoon Paul Jeong
           . I2NSF Consumer-Facing Interface YANG Data Model
           . I2NSF Capability YANG Data Model
           . I2NSF Network Security Function-Facing Interface YANG Data Model 
           . I2NSF Registration Interface Data Model
          16:45-17:00 :45Individual draft Data Model discussion
          draft-hong-i2nsf-nsf-monitoring-data-model-05: Jaehoon Paul Jeong
          draft-xia-i2nsf-sec-object-dm-01: Qiushi Lin                    
          draft-dong-i2nsf-asf-config-01: Wei Pan 
           [Yoav]: encourge more people to read this drafts and comment on
           [Brain] No standards to vote for the advanced policy. It's important
          to be able to reference the type of data, like antivirus signatures,
          so different vendors all could use it.
          17:00-17:10 - Update on Security Policy Translation Draft 
            [Presenter: Jinyong Tim Kim (10 min)]
           [Paul] This is good for our industry, please give comments.
          Open Mic

Generated from PyHt script /wg/i2nsf/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -