Working group,
Draft minutes of IETF99 NVO3 meeting are now available and also posted
on the meeting materials page. Please review and indicate any
corrections needed.
Thank you.
Ignas
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.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
