Skip to main content

Minutes IETF104: i2nsf
minutes-104-i2nsf-00

Meeting Minutes Interface to Network Security Functions (i2nsf) WG
Title Minutes IETF104: i2nsf
State Active
Other versions plain text
Last updated 2019-04-05

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