Nvo3 Status PagesNetwork Virtualization Overlays (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2012-May-01 —Chairs:
IETF-104 nvo3 minutes
Session 2019-03-28 1050-1220: Berlin/Brussels - Audio stream - nvo3 chatroom
Network Virtualisation Overlays WG Thursday Morning session II - 10:50-12:20 ¨C Berlin/Brussels 1. WG Status update Agenda bashing...milestones, document status 2. Security requirements update draft-mglt-nvo3-geneve-security-requirements-06 Daniel Migault presenting... One of the key issue is Geneve & DTLS. Geneve co-authors seem think DTLS is sufficient and security capabilities for transit devices are not necessary. Daniel: - transit devices make Geneve security mechanism implemented through Geneve options - Geneve options are interpreted by transit device or NVE - So transit devices prevent e2e security with geneve. - Explainging why DTLS is not sufficient for all cases. Question: Do we need transit device? (use case for transit device¡) Matthew: Oam requires transit devices to inspect. Have drafts talking about trace route. I do not know if you call it a transit devices. In the framework we don't have transit devices formally defined¡ David: A need for transit device to insert/remove/modify options or just visible to transit devices but not be modifiable in route? Daniel: Only read in current spec David: If current spec is only read, then with a little bit more design work, unfortunately DTLS is not exactly what you want, you can arrange to secure the readable options for integrity e2e without encrypting them and then encrypt everything else, and at that point you are back to e2e security model, just some of the stuff that you have integrity protected end-to-end is in the clear. Daniel: I think that¡¯s something can be done if we need these transit devices. Maybe we can also agree to have whatever is being read by the transit device, protect it or not, but that's need to be clearly stated and discussed. Ilango: You are not characterizing the transit devices accurately and that's the main contention between what your written in the document versus what the architecture is supposed in Geneve. Transit devices exist in the network. It could be the switches or routers, whatever that forwards the traffic between the two endpoints. We have a formal guidelines so that you're exposing or when the transit devices are viewing the Geneve headers information, they can use that information, I gave you a very specific example, could be ECMP purposes that could be an option that has flow context. If Geneve is secure between the NVEs then it doesn't have the visibility and if it doesn't have the visibility it can continue to forward it based upon the outer header information. And that's how the transit devices today operate in Geneve and even with other encapsulations. Geneve does not require the transit devices to look at or observe the options in order to forward the traffic. That's number one, this is if you are using encryption. If you're not using encryption, as David black said if you're using data integrity mechanism, then you don't have to do that. So different deployments may choose to expose this information to the transit devices or not depending upon what's applicable to that deployment. It doesn't mean that Geneve is not secure or not secure e2e. So I would suggest that the author does not miss characterize that Geneve was insecure just because you want to take we are exposing that to the transit devices. Even if you remove the transit devices, nothing precludes the transit devices from viewing the data. David Black: I don't think I heard a suggestion that was insecure. What I think I heard was a suggestion that if you want transit devices you need to do something Geneve specific. What I heard from Ilango was mostly in terms of exposure not modification which is going to make the problem much simpler. I also think back to the router, tutorial discussion yesterday afternoon, and I would suggest that inserting or removing options in route is going to be painful for high speed hardware. That's clearly avoided, modification would be bad enough. If it sounds like we don't even need to do that which means that you've probably got an end-to-end security model. You just have to figure out how to spec the crypto to get integrity on the stuff that needs to be exposed to the transit devices. Ilango, I must have said something. Ilango: You said it correctly David. Transit devices can view the Data, it cannot modify or it cannot insert the options. The options can be inserted or in general Geneve header is inserted and removed by the endpoints, not by the transit devices. Tom Herbert: That last effectively means that transit devices cannot modify UDP payload. It's problematic because they don't know if this is actually Geneve, this could be used for anything. So this should be a must not modify in flight as far as I'm concerned. Ilango: We have spec in the document saying they must not modify. Herbert said is accurate that the specification clearly says that the transit devices must not modify Geneve headers. Greg: I think that I understood comment differently, it was not saying that says, it should say. In connection to yesterday BoF is there was a suggestion to start data plane consideration especially for new encapsulations and variable length encapsulations, I think that will be good to take it before it becomes mandatory and add a section that will highlight impact of Geneve on a fast path processing. Daniel: Try to summarize some of the comments. The current spec is saying clearly that transit device can only read, but the current spec does not make any recommendation on how to protect the Geneve packets. So if you use the transit device, following the current recommendation for security mechanisms, you cannot deploy transit device in a secure way. Matthew: Wrap up? Daniel: More characterization is needed on the transit device so that to clarify this, because they appear clearly like middleboxes so which need explicit signaling. This has been debated and I think it would be useful to be done here. Transit device are somehow hardly compatible with UDP encapsulation because how a transit device will detect it's a Geneve packet¡ (Continue with conclusion slide¡) Feel free to be active on the milling I'm happy to any feedback. 3. Geneve update draft-ietf-nvo3-geneve-12 Ilango Ganga presenting remotely... David Black: TSV reviewer. Thank authors for doing a very productive and cooperative job of addressing difficult comments on the draft. There are a couple of issues I would characterize as half open. I want to quickly bring attention I expect more attention during IETF last call. The first one is that omitting UDP checksums in ipv6 is an interesting area. To zero the UDP checksum you want to increase the hamming distance between valid packets as much as you can. One of the recommend techniques for doing so is to vary the ipv6 source address. Not clear that this is what running code is prepared to do. And the other one is that it's a very good idea for an encapsulating NVE to maintain an MTU value for the tunnel, particularly when that encapsulation NVE is not at the origination point. The upshot is that if you send a packet into that NVE from the network and it's too large you get the ICMP response from encapsulating node rather than getting it downstream somewhere and risking lose using ICMP payload. Both these I think are very good. Ilango: Thank you, the working group members can review that those two points. Matthew: The chairs will probably discuss how to proceed with this because we still have these ongoing security comments coming from Daniel. He is the only person who still has concerns on the list. They may be valid and we have to be aware of those. May be brought up again in the security Directorate review and review by the security ADs if we progress .We'll get together with the authors and decide how to proceed. As far as we can see from perspective of calling consensus from the list discussion, we're probably pretty much there. But there's still some discussion on security that we have to be aware of. So I can address that as a part of the Shepherd¡¯s review. T. Sridhar: I just wanted to highlight the help from multiple folks on making this a better draft and also we believe draft version 13 will address the comments for the security considerations as well and clarify the text with respect to the role of transit devices. 4. 5G-Datacenter Interconnection Use Case draft-defoy-nvo3-5g-datacenter-interconnection-00 Xavier De Foy presenting... Remy: I think it is a very interesting usage scenario because I think in this room most of people are talking about DCN and you are talking about interconnection of DCs. So in your opinion is there any usage scenarios which permit us to define for example sub TLVs for Geneve? Xavier: At this point I don't really know of any impact on in NVO3. That¡¯s very high level. Remy: It may be a good thing because people are not very clear about the definition of TLVs, how to use and what can they do with TLVs. If we find some interesting scenarios, we can define some TLVs for Geneve. I think it will be helpful to extend the usage scope of Geneve. Xavier: Thank you and that's one of the goals of coming here is to find people interested in the community who would like to bring some expertise in data centers, and see if they are interested or not... Greg: In 5G we learn that they're considering three use cases. It's ultra reliable low latency, extended mobile broadband and extensive machine to machine communication. Do you see that for all these three scenarios, one solution will be suitable? Xavier: Actually I hope that not. A lot of work being done in 5g to support edge computing as you know probably and that was a new study starting to enhance the support for edge computing. So I think that right now 5G does not really mandate any specific thing outside of 5G in terms of data centers. It provides some mechanism to enable interconnection with external data networks. So personally I don't think there is one solution that will be mandatory. Greg: A little bit different angle. So where would you suggest to look for requirements for these use cases or scenarios? I think that ultra reliable low latency especially, since you mentioned multi-access edge computing to minimize round-trip delay, might have some distinct set of requirements comparing to enhance mobile broadband. Would you suggest any source of requirements? Xavier: You may have an answer from somebody behind you. Ulises: I think that one of the reasons why we think it is interesting here and have the feedback from the community is that we're also looking at the 5GLAN feature that is going to be developed in 3GPP. Based on the requirements I've seen there, the case of the reliable communication in particular the use of 5GLAN like systems for industrial IOT, I think that will be the use case that from my perspective will be the modules for this type of 5GLAN cases. That would be my input to your question. Yizhou: I want to bring your attention to what we have already done in NVO3 working group called the split NVE or external NVE. Your NVE which is an external device from the end device is a bit different from our current case because we are more focusing on the wired part so there is a VLAN mapping between the so called VNI and VLAN ID. I'm probably want to consider for the 5GLAN case what kind of mapping information from the PTU session since you don't have VNI information there. That's one possibility that's how NVO3 can help in your scenario. Xavier: Thank you, maybe we can talk shortly after session. Matthew: Who has read the draft? (not many) Those have read the draft, who thinks this is in scope of NVO3 first of all? As our Charter is very much focused around kind of traditional fixed data centers in one geographical site, not DC interconnection, but inside of a physical data center. And a distributed data center architecture like this is perhaps a little bit new. Xavier: Will you advise on whether we should continue this work right now? Matthew: I'd suggest that you need to get some more feedback on the list and you get some more people to read the draft. I think there is kind of scoping issue and charter issue, will talk that to AD. 5. Base YANG Data Model for NVO3 Protocols draft-zhang-nvo3-yang-cfg-05 Remy presenting... Matthew: General comment from me I think it needs to be very clear on the scope. Because we've got another young model draft coming up next. To be very clear on the scope of the individual YANG models that one is generic to the overall architecture and the other one is specific to configure the parameters of a particular encapsulations right? Remy: Yes 6. YANG Data Model for NVO3 Protocol draft-chen-nvo3-yang-00 Ran presenting... Remy: I have a couple of comments. First of all just to make sure that this YANG just cover Geneve and VXLAN-GPE right? Ran: Yes Remy: So the second question is what is the mapping relationship between this YANG model and NVO3 architecture? Because here I can't see the terminology that I've been familiar with. For example I can not see the NVE here. Ran: We will update later. Remy: NVO3 instance and NVE, what's mapping relationship? Not obvious Ran: will update Remy: have NVE first, then... do not get the point from your model Ran: I am defining in a different way from your draft Some arguments between Ran & Remy on the mapping and sequences of some particular parameters. Ignas (OPS AD): I do care about manageability. Have a slightly broader discussion because what I see happening here is talk about tiny fragments but I'm not certain whether the working group has the broader view or the manageability. Matthew: We did have an operational requirements draft a long long time ago. We don't have any really active doc. We don't have really any draft apart framework at the moment on overall what you need to manage in an nvo3 network. Ignas: So the problematic aspect that I would see is, first an NVO interface is an interface, it's not a special type of interface. Therefore from a manageability point, it should be put into the hierarchy as any other interface and have its own parameters. The transport protocols below 2e2 client protocols should be aligned with the overall manageability of other transport e2e client protocols. NVO3 is no special if I want to try to use that for practical purposes in a practical network. If it is radically different than IP or MPLS encapsulated interface, something is just not right. Another aspect and that's probably broader, what probably needs to be done is to revisit the use cases draft, and try to talk to the user community, what problems they are trying to solve and how they are trying to do that, and this will come as a set of requirements how that should be managed. The fact that you have a YANG model, it's good, but that is nowhere near enough. It's just a tool but it needs to fit into the overall management hierarchy somehow. 7. BFD for Geneve draft-xiao-bfd-geneve-00 Xiao Min presenting Matthew: The question is do we need to separate modes for encapsulation of BFD in here? Can we just rely on the fact that IP UDP packet or do we need effectively a unique protocol type for BFD in the Geneve header? This kind of precedent for this in MPLS and past, for example you can either run BFD on IP UDP or you can explicitly identify in the G-ACh that you're carrying BFD. But that was really for MPLS TP where you did not rely on IP forwarding. I think in the case of Geneve it's an IP underlay. So do we actually have a need for this to uniquely distinguish BFD? Any feedback on this? Has anybody read this draft yet? Greg: Co-author. It's a question for the working group and in my opinion it's a broader scope question of oam in NVO3 and Geneve. Because how do we encapsulate BFD in this case is a question for this draft and in general how to demultiplex active OAM protocols in NVO protocols, in Geneve in particular. So I think that since Geneve specification is stable and ready to be passed to IESG, I think that we're at a time where we can start looking at question. Matthew: yeah, feedback? Sami: I do have some basic question first and maybe we can provide feedback about whether we should include an IP header. When you are running BFD here, are you testing the connectivity of the tunnel or VNI service? Ming: Tunnel. Sami: So what would be the VNI value? Greg: As being mentioned in the document presentation, there is a lot of similarity with the BFD for VXLAN. You probably know that BFD for VXLAN is waiting for AD review, so it passed BFD working group last call and will follow similar interpretation of VNI in this specification and it is the VXLAN. But obviously if you have some suggestions, welcome. Sami: Sure. I think the other comment is that when we did BFD for mpls-tp and didn't include an IP header, it was mainly because we didn't have an IP network on which we could be running BFD on. But I think the case here is different. We already have an IP network. Greg: The reason to question whether to include IP header because it's extra header and the only purpose of this header is UDP port to demultiplex the payload. Think of our ipv6 addressing what unnecessary overhead we're inflicting just to carry our UDP port, so that's why we're suggesting to consider use of ACH. BFD is supposed to be right weight. If we add ipv6 IP UDP headers on top, like 40 bytes of BFD, so the header is larger than BFD, right? The overhead is like hundred and twenty percent. So I think that it's a good enough reason to at least to consider it. Sami: I think the same comment applies that the associated channel was added because you are running on a non-IP network. I understand overhead well¡. Greg: Associated channel was not only added because MPLS-TP. Associated channel is just generalization of pseudowire VCCV. So it's basically taking the clue from technology already existed. Because basically the same mode is run over pseudowires. There was no IP encapsulation needed for the pseudowire BFD. Sami: layer 2 only and not layer 3. Meaning an associated channel was added for pseudowires VCCV because pseudowire would carry layer 2 traffic that could carry IP or non IP. But here the cases are we already have an IP network. If you are worried about overhead, anyway Geneve header is an overhead. Ming: Sami, when you say IP network you mean underlay network? Sami: Correct. I think when VCCV was added or associated channel was added, for pseudowire we are carrying only layer 2. L2 does not need to carry only layer 3 and it can carry other protocols, others an IP. This is why you need to have BFD running with associated channel because the network may not have IP and so on, right? But in here you have an underlay which is IP¡ Ming: for the overlay, maybe no IP¡ Sami: What you're saying is that I'm carrying a layer 2 overlay and now is that layer 2 overlay may not be an IP overlay, then I should have an protocol for BFD similar to the associated channel so I can run BFD on it as a control message only. I think okay, I can buy that argument. Tom Herbert: I'm looking at the Geneve header, there's a control bit or O bit that says control packet. In this scenario what would that be set to? Is this a control packet? Greg: It's great question thank you. We don't know. Tom: So let's assume that we do set the control bit. Then my question becomes, the protocol type field, what does that mean when the control bit is set? Greg: Another great question thank you. Tom: Third part is, this is answered in GUE. If the control bit is set in GUE, that protocol type field is now a control type field, it's a completely different numbering space. So what I'm concerned about here is do you really want to add an ethertype for control messages? It seems like a slippery slope so you might want to consider something like. Greg: Point to what has been done in SFC NSH. It does have O bit which in RFC8300 was defined as identifying oam packet. There is draft IETF-SFC multi-layer-oam which we name as SFC active oam draft. We have defined with the working group together how O bit with their protocol field identify combinations of OAM whether in header extensions. Because they can have an NSH fixed length extension or variable length extension header and oam in the payload. So it defines the situation that oam information data or commands are in a header part or in the payload part or there is no oam at all. Actually there was a discussion in Bangkok and Adrian provided case that led us to a point to situation that has to be interpreted as erroneous situation that O Bit is not set but next protocol field is oam so that has to be interpreted as erroneous. I will encourage you to look at this. I know what GUE is doing. I'm not completely agree with that because there was not all OAM goes to the control plane, in particular BFD things are done usually in the hardware. So thus changing two name spaces might be unnecessary burden on the hardware support implementation. But I'm open to discuss it. Tom: You made an important point there are two flavors of this. One is the payload is the control packet and two we want to attach control information. So it's not about OAM, it's about how do you deal with these two flavors. I have arbitrary control information to attach or I have specific... in this case it looks like the payload is the control data, which means... Greg: no¡this payload is what's supposed to be processed in the hardware¡ Tom: so is the payload contain an IP packet Greg: that's another thing that we just discussed.. Tom: What I mean is it being attached to a user IP packet? Greg: No Tom: Then I consider that a control packet. I'm not concerned about hardware versus not Hardware. On the wire what does this packet look like? If I say this is protocol type 800 and that those bits are some kind of control information, that's not ipv6. So the protocol type and the control bit and the payload have to work together, so that's unambiguous what the Geneve payload contains, and since we know the transit devices are going to try to parse this, it has to be on ambiguous for them not just the endpoints. Sami: One last comment is if you are talking about ACH here and so on, did you consider putting an MPLS label like GAL label and saying this is an MPLS packet? Why not? They are using the same approach. Is the way we did it in MPLS-TP is that you put a GAL label¡ David: We need to talk about why we're doing BFD in the first place. What is the thing on the far side whose liveness and ability to talk to us we'd like to establish. And I believe what we're going after here is the chunk of the NVE that knows how to decap Geneve. So the hardware is being referred to is the hardware that chews on the Geneve header. ¡¡because what essentially it says is the hardware chews on the Geneve header something in there says this is BFD and the BFD payload comes next, and now you have BFD solving the problem you want to solve, is the NVE capable chewing on Geneve or did something break before it opened up that header? Sami: I didn't get it. So you want BFD or you donot want BFD? David: I want the BFD header to be as close to the thing whose liveness I'm testing. The more headers you add in the middle, the more ways there are to break BFD without breaking the forwarding engine. The further away I move BFD from the chunk of hardware's liveness I care about, the more opportunities are for BFD and the hardware to not to tell me the same thing. Sami: GAL is only four bytes David: find some way to code in the Geneve header this is BFD then the hardware process of Geneve header grabs that BFD and says yes I'm here Greg: That's possible just to use a next protocol, allocate BFD next protocol and be done with it. Sami: It's already defined ACH having being used for non IP header and you want to use an ACH approach, so I didn't understand the argument why not use the ACH approach as its defined already. Greg: I think that what we can agree on that this is a separate topic for discussion because it's broader than just BFD. Matthew: yeah, to conclude, we need to describe comprehensively how the O bit is used and how that should be interpreted in Geneve. In other technologies like pseudowire, you define an exception mechanism whether that 0001b on a header or ¡ my interpretation of the O bit here is it's an exceptional mechanism that says this is a control channel message, and no more than that. But what the structure of that control channel is, whether it's something with an ACH, whether it's an IP channel, is undefined at the moment.