IETF95 Buenos Aires SFC Agenda Total time: 2.0 hours Chaired by Martin Stiemerling (mls.ietf@gmail.com) Minutes by Dhruv Dhody (dhruv.ietf@gmail.com) Jabber by DIEGO LOPEZ GARCIA Meetecho Recording: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SFC&chapter=chapter_1 00:00 Introduction (WG-chairs) - [5 minutes] Agenda bashing, note-well, (WG-chairs) - [5 minutes] 00:05 Update on draft-ietf-sfc-nsh (Presenter + open-mic) - [25 minutes] - draft-ietf-sfc-nsh update/progression (Uri Elzur) - [15 minutes] - https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ - draft-ietf-sfc-nsh Q&A (open-mic) - [10 minutes] --- Mohamed Boucadair: Issues raised by various members the mailing list for mandatory and optional MD type, which were ignored. What is the rationale for fixed metadata? Uri: All tickets are adressed, maybe you disagree with the resolution. Mohamed Boucadair: Who decide the fix of the issue? Uri: Prerogative of the WG. If you are looking for optimal flexibility you have MD-Type=2, but optimal performance should be served too. Intention is to serve both camps. Martin: Can you send the pointer of the issue which you feel are ignored. WG decides and chair would help. --- 00:30 SFC Implementation (Presenter + open-mic) - [25 minutes] - Implementation status of draft-ietf-sfc-nsh (Uri Elzur) - [15 minutes] --- Martin: Who in the room is working on implementation? Martin: Is there any other OS apart from Linux like BSD? Uri: Not aware. Could be. --- Kent Leung: How does it map to control plane interface C1-C4? For ex. LB for user traffic v/s LB for SFC itself. Uri: It is not necessary to map in the draft because these open source implementation are independent. Also there was feedback to the WG in the list about such mapping. Kent Leung: I am not the author, but just want it to make sense all together and in sync. Uri: That could be a work item for someone to take up. --- - SFC Implementation Q&A (open-mic) - [10 minutes] David Mozes: Data type match to the data path or only control plane? Uri: Dependent on who user is and how hight to build stack, OPNFV is integrating cloud management (Openstack) and use SDN controller (ODL). In such system it does make sense to have data type. In some other scope, MANO that it is fully sufficient, it doesn't make sense. Its outside of IETF. ---- Georgios Karagiannis: Does the Control Plane in ODL uses ietf draft and in what extend? Uri: Dont have a positive confirmation, implementation started before control plane is in WG, Open source community based on contribution and doesn't always consider it a prerequisite. Also it should not be strikingly different, perhaps present in the next IETF. Implementation can also give some guidance to WG draft. Kent Leung: Want to make sure we are not diverging, implementation started with some basic function, but as we move to advance stuff like loadbalancer, we should take care. Uri: No objection if you would like to work on it, we would cooperate. Lee: Does the Firewall in Cluster have the same identification? Uri: There is no notion of SF chaining in current implementation in openstack, there is no SF identification in VM hosting it. Your orchestration is "manual" (described in detail, listen to audio) Lee: Orchestrator needs to make those decisions. --- Martin: WG LC just started. Give comments on the list! Implementers Feedback! 00:55 SFC Security Discussion (Presenter + open-mic) - [25 Minutes] - draft-mglt-sfc-security-environment-req update/progression (Daniel Migault) - [15 minutes] - https://datatracker.ietf.org/doc/draft-mglt-sfc-security-environment-req/ ----- Daniel Migault: (Question to WF) What does WG feel about the document? Is "requirement" too strong? Should we have it as "guidance"?Also, What is MUST and SHOULD in term of guidance? ---- Sunil: Question on authentication, Is it authenticating user (which is okay)! For authenticating Service is not clear? Daniel Migault: For us Authentication, is for NSH traffic Sunil: Is it same as MAC digest? Daniel Migault: Or signature, Depends on which layer? what is important is why authenticate, like encrypting, the problem is actually in managing keys. and figure out if its needed or not. --- - SFC Security Q&A (open-mic) - [10 minutes] Martin (no-hat): Things are fluffy. Draft needs more information on what is the risk if metadata is exposed? Information like encryption should be done in which layer (NSH?) and pros and cons should be added before we take to IESG. Daniel Migault: I understand and we removed text which was solution related, perhaps that was incorrect. Martin: Could be, threats needs to come at some point before solutions. --- Georgios Karagiannis: Is this draft limited to one domain? what about Hierarchical SFC? Daniel Migault: Limited to single administrative domain. ---- Diego (Nokia): This looks like gap analysis. You should focus on performance, control plane aspects. What is the implication if we do encryption all the way. Daniel Migault: In that case, consensus wont be possible, as things would be depends on HW/SW. Some performance aspects are in draft (may be add clarity). Martin: It is difficult to discuss implementation detail for a draft aiming to be RFC. Draft should focus on penalty of encrypt and decrypt at every hop, there is performance impact irrespective of HW or SW. Encryption 10 million or 10 sessions. Those considerations are valuable. Discuss penalty and benefit of such approach. Diego: We can focus on comparing impact if security was done via a shared secret to find if the packet was manipulated or not without worry about the content. Daniel Migault: Cost on encapsulation v/s cost of encryption can vary and that is why i am reluctant to add because it depends on the encryption algorithm. Diego: If the aim of the draft is to say there should be protection? But not say what that protection is, will lead to many non-interoperable solutions. Daniel Migault: First we can have decision on protocol (say IPSEC) that we use for the authentication and encryption function that do that action. Then, encryption/authentication algorithm in use is another discussion. Maybe that is why document looks fluffy. Diego: Will this document specify gap only or will it also eventually recommend use of a particular algorithm. Daniel Migault: this I-D doesn't even provide requirements to NSH protocol, it provide guidance to the SFC deployment, to make sure your initial hypothesis is correct and you need to take care of which aspects. ---- Philip Eardley: The scope of the I-D is not clear? I am not sure what subset of security problems are you talking about? What is dividing line between what is include in the document? Daniel Migault: Scope is really the deployment of a SFC. Martin: Its not only about deployment. Philip Eardley: In that case it includes the security of the protocol, security of the SF... Not clear. Martin: Chairs and DT should discuss and fix the scope clearly. ---- Rajiv Asati: Doc is good, it has requirement, recommendation, and lot of text to support. Might be useful to focus only on requirements to fine tune the scope. Daniel Migault: Requirements are quite dependent on the environment of the SFC deployment, you end up with so many subcases. The good question would be what is requirement, and what is recommendation? Rajiv: Requirements can be deployment independent, another document that focus on a particular deployment scenario and add recommendations pertaining to that. Daniel Migault: Perhaps we can take trusted environment, and say what are the requirements 1,2,3. ---- Joe Clarke(Jabber): The draft says it's not trying to define protocol requirements, but in terms of cross-vendor compatibility would the requirements not lead to a need to create some protocol requirements? For example, if you encrypt NSH, wouldn't you need multiple implementations to support common encryption? Joe Clarke (Telefonica): How can we make sure multiple components implemented by multiple vendors support common security scheme? Daniel Migault: It got to be NSH encryption. But it you choose lower layer say IPSEC, then both end support IPSEC but thats different layer. ---- Surendra Kumar :Security is an odd ball for operator, good security should not be in the way and draft doesn't mention what disruption it would cause. In the draft do you rule out a new security protocol? Daniel Migault: Draft defines requirement and protocol is out of scope. Surendra Kumar: For operational ease, would not like to see another protocol added for encryption and authentication, the bit cost is justifiable because operator doesn't have to deploy something new. ----- Martin: More attention is needed from community, and more discussion on the list 01:20 SFC Miscellaneous (Presenter + open-mic) - [25 minutes] - Hierarchical Service Function Chaining (Dave Dolson) - [15 minutes] - https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchical/ Rajiv: Hiding is a reasonable thing to do in a large scale environment, but how would you do sfc traceroute? (1) If a packet is dropped/expired at sub level is handled (2) Processing of metadata i.e. change at sub level would be propagate to parent level? Are the rules defined? Dave Dolson: One approach is shared schema, where change in metadata in one domain is also changed in another, so it is same as SF changing metadata. Or you dont want to change the metadata in the higher domain. Most common case would be most metadata would be added in lower domain with no metadata in higher. For SFC trace route, more thinking is needed, it should be like high level SF dropped the packet. Rajiv: Topology in slide 7, Is SF also SFF in sub-domain? Dave Dolson: IBN has SFF feature in it with special termination. - SFC Miscellaneous Q&A (open-mic) - [10 minutes] Rajiv: Looking at the sub-domain classifier, decapsulate the frame first and then classify in the sub-domain? or take full packet and then classification on overlay header. Dave Dolson: Inner Packet, it can use some properties of the path it is on. Reasonable to pop the packet out of NSH and consider the metadata with it. Rajiv: Packet enters sub-domain, it just impose another NSH header Dave: Thats one of the solution with benefit of less state in the IBN but burden on SF. --- Robert: (slide 3), In sub domain 1 there are SF, but in global picture there are no SF abstraction, so why does packet go to sub domain 1 in the first place. Dave Dolson: sub-domain 1 itself is the SF in the higher level SFC Robert: not sure why hierarchy is needed. This is a control plane issue Dave Dolson: It control plane issue, but we want to have different controller in each plane and not have a god controller ---- Kent Leung: we should prescribe that we should not look at outer NSH header and metadata. is there a reason you want to strip it out and look only at the user traffic? Dave Dolson: Dont need to prescribe that. ---- Martin: Should this be WG item? Give feedback on the list. 01:40 SFC Metadata Model (Sunil Vallamkonda) Joel Halpern: We can maintain a public registry, where vendors can put details when they wish to make public. We dont need this model. Not sure how your fwk solve interoperability problem that might occur between vendors. There are some under specified issues when it comes to metadata but framework to describe the metadata doesnt seem to address anything. Kent Leung: Not sure interoperability is solved by this draft, different vendors do different SF but if SF1 of vendor1 sets the "critical bit" in the metadata which is not understodd by Sf2 of vendor2. Thats creates interoperability and this is underspecified. Sunil Vallamkonda: I will try to address as we progress the draft. ---- Rajiv Asati: How does a SF decide what it needs to include in the metadata based on the vendor of the next SF/SFF? There could be many vendors and how to accomodate this variability? Sunil Vallamkonda: Controller provision the abstract chain, and from that we get RSP and can pass vendor specific information and metadata. Dave Dolson: For Joel, maybe we have not framed it correctly, but we need a model to talk to different vendor and classify metadata and make it interoperable. 01:45 Closing (WG-chairs) - [5 minutes] Martin: Out of time. Meeting adjourned. ---