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