Skip to main content

Minutes IETF103: i2nsf
minutes-103-i2nsf-00

Meeting Minutes Interface to Network Security Functions (i2nsf) WG
Title Minutes IETF103: i2nsf
State Active
Other versions plain text
Last updated 2018-12-04

minutes-103-i2nsf-00
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

Chairs:
  Linda Dunbar      linda.dunbar@huawei.com
  Yoav Nir          ynir.ietf@gmail.com
AD:
  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 network.

 [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 ones.

 [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
   (draft-ietf-i2nsf-consumer-facing-interface-dm-02)
 . I2NSF Capability YANG Data Model
   (draft-ietf-i2nsf-capability-data-model-02)
 . I2NSF Network Security Function-Facing Interface YANG Data Model
   (draft-ietf-i2nsf-nsf-facing-interface-dm-02)
 . I2NSF Registration Interface Data Model
   (draft-ietf-i2nsf-registration-interface-dm-01)


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 them.
 [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)]
   (draft-yang-i2nsf-security-policy-translation-02)
 [Paul] This is good for our industry, please give comments.

Open Mic