IETF102 NVO3 WG agenda Network Virtualization Overlays WG Wednesday Afternoon session I - 13:30-15:00 - Viger Chari: Matthew Bocci Secretary and minute taker: Li Yizhou Matthew: Note well applies. 1. WG status update.ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊWG Chairs, 10 min Agenda Bashing. Milestones: dropped control plane requirement and solution milestones due to lack of progress and may move some of them back. Added security requirement and solutions milestones. 6 RFCs including 1 new RFC since from last IETF. Document status: new revision of Geneve. Security discussion today. Hopefully LC after IETF meeting.Ê Security requirement document, a lot of discussions, no sufficient consensus to adopt it yet.Ê Hopefully run another adoption poll with the latest revision Daniel is going to talk about. EVPN applicability draft currently under adoption call. Read draft. vmm draft. Started WG LC, not closed. A particular review from TCPM. Can author come to the mic and let us know their plan? Behcet Sarikaya: can address the comments next week.Ê Matthew Bocci: please read the draft. Will try another WG LC after OPS area review comments has been addressed and probably a review of TCPM. Next IETF and IEEE meetings are back to back. A proposal for a potential joint IETF and IEEE 802 workshop on data center technologies in Bangkok.Ê Paul Congdon: IEEE 802 plenary meeting is immediately following the IETF meeting in Bangkok at the same hotel and so we wanted to try to take advantage of that opportunity to see if we could get together some of the thought leaders around data center technologies. IEEE 802 just recently approved a project around congestion management and it's intended to work with higher layer congestion management in the IETF as well. So we think that there would be some fruitful discussions in that area. There's also some strong interest in the IEEE where of course all the switch vendors are and ASIC vendors around. How we how we interconnect other data center technologies such as the overlay networks as well, so the interplay between layer 2 and layer 3 and would be a great opportunity to have such discussions. Again, congestion being one of the interesting areas, a lot of the new proposals here in the IETF are using option fields in the TCP header which would be inside the encapsulation. So it's not clear how the fabric switches themselves would be able to see or do anything about that so that would be interesting to know how we can communicate indications of congestion and things like this to the edges of the network as well in order to take appropriate action. So the proposal is that this would take place on a Saturday immediately after the IETF, the IEEE has indicated they have room space available so there would be no additional meeting fees or anything like that.ÊBut the agenda is not fully set yet, it would probably be announced to by the IAB or something in the IETF. Any questions about that? Matthew Bocci: ok so I'll also post something to the NVO3 list about this. I guess you're looking for feedback on potential topics that people would be interested in. Paul: Correct we're looking for feedback on topics as I mentioned the kind of current thoughts as it would be around congestion management but we're open to other topics as well. Matthew Bocci: That brings us on to our session presentations. The Geneva security requirements draft. 2.draft-mglt-nvo3-geneve-security-requirements-03ÊÊÊÊÊ Daniel Migault, 10 minÊÊÊÊÊÊÊ Daniel: presenting... Ilango Ganga:ÊWe have had the extensive discussions with the security requirements authors. But I just wanted to point out that the transit nodes was as an important point where the security requirement document made certain assumptions that is not supported by NVE architecture. There are several requirements that are associated with this. We have given detailed feedback to them saying that these are unsupported and we shouldn't have those requirements. That's number one.ÊThe second one is regarding the optimization versus requirement. We discussed that one as well. There are two things. One is multiple flows. We don't believe that multiple flows is more of a nice-to-have and is an optimization and it is not an absolute requirement to secure the communication between the two NVE pairs. That's one point and the second one is on whether the tenant can encrypt the data or whether the tenant encrypts the data or not if an operator deems necessary that the communication between the NVE pairs needs to be encrypted and they will encrypt it that is irrespective of what happens here with the payload. So we believe that's also an optimization and not a requirement. We have submitted detailed comments to the authors of the requirements and that's not been addressed in the current version. So with that my opinion is it is still not ready for adoption. We still need to fix the architectural issues as well as some of these optimization requirements before it's ready for adoption. Matthew Bocci: You're planning on doing a new versionÊof draft right? ÊÊ Daniel: We're working on the new version.ÊÊ The assumption we had before were reallyÊbad. So it's more to see the direction where we have to go. To me,Êoptimization can be discussed. Multiplexing is not a big thing. The transitÊnode issue seems to me more drastic because as Ilango mentioned a lot of theÊrequirements were coming from these. So if there is actually no transit nodesÊas the way we understood, those requirements are going to be completelyÊdifferent. And even the analysis. If we kind of fix on that, it's easier to have a more stable version. ÊÊ Matthew Bocci: Given that this was going throughÊan adoption call, it would be good to have more discussion on the list aboutÊ it rather than in private. Maybe form a formal design team around this. If Geneve could try to have more of the discussions on the list if possible that would be good.Ê 3.draft-ietf-nvo3-geneve-07.txtÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Ilango Ganga (remote), 10 minÊÊ Ilango: presenting remotely... Tal Mizrahi (Marvell): The one before last bullet says options or the ordering must not be changed by transit devices. Actually the sentence says two different things. First of all I would suggest to split it into two sentences. One talks about the ordering and one talks about changing or not changing the option. Regarding changing the option, you mentioned IOM, so maybe I miss what you said, but how does this work with IOM if you can't change the option? What are the transit devices supposed to do in terms of IOM? Ilango: The datagram has the meaning only at the endpoints. If you look at RFC7605, that makes it very clear that the port number association is also established by the endpoints. So even though the transit devices may be able to interpret, that doesn't guarantee any security that the association will always be on this port number. It's the same thing with Geneve. You don't want it to be able to go and change the content of the packet. That would cause security with respect to what the communication that is going on between the endpoints. This is like you are establishing a tunnel between an end point to an end point, and end points are the ones that are establishing the tunnels and maintaining it. You don't want the contents of that tunnel to be modified by the intermediate devices. That was not an intent of Geneve architecture and we just wanted to make it clear. Tal: So just to make sure I understand we're saying that we're not going to support IOM and transit devices? Ilango: If you're going to modify the packet, then what it means is that's an endpoints responsibility. Then you need to be implementing an endpoint in order to make changes to the packet. Daniel: Transit nodes cannot insert, delete. Only thing can do is read an option? Ilango: That's correct. Ilango: continue with the presentation on "security considerations section"... Tal: I completely agree with this slide. But how does slide 5 work with the fact that the confidentiality, integrity and authentication are must requirements. I mean if we need to do a threat analysis, and based on that threat analysis we need to decide which requirements are applicable and which ones are not, why are we requiring as a must to implement confidentiality, integrity and authentication? Ilango:Ê It's a must in that particular scenario. It is not a must all the time. For example let's say in a multi-tenancy data center, the requirement is to protect the data between two NVE pairs and that's a requirement. In that case the data center operator must enable it in order to protect the data. If you go and read through the BCP 72 guideline, it is very clear that we need to identify the threat and also we need to clearly specify what is a must and what is a should or what is a must not. That needs to be very clearly explained. If you go back to look at RFC 8300, that recently went through this process. It was very clear that we have to provide such requirements. That's exactly what we try to follow in updating the security consideration section here. Tal: So the way I'm reading the current version of the draft, maybe I'm not reading it right, is that you must implement confidentiality, you must implement integrity, and you must implement authentication. Ilango: We can add qualifying statement that's what I said in the next page. It's possible to add qualifying statement to make sure that it is applicable only in such scenario, provided the operator has done or there is a risk assessment and based on that they intend to enable it. Tal: I think we have to rephrase it because right now it says something which is very difficult to follow. I think if we're saying you must implement confidentiality, and we're not defining an encryption algorithm and we're not defining a protocol. First of all no one will implement it, second of all there is no way to interoperate. So it won't work. I would suggest to be very careful about using the word must in capital letters. Suggest to remove it or to phrase it very carefully in a way that will be clear that we're not actually expecting people to implement it as a must, but only to use it in certain scenarios. Ilango: I think we still have to include the must statements in there because we need to clearly specify that. You can also refer back to the recently completed RFC process. I also monitored some of the exchanges that went through during that draft review process. We will have to clearly specify the risk and we'll also clearly specify what those requirements are. But it is possible for us to add qualifying statements in such a way that requirement is not applicable to all scenarios. It's only required in a specific scenario where that threat is deemed necessary by that operator. Matthew Bocci: Try to clarify Tal's comments: There's no point in having a must if you don't have a mechanism to back up that must right now. It's quite common in security considerations to give examples of protocols that can satisfy that requirement. So if there's specific protocols that you have in mind to provide these, then you can just lift those as examples. Rather than leaving it completely open-ended. Tal: The way we read the text right now is it says as an instruction to the implementer. You must implement these things. And as an implementer I'm reading this and I'm saying I can't comply to Geneve because I can't implement confidentiality and I don't know what to implement. So we can't leave it like this. Matthew Bocci: There are other ways to phrase it. Perhaps less prescriptive but satisfy that the kind of purpose of the security considerations section. Speaking as a co-author of other RFCs, from what we have done, you have to start the state what the threat is, and then say there are mechanisms available. Enlist some mechanisms to mitigate against that threat. Tal: Just as a suggestion what we did for example in the tic-tock. We had security requirements so what we did was we define the security requirements for a security mechanism. That is if you're implementing a security mechanism in a system that requires this mechanism based on threat analysis, these are the requirements, some of them are must and some of them are should and so on. But that's if you're implementing the mechanism. So it's not a must to the implementer. It's a must to whoever is using or deploying security mechanism. That's what I suggest to do here. Ilango: Point well-taken. We'll try to maybe rephrase it in such a way that it is very clear what we intend to do here. Matthew Bocci: I think one of the things that we intend to do with this document is once we see a new version of it, we will start WG last call to this, and ask for a security area review. So what I suggest you do is to write down what makes sense for an implementer of Geneve here, because this is supposed to be specifying the Geneva Protocol. And hopefully we can get some advice back from the security area or some guidance on whether or not what is written in there is adequate. Somehow we have to come to a compromise here as to what makes sense for a protocol spec while having sufficient text in there to also guide the fact that if you need to meet these security requirements in certain deployments, obviously you must implement these other mechanisms. Ilango: Shall we send the draft to ask for security review or after we make rephrase of some of these sentences and then send it for a security review? Matthew Bocci: First rephrase it in a way that makes sense for an implementer. It sounds like we don't yet have consensus on the current text. So let's get some consensus in this working group first and then send it for wider review. Ilango: All right. Daniel: I think it's a good path to go through. Because having strong security requirements that are not implementable I don't think is going to be helpful for the review Daniel: What is the timeline to submit it for security area review or IESG? Matthew Bocci: Let's get some consensus. If you could maybe work with Tal and the authors to propose some text for this section, try to get consensus on the NVO3 list first, so in the next couple of weeks. It's only a couple of sentences. Then we will revise the draft and go for a security area review first and then a working group last call based on any feedback from that. So I definitely like to get this sent to Martin before Bangkok. 4.draft-fmm-nvo3-pm-alt-mark-02ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Guiseppe Fioccola, 10 min Tal presenting.... Daniel: Clarifying question. The marking and the reading of the marking being performed at the NVE or any node in the network?Ê Tal: At NVE. The idea is that the NVEs are assigning that marking bit and the terminating NVEs are using that marking bit. Ilango: Follow-up to Daniel's question. So basically what you're saying is the NVE is the one that is marking this bit and NVE is the one that's consuming this bit as well. Tal: Yes Matthew Bocci: Hands up if you have read this draft. About Three?Ê Ilango: If that is the case then why won't they use the options in order to do this because that was the intent of having extensibility rather than using the base header? You can have the option to indicate this information and you're not limited by in the number of bits. A lot more space in order to do it or provide metadata between the NVEs.Ê Tal: Right, you can use the options. But the idea is that since this approach only requires a single bit or two bits, very small number of bits, it's a bit of a waste to use an option for this. If we can spare a bit for or two for this in the Geneva header, we can just be more efficient and still get that functionality. Ilango: I believe that this is exactly the reason why we have extensibility and also not all the deployments will need this. So it will be better to have an option. And then you are not limited by one or two bits. If you want one or two bit that's fine but if you want to use more, that allows you use the extensibility feature of Geneve in order to do this. That's my opinion. Greg Mirsky: So strictly speaking there is no consumption of the marking field. And I probably have a different opinion from TalÕs that effectively the test point that acts on the value of the marking field can be anywhere in the tunnel. It's not necessarily the edge NVE. The benefit of using fixed position of the marking field is that simplification of the operation of the test point. Because then it makes its well-known position in a packet rather than you need to parse their variable length portion of the header to identify where the field is. Ilango: Is that a question to Tal? Greg Mirsky: No, it's my answer to your suggestion to use a variable length extensible part of the header for the marketing field because that will make it hardware support of it less efficient. Again I want to point that this method is even though it's classified as a hybrid method similar to other hybrid methods, it does not transport data in a packet. The data being calculated locally at the test point and then can be exported out of band. So which makes it even more efficient because you don't need to transport each and every timestamp of the marked packet.Ê Ilango: I still believe that you can use the options for this purpose. Because most of the Geneva endpoints that are implementing will also be able to implement options. The efficiency is not an issue. So I don't believe that efficiency is an issue whether you're interpreting an option or whether you are interpreting bits in an option. Greg Mirsky: I agree with you everything can be done differently there is not one way to slice the bread. But in terms of performance monitoring, being able to identify the packet as close as possible when it's being received, it's almost critical. Because if for example the timestamp is not taken during the physical reception of the packet, then you are measuring something else. Basically you are measuring internal queuing delays and internal processing rather than propagation delay. That becomes a variable so their quality accuracy of measurements suffers. We can discuss it at length but I want to assure you that it is important. Matthew Bocci: Greg, I think I had similar comments. If you're adding options in a performance monitoring, you're making the packets bigger. You don't want the fact that you've added these additional option fields or headers to impact your OAM measurements which are supposed to represent the user traffic behavior. Greg Mirsky: The alternate marking method works on the user traffic. And the idea of using pre-allocated field in a fixed size header or at least fixed size portion of the header makes it almost as best measurement because there is no increase in the size. As Tal pointed out the size of the flag is so small, so adding option will be significant overhead to the actual size of their marking field. Matthew Bocci: Right, we're saying the same thing. 5.draft-mirsky-rtgwg-oam-identify-00ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Greg Mirsky, 10 min Greg presenting... Matthew Bocci: I guess one of the questions really is where to discuss the draft if it should be on the routing. Is it only specific to the NVO3 or within the context of the routing area working group?Ê Greg: Jeff asked that because he was aware that I'll have presentations at NVO3 and then SFC. So he asked to summarize their discussion. I think that again if somebody wants to have it in one group. But the discussion should include all these groups. And actually I think that because there is consideration for GUE. We need to involve the group that works on GUE as well to make them aware of our discussion and our arguments. Martin: According to you, what is the set of competencies needed for that document? Is it NVO3? Greg: I definitely wanted to have impact on SFC. I want them to think about it and to discuss it. Matthew Bocci: So given that the document is about surveys on the mechanisms that are in place at the moment, and the various OAM and the various overlay encapsulations, and that some of those encapsulations are quite well advanced, and of those implementations of them, what do you see the value of the document? Do you see that if the document is going to change encapsulations or are you hoping to change encapsulation existed today?Ê Greg: No. I try to make my recommendation as least intrusive as possible. For example we have probably the most advanced would be SFC NSH. For an SFC NSH, we haven't made much progress on OAM framework and it is still being worked on. We may redefine the interpretation of O bit in an NSH header and we just then define the value for next protocol to identify active OAM. So I don't think that would be a very big change and I would see it as being backward compatible. But it's worth discussion because people might have some ideas. Matthew Bocci: If I could encourage folks in this working group to read the draft and probably provide feedback on the routing area from an NVO3 perspective, I think that would be the way to do it.