Interface to Network Service Functions (I2NSF) Working Group
IETF-104, Prague
Agenda
=======
Tues march 26, 2018
13:50 - 15:50 (2 hours)
Room: Athens/Barcelona
Chairs:
  Linda Dunbar    linda.dunbar@huawei.com
  Yoav Nir      ynir.ietf@gmail.com
AD:
  Roman Danyliw   rdd@cert.org
=======
Agenda bashing, blue sheets, and Note Well, Document status (10 min)
 Chair: The remaining work is to complete data models for NSF facing, Client facing and Registration. 
 Frank Xia: I'm one of the co-authors of the information model and data model drafts. We think the capability information model is mature and stable, and it's the basis for several data model drafts. The data model drafts have been doing interoprate test for several Hachathon. Maybe we can ask for WGLC because there is no new thing for the information model and data model.

I2NSF Hackathon Project (5 minutes)?- : Jaehoon Paul Jeong 
Github Link:  https://github.com/kimjinyong/i2nsf-framework
?Chair: Very good work. For people interested in implementing Workload bound security policy and interested in using Open Source. Please check the code and see if you benefit from them.

IPsec Flow Protection (15 min): Rafael Marín-López
Discussion on major changes of the document. Making it ready for WG adoption.
The draft has defined three parts: ietf-ipsec-common (Appendix A), ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less case). The model ietf-ipsec-common has only typedef and groupings common to the other modules.
 Yoav: You didn't remove the functionality of forwarding IPsec (AKA Back-2-back IPsec), only you need both an inbound and an outbound policy to define it.
 Rafa: Yes. 

 Frank Xia: Need to look at the crypto type YANG data model. It's very big with many combinations, currently including IPSec, TLS and SSH. Maybe you should pick up the ones that are applicable to IPsec.
 Rafa: True.

 Paul Wouters: Recently there's a desire to have more SPD selectors in the future. General concern: This kind of documents basically put a snapshot copy of the IANA registry inside, but IANA keeps changing. Is there any YANG way to reference IANA and changes when IANA changes? Will it be better to just point to IANA registry.
 Rafa: We understand the problem and we take the current solution to refer to another draft. We need to investigate how to refer to the IANA registry to avoid document changing when something new is occured or something old is removed.
 Frank Xia: I think we need to solve this kind of general problem. I think the best way is to solve this problem in the crypto type YANG data model draft.
 Rafa: That's is actually our approach.
 **TODO** Chair: Talk to the YANG doctors and see what is the general approach to a list that gets updated outside our WG.
 Diego: We should ask YANG doctors about the possibility of including references to two values included in IANA registry.
 Chair: It's not a nice way that giving a number in the RFC and asking reader to go to the IANA registry to see what it means.
 Pual Wouters: If the IANA registry updates we have to write a new RFC document with only a few values changed. I would like to avoid needing to do that.
 Chair: I'll talk to the YANG doctor and write on the mailing list on how to archieve that.

 Yoav: Chair hat off. A child SA should have one traffic selector, because when you try to support more, then you get interpoeratibility problems. I'm fine with removing AH support.
 Paul Wouters: That seems all fine to me. We have use cases where we have more than one identical Child SA to one SPD entry. Binding IPsec to multiple CPUs / clusters, needs multiple child SAs with the same Traffic selector. **TODO** For the authors: See if the model accomodates multiple parallel SAs (same policy, same selectors, only different SPI and keys).

 Paul Wouters: Need to add IKE port back into the source and destination, because Kubenete containers have very few UDP ports and they don't get UDP port for IKE. Therefore, it needs to pre-config IKE port on both the source and destination IP address to actually set up a connection.

 Valery Smyslov: If there is no traffic, there is no need to re-key.
 Rafa: It depends of the lifetime you have because we have in terms of time or in terms of bytes pre-set by the IPSec SA.
 Paul Wouters: The hard time is like all your regular processing hasn't happened and this is the emergency that we must not do more encryption with this key. So the only action we had is to kill the SA, and that's why there's no action.

 Rafa: Should we include road-warrior support or generate a new I-D?
 Yoav: I tend to agree that this should be in a separate I-D. We are likely not controlling the road warriors machine with the SDN controller.

 Yoav: With no hats. It would make sense for the IKE-less cause that if we have multiple parallel pairs of SAs and want the pairs to be connected to one another. Even in the IKE-less case it should add to each SA where the paired SPI is. I think the SA should contain the SPI of the other SA that is created at the same time.
 Rafa: This is a different comment. If you have the reqid, you can use that like a pointer between the IPSec SAs, but now we don't have such kind of link. The policy has traffic selector and the IPSec SA also has traffic selector, then the relationship between the IPSec SA and the policy is based on that traffic selector. The other thing you mentioned that one inbound SPI has a related outbound SPI and we should reflect this relationship is correct.
 Yoav: Is this reqid part of the SPD that you send to the Linux kernel?
 Rafa: Yes, it's something that you can include if you want.
 Yoav: I guess it makes sense to link them.

 Chair: The draft is ready for the WGLC. Wait a week after the meeting and start the WGLC.

 Linda: To David, is there any conflict between your rekey mechanism and this mechanism or it's a complementary.
 David: I think it could be complementary. I could bring my mechanism forward at some other point. This point this document is ready.
 Linda: Is your rekey mechanism applicable to both IKE and IKE-less cases?
 David: It's different than both.
 Linda: When you can write something up? It could be an independant document.
 David: I'll writh something up separately before next meeting.
 Linda: How is your mechanism aglined with this one while conflicting with it? Will it be any problems?
 David: I'll think about it.

 Frank Xia: Current document is mainly about the configuration YANG data model for the IKE and IKE-less cases. I think the other solution is about the key distribution mechanism for the SDN controller scenario. Will the current YANG data model in this I-D be directly used for the other options? Is there no conflictions between your draft and the future possible solution?
 Rafa: The solution here is very simple. I don't see any conflict. The YANG data model can be extensible.
 Frank Xia: I think you have persuaded me and your proposal is very direct and simple. Right now I also can't see any conflict.

 Paul Wouters: In the distributed IKE case, when doing IKE exchange between two security controllers, but some values are only transported to the nodes that actually use it. In this case only the nodes know the private key but not the controller knows. So there might be some addtional configuration needed. I think these can be done in a separate document.

