* 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: Roman Danyliw, Benjamin Kaduk | 2015-Sep-18 —  
Chairs
 
 


IETF-104 i2nsf minutes

Session 2019-03-26 1350-1550: Athens/Barcelona - Audio stream - i2nsf chatroom

Minutes

minutes-104-i2nsf-00 minutes



          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
          
          



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