< draft-wei-nvo3-security-framework-00.txt   draft-wei-nvo3-security-framework-01.txt >
nvo3 Y. Wei, Ed. NV03 Working Group Y. Wei, Ed.
Internet-Draft S. Zhang Internet Draft ZTE Corporation
Intended status: Informational ZTE Corporation Intended status: Informational L. Fang, Ed.
Expires: December 22, 2012 June 20, 2012 Expires: January 16, 2013 Cisco Systems
S. Zhang
ZTE Corporation
NVO3 Security Framework July 16, 2012
draft-wei-nvo3-security-framework-00
NVO3 Security Framework
draft-wei-nvo3-security-framework-01
Abstract Abstract
This document provides a security framework for overlay based network This document provides a security framework for overlay based
virtualization. It describes the security reference model, the network virtualization. It describes the security reference model,
security threats and security requirements. the security threats and security requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress".
This Internet-Draft will expire on December 22, 2012. This Internet-Draft will expire on January 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
NVO3 Security Framework
Expires Jan. 2013
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction .................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
3. Security Reference Model . . . . . . . . . . . . . . . . . . . 4 2. Terminologies ................................................3
4. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 5 3
4.1. Attacks on Control Plane . . . . . . . . . . . . . . . . . 6 3. Security Reference Models ....................................5
4.2. Attacks on Data Plane . . . . . . . . . . . . . . . . . . . 6 5
5. Security Requirements . . . . . . . . . . . . . . . . . . . . . 6 3.1. Scenario 1: Virtual Network and DC infrastructure belong to
5.1. Control Plane Security Requirements . . . . . . . . . . . . 7 the same DC operator ............................................5
5.2. Data Plane Security Requirements . . . . . . . . . . . . . 7 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Threats .............................................6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4.1. Attacks on Control Plane ..................................7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 4.2. Attacks on the Data Plane .................................7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Requirements ........................................8
8
5.1. Control Plane Security Requirements .......................8
8
5.2. Data Plane Security Requirements ..........................8
8
6. Security Considerations ......................................8
8
7. IANA Considerations ..........................................9
9
8. Normative References .........................................9
9
9. Informative References .......................................9
9
10. Author's Addresses ........................................10
10
1. Introduction Requirements Language
Security is one of important factors in the envrionment of cloud Although this document is not a protocol specification, the key
computing. This issue should be addressed for the overlay based words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
network virtualization, which supports multi-tenancy in data center. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [RFC
Security considerations have already been provided in each of the 1. Introduction
individual document on framework, control plane and data plane NVO3 Security Framework
requirements of data center network virtualization over Layer Expires Jan. 2013
3(NVO3). [I-D.lasserre-nvo3-framework] describes that the tenant to
overlay mapping function can introduce significant security risks if
appropriate security mechanisms are not used for protocol.
[I-D.kreeger-nvo3-overlay-cp] describes that the protocol should
protect the integrity of the mapping, and overlay exposes virtual
networks to attacks on the underlying network such as traffic
injection. [I-D.bitar-lasserre-nvo3-dp-reqs] also describes the
security risks of the tenant to overlay mapping function.
Security is one of most important factors in the environment of
cloud computing and particularly to the Data Center Network
Virtualization where multi-tenancy support is one of the fundamental
requirements.
Though security considerations are provided in several individual
documents, a general description of security for NVO3 is needed,
especially there are areas not covered in the current documents.
The motivation of this document is to provide a general and The motivation of this document is to provide a general and
consistent security description for NVO3, and to complement with consistent security framework for NVO3, and to provide a guidance
security considerations in the current documents. This document is for the design of related protocol.
organized as follows. Section 3 describes the security reference
model for NVO3. Section 4 describes the security threats under the
security model. Section 5 addresses the security requirements
corresponding to the security issues.
2. Terminology This document is organized as follows. Section 3 describes the
security reference model in the context of NVO3, which defines which
component is trusted or not for a particular scenario. Section 4
describes the security threats under the security model. Section 5
addresses the security requirements in response to the security
threats.
This document introduces no new terminology. For reader's 2. Terminologies
convenience, this document repeats some of them defined in
[I-D.lasserre-nvo3-framework] [I-D.kreeger-nvo3-overlay-cp]
[I-D.bitar-lasserre-nvo3-dp-reqs].
Tenant End System(TES): An end system of a tenant, which can be for This document uses NVO3 specific terminology defined in [I-
instance a virtual machine(VM), a non-virtualized server, or a D.lasserre-nvo3-framework]. For reader's convenience, this
physical appliance. A TES attaches to Network Virtualization document repeats some of the definitions in addition to reference
Edge(NVE) node. it.
Network Virtualization Edge(NVE): An NVE implements network NVE: Network Virtualization Edge. It is a network entity that sits
virtualization functions that allow for L2/L3 tenant separation, on the edge of the NVO3 network. It implements network
tenant-related control plane activity. An NVE contains one or more virtualization functions that allow for L2 and/or L3 tenant
tenant service instances whereby a TES interfaces with its associated separation and for hiding tenant addressing information (MAC and IP
instance. The NVE also provides tunneling overlay functions. addresses). An NVE could be implemented as part of a virtual switch
within a hypervisor, a physical switch or router, a Network Service
Appliance or even be embedded within an End Station.
Virtual Network(VN): This is one of a virtual overlay network. Two VN: Virtual Network. This is a virtual L2 or L3 domain that belongs
Virtual Networks are isolated from one another. a tenant.
Overlay Boundary Point(OBP): This is a network entity that is on the VNI: Virtual Network Instance. This is one instance of a virtual
edge boundary of the overlay. It performs encapsulation to send overlay network. Two Virtual Networks are isolated from one another
packets to other OBPs across Underling Network for decapsulation. and may use overlapping addresses.
Underlying Network(UN): This is the network that provides the Virtual Network Context or VN Context: Field that is part of the
connectivity between the OBPs. overlay encapsulation header which allows the encapsulated frame to
be delivered to the appropriate virtual network endpoint by the
egress NVE. The egress NVE uses this field to determine the
appropriate virtual network context in which to process the packet.
This field MAY be an explicit, unique (to the administrative
domain) virtual network identifier (VNID) or MAY express the
NVO3 Security Framework
Expires Jan. 2013
3. Security Reference Model necessary context information in other ways (e.g. a locally
significant identifier).
This section defines security reference model for Overlay based VNID: Virtual Network Identifier. In the case where the VN context
Network Virtualization. has global significance, this is the ID value that is carried in
each data packet in the overlay encapsulation that identifies the
Virtual Network the packet belongs to.
Underlay or Underlying Network: This is the network that provides
the connectivity between NVEs. The Underlying Network can be
completely unaware of the overlay packets. Addresses within the
Underlying Network are also referred to as "outer addresses"
because they exist in the outer encapsulation. The Underlying
Network can use a completely different protocol (and address
family) from that of the overlay.
Data Center (DC): A physical complex housing physical servers,
network switches and routers, Network Service Appliances and
networked storage. The purpose of a Data Center is to provide
application and/or compute and/or storage services. One such
service is virtualized data center services, also known as
Infrastructure as a Service.
Virtual Data Center or Virtual DC: A container for virtualized
compute, storage and network services. Managed by a single tenant,
a Virtual DC can contain multiple VNs and multiple Tenant End
Systems that are connected to one or more of these VNs.
VM: Virtual Machine. Several Virtual Machines can share the
resources of a single physical computer server using the services
of a Hypervisor (see below definition).
Hypervisor: Server virtualization software running on a physical
compute server that hosts Virtual Machines. The hypervisor provides
shared compute/memory/storage and network connectivity to the VMs
that it hosts. Hypervisors often embed a Virtual Switch (see
below).
Virtual Switch: A function within a Hypervisor (typically
implemented in software) that provides similar services to a
physical Ethernet switch. It switches Ethernet frames between VMs'
virtual NICs within the same physical server, or between a VM and a
physical NIC card connecting the server to a physical Ethernet
switch. It also enforces network isolation between VMs that should
not communicate with each other.
Tenant: A customer who consumes virtualized data center services
offered by a cloud service provider. A single tenant may consume
NVO3 Security Framework
Expires Jan. 2013
one or more Virtual Data Centers hosted by the same cloud service
provider.
Tenant End System: It defines an end system of a particular tenant,
which can be for instance a virtual machine (VM), a non-virtualized
server, or a physical appliance.
3. Security Reference Models
This section defines the security reference models for Overlay
based Network Virtualization.
The L3 overlay network provides virtual network to multi-tenants, The L3 overlay network provides virtual network to multi-tenants,
which is deployed on the underlying network. The tenant end system which is deployed on the underlying network. The tenant end system
attaches to the L3 overlay network. attaches to the L3 overlay network.
L3 overlay network provides isolation to each tenant, which provides L3 overlay network provides isolation to each tenant, which
security to its tenant. L3 overlay network can be regarded secure provides a level of security to its tenant. L3 overlay network can
zone from the view of ONV3 operator. Other components outside of the be regarded secure zone from the view of ONV3 operator. Other
ONV3 are considered as untrusted, which may impose some attacks on components outside of the ONV3 are considered as untrusted, which
the ONV3. On the other hand, each virtual network may not trust may impose security risk to the NVO3 networks. Each virtual
other virtual network. This model is the basis to analyze the network should assume not trusting other virtual networks. This
security of ONV3. model is the basis to analyze the security of ONV3.
+------------------------------------+ 3.1. Scenario 1: Virtual Network and DC infrastructure
| Trusted | belong to the same DC operator
| +--------------------+ |
| |+------------------+| |
| || Virtual Network 1|| |
| |+------------------+| |
+----------+ | +-----++------------------++-----+ |
|Tenant End| | | || Virtual Network 2|| | | +----------+
| System +----+ NV |+------------------+| NV | | |Tenant End|
+----------+ | |Edge |+------------------+| Edge+----+ System |
| | || Virtual Network 3|| | | +----------+
Untrusted | +-----++------------------++-----+ |
| | L3 Overlay Network | | Untrusted
| | | |
| +--+---------------+-+ |
| | Overlay | |
| | Boundary Point| |
| +-------+-------+ |
+------------------|-----------------+
|
+----------+---------+
| Underlying Network | Untrusted
+--------------------+
Figure 1: Security Reference Model for Overlay based Network |<-----------(Trusted)---------->|
Virtualization | |
| /---------------------------\ |
++ Virtual Network L3 Overlay ++
| \---------------------------/ |
+----------+ +--+------+ +-----------+ +-------+-+ +----------+
|Tenant End| | NV | | DC infra | | NV | |Tenant End|
| System +-+ Edge +--+ Underlay +--+ Edge +-+ System |
| (TES) | | (NVE) | | Network | | (NVE) | | (TES) |
+----------+ +---------+ +-----------+ +---------+ +----------+
|<---------->|<-------->|<------------>|<--------->|<---------->|
|(Untrusted) | (Trusted)| (Trusted) | (Trusted) |(Untrusted) |
4. Security Threats Figure 1. Trust Model for Scenario 1
This section describes the various security threats that may endanger NVO3 Security Framework
overlay based network virtualization. For example, an attack on ONV3 Expires Jan. 2013
may result in some unexpected effects:
o Interrupt the connectivity of tenant's virtual network. Notes:
o Inject some unwanted traffic into virtual network.
o Eavesdrop sensitive information from tenant. 1) The diagram is a logical illustration. The TES and NVE may be
o Degrade provider's service level. implemented in the same physical device, or separate devices.
2) The physical end system may in reality include virtual
switching/routing instances and multiple VMs (TESs) belong to
different tenants.
3) The trusted or untrusted notions in the diagram is from a Virtual
Overlay Network point of view, not the underlay network.
4) Each VN treats other VNs as untrusted.
Scenario 2: Virtual Network and DC infrastructure belong to
different DC operators
|<-----------(Trusted)---------->|
| |
| /---------------------------\ |
++ Virtual Network L3 Overlay ++
| \---------------------------/ |
+----------+ +--+------+ +-----------+ +-------+-+ +----------+
|Tenant End| | NV | | DC infra | | NV | |Tenant End|
| System +-+ Edge +--+ Underlay +--+ Edge +-+ System |
| (TES) | | (NVE) | | Network | | (NVE) | | (TES) |
+----------+ +---------+ +-----------+ +---------+ +----------+
|<---------->|<-------->|<------------>|<--------->|<---------->|
|(Untrusted) | (Trusted)| (Untrusted) | (Trusted) |(Untrusted) |
Figure 2. Trust Model for Scenario 2
The same notes listed under scenario 1 also apply here.
4. Security Threats
This section describes the various security threats that may
endanger overlay based network virtualization. For example, an
attack on ONV3 may result in some unexpected effects:
o Interrupt the connectivity of tenant's virtual network.
o Inject some unwanted traffic into virtual network.
o Eavesdrop sensitive information from tenant.
o Degrade provider's service level.
NVO3 Security Framework
Expires Jan. 2013
Security threats may be malicious or casual. For example, some of Security threats may be malicious or casual. For example, some of
them may come from the following sources: them may come from the following sources:
o A tenant who rents one or more virtual networks may want to o A tenant who rents one or more virtual networks may want to
acquire some information from other tenants co-existed in the same acquire some information from other tenants co-existed in the same
data center. data center.
o Some persons who manipulate the activation, migration or o Some persons who manipulate the activation, migration or
deactivation of tenant's virtual machine. deactivation of tenant's virtual machine.
o Some persons who physically access to underlying network.
o Some persons who phyically access to underlying network. 4.1. Attacks on Control Plane
4.1. Attacks on Control Plane 1. Attack association between VM and VN: one of the
functionalities of ONV3 is to provide virtual network to multi-
tenants. ONV3 associates a virtual machine's NIC with corresponding
virtual network, and maintain that association as the VM is
activated, migrated or deactivated. The signaling information
between endpoint and access switch may be spoofed or altered. Thus
the association between VM and VN may be invalid if the signaling
is not properly protected.
1. Attack association between VM and VN: one of the functionalities 2. Attack the mapping of a virtual network: The mapping between
of ONV3 is to provide virtual network to multi-tenants. ONV3 the inner and outer addresses may be affected through altering the
associates a virtual machine's NIC with corresponding virtual mapping table.
network, and maintain that association as the VM is activated,
migrated or deactivated. The signalling information between
endpoint and access switch may be spoofed or altered. Thus the
association between VM and VN may be invalid if the signaling is
not properly protected.
2. Attack the mapping of a virtual network: The mapping between the
inter and outer addresses may be affected through altering the
mapping table.
3. Inject traffic: The comprised underlying network may inject
traffic into virtual network.
4. Attack live migration: An attacker may cause guest VMs to be live
migrated to the attacker's machine and gain full control over
guest VMs[VM-Migration].
5. Denial of Service attacks against endpoint by false resource
advertising: for live migration are initiated automatically to
distribute load across a number of servers, an attacker may
falsely advertise available resources via the control plane. By
pretending to have a large number of spare CPU cycles, that
attacker may be able to influence the control plane to migrate a
VM to a compromised endpoint.
4.2. Attacks on Data Plane 3. Inject traffic: The comprised underlying network may inject
traffic into virtual network.
1. Unauthorized snooping of data traffic: This is attack results in 4. Attack live migration: An attacker may cause guest VMs to be
leakage of sensitive information, an attacker can sniffer live migrated to the attacker's machine and gain full control over
information from the user packets and extract their content. guest VMs.
2. Modification of data traffic: An attacker may modify, insert or
delete data packets and impersonate them as legitimate ones.
3. Man-in-the-Middle attack on live migration of VM: When a virtual
machine is migrated from one endpoint to another, the VM may be
intercepted and modified in the middle of the migration.
5. Security Requirements 5. Denial of Service attacks against endpoint by false resource
advertising: for live migration initiated automatically to
distribute load across a number of servers, an attacker may falsely
advertise available resources via the control plane. By pretending
to have a large number of spare CPU cycles, that attacker may be
able to influence the control plane to migrate a VM to a
compromised endpoint.
4.2. Attacks on the Data Plane
1. Unauthorized snooping of data traffic: This is attack
results in leakage of sensitive information, attacker can sniffer
information from the user packets and extract their content.
NVO3 Security Framework
Expires Jan. 2013
2. Modification of data traffic: An attacker may modify, insert
or delete data packets and impersonate them as legitimate ones.
3. Man-in-the-Middle attack on live migration of VM: When a
virtual machine is migrated from one endpoint to another, the VM
may be intercepted and modified in the middle of the migration.
5. Security Requirements
This section describes security requirements for control plane and This section describes security requirements for control plane and
data plane of NVO3. data plane of NVO3.
5.1. Control Plane Security Requirements 5.1. Control Plane Security Requirements
1. The network infrastructure shall support mechanisms for 1. The network infrastructure shall support mechanisms for
authentication and integrity protection of the control plane. authentication and integrity protection of the control
(1)When a protocol is used for the service auto-provisioning/ plane. (1)When a protocol is used for the service auto-
discovery, the information from endpoint shall not be spoofed or provisioning/discovery, the information from endpoint shall
altered. (2)When a protocol is used to distribute address not be spoofed or altered. (2)When a protocol is used to
advertisement and tunneling information, the protocol shall distribute address advertisement and tunneling information,
provide integrity protection. (3)The protocol for tunnel the protocol shall provide integrity protection. (3)The
management shall provide integrity and authentication protection. protocol for tunnel management shall provide integrity and
2. NVEs shall assure the information in the mapping table is coming authentication protection.
from a trusted source. 2. NVEs shall assure the information in the mapping table is
3. The virtual network should prevent malformed traffic injection coming from a trusted source.
from underlying network, other virtual network, or endpoint. 3. The virtual network should prevent malformed traffic
injection from underlying network, other virtual network, or
endpoint.
5.2. Data Plane Security Requirements 5.2. Data Plane Security Requirements
1. The mapping function from the tenant to overlay shall be 1. The mapping function from the tenant to overlay shall be
protected. NVEs should verify VNID is not spoofed. protected. NVEs should verify VNID is not spoofed.
2. The data plane should protect VM's state against snooping and 2. The data plane should protect VM's state against snooping
tampering. and tampering.
3. IPsec can provide authentication, integrity and confidentiality 3. IPsec can be used to provide authentication, integrity and
protection. IPsec can be used to protect the data plane. confidentiality protection. IPsec can be used to protect
the data plane.
6. Acknowledgements 6. Security Considerations
NVO3 Security Framework
Expires Jan. 2013
We invite more feedbacks and contributors. This document discusses general security threats and requirements
for NVO3. Individual document may raise specific issues based on the
particular content and should address them in the individual
document.
7. IANA Considerations 7. IANA Considerations
IANA does not need to take any action for this draft. This document contains no new IANA considerations.
8. Security Considerations 8. Normative References
TODO 9. Informative References
9. References [Editors' note: All Network Virtualization with Layer 3 (NVO3)
Internet drafts or related ID(s) referenced in the following list
are currently work in progress individual drafts in their early
development stage, status and text are subject to change, more
reference may be added along with the development of the NVO3 WG.]
9.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.lasserre-nvo3-framework] [RFC4111] Fang, L., Fang, L., Ed., "Security Framework for
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
Rekhter, "Framework for DC Network Virtualization", July 2005.
draft-lasserre-nvo3-framework-02 (work in progress),
June 2012.
[I-D.kreeger-nvo3-overlay-cp] [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Black, D., Dutt, D., Kreeger, L., Sridhavan, M., and T. Networks", RFC 5920, July 2010.
Narten, "Network Virtualization Overlay Control Protocol
Requirements", draft-kreeger-nvo3-overlay-cp-00 (work in
progress), January 2012.
[I-D.bitar-lasserre-nvo3-dp-reqs] [opsec-efforts] Lonvick, C., and Spak, D., "Security Best Practices
Bitar, N., Lasserre, M., and F. Balus, "NVO3 Data Plane Efforts and Documents", IETF draft-ietf-opsec-efforts-18.txt, April
Requirements", draft-bitar-lasserre-nvo3-dp-reqs-00 (work 2012.
in progress), May 2012.
9.2. Informative References [VM-Migration] Oberheide, Jon., Cooke, Evan., and Farnam. Jahanian,
"Empirical Exploitation of Live Virtual Machine Migration", Feb
2011.
[VM-Migration] [I-D.narten-nvo3-overlay-problem-statement] Narten, T., Sridhavan,
Oberheide, Jon., Cooke, Evan., and Farnam. Jahanian, M., Dutt, D., Black, D., and L. Kreeger, "Problem Statement:
"Empirical Exploitation of Live Virtual Machine Overlays for Network Virtualization", draft-narten-nvo3-overlay-
Migration", Feb 2011. problem-statement-02 (work in progress), June 2012.
Authors' Addresses [I-D.fang-vpn4dc-problem-statement] Napierala M., Fang L., Cai,
Dennis, "IP-VPN Data Center Problem Statement and Requirements",
draft-fang-vpn4dc-problem-statement-01.txt, June 2012.
Yinxing Wei (editor) NVO3 Security Framework
Expires Jan. 2013
[I-D.lasserre-nvo3-framework] Lasserre, M., Balus, F., Morin, T.,
Bitar, N., and Y.Rekhter, "Framework for DC Network
Virtualization", draft-lasserre-nvo3-framework-03 (work in
progress), July 2012.
[I-D.kreeger-nvo3-overlay-cp] Black, D., Dutt, D., Kreeger, L.,
Sridhavan, M., and T. Narten, "Network Virtualization Overlay
Control Protocol Requirements", draft-kreeger-nvo3-overlay-cp-00
(work in progress), January 2012.
[I-D.bitar-lasserre-nvo3-dp-reqs] Bitar, N., Lasserre, M., and F.
Balus, "NVO3 Data Plane Requirements", draft-bitar-lasserre-nvo3-
dp-reqs-00 (work in progress), May 2012.
10. Author's Addresses
Yinxing Wei (Editor)
ZTE Corporation ZTE Corporation
No 68, Zijinghua Road No 68, Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Phone: +86 25 52872328 Phone: +86 25 52872328
Email: wei.yinxing@zte.com.cn Email: wei.yinxing@zte.com.cn
Luyuan Fang (Editor)
Cisco Systems, Inc.
111 Wood Ave. South
Iselin, NJ 08830
USA
Email: lufang@cisco.com
Shiwei Zhang Shiwei Zhang
ZTE Corporation ZTE Corporation
No 68, Zijinghua Road No 68, Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Phone: +86 25 52870100 Phone: +86 25 52870100
Email: zhang.shiwei@zte.com.cn Email: zhang.shiwei@zte.com.cn
 End of changes. 56 change blocks. 
211 lines changed or deleted 372 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/