IETF99 NVO3 WG agenda Session 1 (90 mins) WEDNESDAY July 19, 2017 1520-1650 Afternoon Session II. 90 mins. Congress hall III RTG nvo3 Network Virtualization Overlays WG 1. Administrativia. 5 min. WG Chairs. Matthew: Meeting starting. Note Well applies. This is a first normal meeting we had in a while, previous meetings had experiments with the roundtables. This generated some drafts for security topic. Agenda bashing. Towards the end of the agenda we have an overview of EVPN work in BESS that is relevant to NVO3. Milestones. Document status. One new RFC, use cases. Nothing in RFC editor queue. Multicast framework went through LC and publication was requested. Adopted the DT document for dataplane encapsulation, and Geneve draft is adopted too. We ran adoption poll for two OAM drafts. There was no consensus on adopting. Progress needs to be made on those drafts and discussions on the list will be initiated. Geneve draft will be presented remotely. 2. WG status update. 5 min. WG Chairs. 3. Data Plane Design Team. draft-ietf-nvo3-encap-00 10 min. Sami Boutros Sami presenting. An update for DT encapsulation draft. We removed backwards compatibility as a requirement. Bit flag extensibility was also removed. More clarifications to the document overall. Recommendation on guidance on how control plane could help in option processing. Clarified transit node option processing. Clarified TLV processing. Clarifications for both hardware and software implementation considerations. Clarifications on variable length requirements. OAM clarifications on alternative marking and the need for 1 or 2 bits. OAM usage models need to be discussed more. We need to talk more how OAM can be addressed in general and how that could be addressed by Geneve. Fragmentation handling. Critical bit usage in Geneve draft. Telemetry TLV option requiting 256 bytes, further discussion needs to happen on this topic. IPsec usage clarifications. Entropy discussions happening, NAT traversal too. Tal Mizrahi: I am a coauthor, and question is intended to the chairs. VXLAN-GPE at this time is still a standards track draft. Is there a future in GPE, and when the recommendations will come into effect? Matthew: When we chartered the DT for encapsulation, we stated that the other encapsulation drafts will have to wait after Geneve is done. If people want to progress other encapsulations as informational documents they can do. There needs to be changes done to the GPE draft as it states standards track at this time and that needs to be fixed. IANA allocations need to be fixed too. Greg Mirsky: The questions that were listed in the dataplane DT presentation, how are they addressed in the Geneve presentation? Sami: That will be presented in Geneve presentation. Greg: One of the questions is on the OAM bit. I do not expect the answer now but that needs to be discussed. Sami: All the comments that are put on Geneve are getting addressed. 4. Draft Geneve Update. draft-ietf-nvo3-geneve-04 10min. Ilango Ganga (remote) Ilango presenting remotely. [Meetecho did not work, Sami presenting locally.] Ilango presenting remotely finally:-) Ilango: We are coordinating with the dataplane DT. Updates are based on the recommendations of the DT. Control plane constrains for the options. Control plane can limit the number of TLV ordering and the amount of TLVs. This helps both SW and HW implementation on the endpoints. Control plane should have the capability to describe the properties of the endpoints. Recommendations for OAM – allow the recommendations as for PWE3 and L2VPN to avoid MTU and fragmentation issues. Even if there is fragmentation, it needs to be done before encapsulation to avoid transit fragmentation. OAM, two bits for alternate marking method. OAM proposals and use cases are for further discussion before we make any changes. Usage of existing OAM bit. The draft proposes an OAM channel. OAM discussions need to mature and we will make changes afterwards. Critical bit processing is helpful for critical option processing. If that is not clarified enough we will add additional text. Increasing option size to 256, mainly targeted for telemetry use cases. WG needs to comment on this topic. It will limit the options that can be carried in Geneve, if telemetry option takes all the space it will be difficult to carry other options. Next steps. Discussion on the list is fed back into the changes to the Geneve encapsulation draft. [No questions and discussions.] 5. Geneve Protocol Security Requirements draft-mglt-nvo3-geneve-security-requirements-00 10 mins. Daniel Migault Daniel presenting. A set of 4 drafts, requirements, proposed solution approaches, and then architectural overview of how it combines together. Tenants can encrypt their own communication themselves, this is not in the scope of Geneve but the scope of the tenants. Any nodes on the path need to be able to read Geneve packets. Geneve NVE needs to agree that the authentication includes some options and include some part of the payload. If you want to authenticate a single Geneve option then the payload is not involved. Geneve intermediate forwarding element may validate the packet before it reaches its destination. Forwarding nodes that are not supporting the authentication option still can work and forward the packets. Redirection and leakage – that is more of a deployment aspect and less of the protocol one. How could you mitigate the leakage by making it meaningless even if it still happens. IPsec use even can reveal much of the information like addresses. TLVs also leak information like ports. Geneve NVE must be able to encrypt options that are not intended to be modified. How we can make the overlay robust itself? A replay attack on OAM traffic. If you increase the volume of OAM traffic you can disrupt the network. This requires anti-replay mechanisms. Tal: Thanks for putting together this draft. One thing that is missing for me to understand is the threat analysis to understand the set of attack vectors and have a mapping of the vectors and requirements. Daniel: Are you suggesting that for the draft? Tal: Yes. Daniel: We can discuss this. Suresh: I would like to see some requirements why encrypting UDP is not enough. Dniel: We have included that. Suresh: The document structure is a bit difficult to handle. Maybe one document could cover the architecture and the options. Daniel: That would be good – merging into one draft. 6. Geneve Header Authentication Option (GAO) draft-mglt-nvo3-geneve-authentication-option-00 10 mins. Daniel Migault Geneve Header Encryption Option (GEO) draft-mglt-nvo3-geneve-encryption-option-00 10 mins: Daniel Migault Daniel presenting. Why the current DTLS and the IPsec solution does not fulfill the requirements, and why do we need a Geneve specific solution. We use IPsec AH adapted for Geneve. It allows to insert option on-path. It is a Geneve option, the ID used in IPsec is SPI and is 32 bits, here a shorter value is sufficient. We have Geneve fixed header, then options that are not covered, then GAO, and after it the authenticated options. When you see the packet you know already which options will be authenticated and which will not be. Processing is similar to IPsec. Encryption option is similar to IPsec ESP. A difference is that it does not include the whole packet but instead the indicated length after the marker is encrypted. We usually use authentication encryption, Geneve fixed header is authenticated too. 7. Geneve Security Architecture draft-mglt-nvo3-geneve-security-architecture-00 10 mins. Daniel Migault Daniel presenting. Security architecture focuses how to associate the security options to flows. How do we define whether the packet needs to be protected or not. Traffic selector is used for that. In a controlled environment the required security policies and associations will be provided, but it is also possible to use IKEv2 for more dynamic associations. If you receive the packet and cannot validate the signature that is fine, but you need to validate it against the security policy. TLS does not make it simpler, it is a different model how TLS is being used. Any questions? Behcet: It is Geneve, and not Geneve, how do you pronounce it? Matthew: Any Geneve authors in the room? :-) 8. IPsec over Geneve draft-boutros-nvo3-ipsec-over-geneve-00 10 mins. Sami Boutros Sami presenting. A description of how ESP could be carried in Geneve tunnel. A description of encapsulation used for carrying AH over Geneve tunnel. Please comment on the list. Behcet: Can this be used with VXLAN? Sami: VXLAN does not carry protocol identifier field. Behcet: Can you encapsulate via ESP? Sami: Geneve has a field to indicate the protocol number. VXLAN has only the VNI. Tal: I hope there are IPsec experts who could correct me if I am wrong but I recall at some point I recall that EH was deprecated. Daniel: This debate comes up every few years. There is a draft on how to protect AH. 9. EVPN Overview for NVO3 No draft. 10 mins. Jorge Rabadan Jorge presenting. Chairs have asked to present what we are doing in BESS on DC overlay networks. Brief EVPN overview, and then the work in the BESS on overlays. EVPN – the original idea was to have L2VPN operated in the similar was as we do with routed L3VPNs, replacing the flood and learn behavior with BGP. That gives a lot of control, and allows to have quick MAC mobility. Efficient ability to deliver BUM traffic. Ability to support efficient multihoming. EVPN has evolved since the RFC7432, it is a unified control plane technology that allows to have not only L2 connectivity technologies. EVPN support NVO3 tunnels, with the most popular option being VXLAN. An open discussion what do we need to do for NVO3 to be able to use EVPN as a control plane. We would need to extend EVPN with extensions for support of new encapsulations and extensions. Mattew: Any comments? Parviz: Did you cover WAN connectivity? Jorge: Yes, in BESS WGLC now. Matthew: We asked to have an overview of what is going in BESS on EVPN. It is a question whether we need an applicability document in NVO3 how EVPN fits into the NVO3 architecture. Second – we need a way to input our requirements into BESS. Sam Aldrin: Applicability document will be generated here and solution documents will be worked in BESS. 10. Update on IEEE 802.1Qcn (VDP extnsion to support NVO3) draft-ietf-nvo3-hpvr2nve-cp-req-06 5 mins. Yizhou Li Yizhou presenting. Update on the 0.5 draft. Last week there was 802.1 plenary meeting and there was nothing controversial, draft will be updated to 0.6. 802.1Qcn has a name conflict with queue congestion notification project work, our one will move to some other project number. 10. VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG draft-huang-nvo3-gpe-extension-for-vbng-00 5 mins. Lu Huang Lu presenting. Presenting on the problem space, requirements, and the proposed solution. Michael/Huawei: Why do we need this optional solution as we have discussed with operators and the split of slot/subslot/card id may not be enough. The requirement is to have a more flexible split of port identifier components. Lu: Requesting for WG adoption. Questions? Matthew: Thank you. Matthew: Any further comments on the topics discussed? End of meeting.