I2NSF Applicability: Jaehoon Paul Jeong (5 min)
? - Update from AD Eric Rescorla's Comments
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-09
Addressed the comments from previous AD. Hope they are good enough to move into IESG. 

I2NSF YANG Data Models:? Jaehoon Paul Jeong (15 min)
? - NSF Capability
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-03
? - Consumer-Facing Interface
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-03
? - NSF-Facing Interface
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-04
? - Registration Interface
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-02
? - NSF Monitoring Interface
? ? https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-monitoring-data-model-00

A Proposal for Model Convergence: Diego Lopez
 Frank Xia: Good direction. Will this bring big influences or changes to current data model? I think there will only be some minor changes and this work worths being considered more.
 Diego: This doesn't affect the capability model.
 Paul Jeong: Good direction. We discussed how to implement this model. This one will not affect much about the capability model.
 Chair: It seems the proposal will uproot the entire data models we've been done.
 Diego: No. Only the registration interface. When registering a capability, a reference will also be added to point out the related data model. We will find out how this reference can be constructed in the best way.
 Chair: Is it doable?
 Diego: We believe so.
 Paul Jeong: If working group agrees this proposal, my student can revise the draft after this meeting.
 Roman Danyliw: How about the previous drafts that are ready for WGLC. Does it have to change the status?
 Diego: Only impact 2 documents: NSF-facing and Registration interface DM. All the rest are ready to last call.
 Chair: After the meeting if you can update the document, then we can circulate it to a few reviewers, and hopefully we can get it ready for WGLC.
 Diego: It will be done before next meeting.

I2NSF Security Policy Translation: Jinhyuk Yang (5 min)
? - Security Policy Translator as Security Controller's Core Function
? ??https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-03
Mainly posted as guideline for I2NSF , published as best practices, as RFC 8075 (implementation guide)
 Paul Jeong: It is important to have a guideline.
 Frank xia: I believe this document has some value as providing some guidance. But many security devices have already provided a lot of application layer information for direct management. If you can provide highlevel architecture guideline for how to do abstract translation, it would be more useful. 
 Diego: This document makes more sense to me. It is a new functionality that controller should have.

Open Mic