Internet DRAFT - draft-zu-nvo3-security-requirements
draft-zu-nvo3-security-requirements
Network Working Group Z. Qiang
Internet Draft A. Kavanagh
Intended status: Informational Ericsson
Expires: April 21, 2014 October 21, 2013
Security Requirements of NVO3
draft-zu-nvo3-security-requirements-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 21, 2014.
Z. Qiang Expires April 21, 2014 [Page 1]
Internet-Draft Security Requirements of NVO3 October 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This draft discusses the security requirements and several issues
which need to be considered in securing a NVO3 network architecture
based virtualized data center network for multiple tenants. In
addition, the draft also discusses issues that could be addressed or
mitigated.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Security Risk..................................................3
5. Security Control...............................................4
5.1. Control Plane Protection..................................4
5.1.1. Control Plane Availability...........................4
5.1.2. NVA-NVE Control Plane................................5
5.1.3. NVE-NVE Control Plane................................8
5.1.4. Hypervisor-to-NVE Control Plane......................9
5.2. Data Plane Protection....................................10
5.2.1. Security Policies on Tenant Traffic.................10
5.2.2. Protect the Overlay Tunnel..........................11
5.2.3. Protect the Tenant Traffic..........................12
5.3. Operation and Management.................................13
5.4. Logging..................................................13
5.5. Scalability..............................................13
5.6. Extensibility............................................13
6. Security Considerations.......................................14
7. IANA Considerations...........................................14
8. References....................................................14
Z. Qiang Expires April 21, 2014 [Page 2]
Internet-Draft Security Requirements of NVO3 October 2013
8.1. Normative References.....................................14
8.2. Informative References...................................14
9. Acknowledgments...............................................15
1. Introduction
Security is the key issue which needs to be considered in the design
of a data center network. This document first highlights the
security risks that a NVO3 network may encounter, and documents the
lists the security requirements that a NVO3 network should fulfill.
The purpose of the draft is to propose additional NVO3 network
security requirement considerations which can be incorporated into
the WG security requirement draft.
Note, it is not the intention to replace the Security Considerations
section in each NVO3 draft by this document. This document provides
the high level views of the security requirements when NVO3 network
is developed. It only lists the architecture level security
requirements which can be used as inputs at the design phase of the
NVO3 network architecture, control plane and data plane. Each NVO3
drafts must have its security considerations which shall define the
detail security solutions of a specific architecture and / or
protocol. This document is only the input document when the Security
Considerations section in each NVO3 draft is discussed.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
This document uses the same terminology as found in the NVO3
Framework document [I-D.ietf-nvo3-framework] and [I-D.kreeger-nvo3-
hypervisor-nve-cp].
4. Security Risk
Overlay infrastructure increases security risks and introduces new
threats. In a NVO3 network, there are security risks that the attack
made on the underlying network, including the NVO3 control
protocols, may be initiated from an exposed overlay virtual network;
Z. Qiang Expires April 21, 2014 [Page 3]
Internet-Draft Security Requirements of NVO3 October 2013
or the attack made on the encapsulated virtual networks may be
initiated from the underlying network or a compromised overlay
virtual network.
In a perfect world, virtualization is considered secure with no
level of privilege within the virtualized guest environment that
permits interference with the host system. There are really not much
security issues if a tenant network is isolated as it is designed.
In practice, there are occasional misconfigurations and/or security
vulnerabilities that allow an attacker to circumvent these
protections and gain access to other virtual machines, or even worse
the underlay network. While the misconfigurations or vulnerabilities
are pretty rare, they do exist.
In NVO3 network, both the hypervisor and the NVE module is just a
piece of software. Any software is vulnerable to a local privilege
escalation attack. The vulnerability may be exploited for local
privilege escalation or a guest-to-host virtual machine escape. So
both hypervisor and NVE may be compromised due to any
misconfigurations or software vulnerabilities. When the hypervisor
and the NVE are compromised by the attacker, the NVO3 network and
the underlay network architecture may be exposed to the attacker.
5. Security Control
5.1. Control Plane Protection
The DC service provider has the responsibility to protect the NVO3
control plane signaling against any attack.
5.1.1. Control Plane Availability
In a NVO3 network, the control plane is used to control the overlay
data plane tunnels for the VNs. It must be available when it is
needed. This means that the NVO3 control plane network components
and the control plane interfaces must be functioning correctly and
preventing any denial-of-service attacks.
R1. At NVO3 network design, any NVO3 network components, including
NVA and NVE, SHALL not become the bottleneck of the control
plane traffic. This is to avoid any DoS/DDoS attacks and to
provide control plane availability.
Z. Qiang Expires April 21, 2014 [Page 4]
Internet-Draft Security Requirements of NVO3 October 2013
R2. The control plane design SHALL minimize the amplification
effects which have the potential to be used by attackers to
carry out reflection attacks. For instance, the usage of the
NVE broadcast address MUST be avoided or restricted in the
control plane protocol. And the NVE MUST discard any control
plane traffic received from any non-participating NVEs or
unknown network addresses. This can minimize the amplification
effects which a compromised NVE or a compromised network
component to initiate a distributed reflection DoS attack by
sending request message to the broadcast address of the NVEs,
where the NVEs are exploited to act as reflectors of the
amplification attacks.
R3. Some overlay data plane tunnel protocols may use endpoint
addresses which is algorithmically derived from some known
values. These addresses are structured, and the fields
contained in them can be fairly predictable. If the control
plane and data plane are sharing the same address space, it
reduces the search space for an attacker and reduces the
resistance of the address in scanning attacks. Therefore the
NVE SHOULD have separated address space for data plane tunnel
end point and control plane traffic in order to minimize
security exposure of the control plane addresses, as
recommended in [RFC6169].
5.1.2. NVA-NVE Control Plane
In [I-D.ietf-nvo3-arch], two different possibilities are allowed for
VN context configuration and inner-outer address mapping table
updating at VN connection / disconnection or vNIC association /
disassociation:
- NVA Configuration only; or
- With Hypervisor/NVE Notifications
With the "NVA Configuration only" approach, the hypervisor is always
configured by the VM Orchestration Systems. It is assumed that
either the NVA is collocated with the VM Orchestration Systems, or
there is an interface between the VM Orchestration Systems and NVA,
which the NVA learns the VN connection / disconnection and vNIC
association / disassociation from the VM Orchestration Systems. Then
the NVA configures the attached NVE with the VN context of the
connected / disconnected VN and the associated / disassociated vNIC
addresses. The next step is that the NVA updates the inner-outer
address mapping table of the VN at both the attached NVE and all the
participating remote NVEs.
Z. Qiang Expires April 21, 2014 [Page 5]
Internet-Draft Security Requirements of NVO3 October 2013
With the "With Hypervisor/NVE Notifications" approach, the
hypervisor is always configured by the VM Orchestration Systems. The
attached NVE is informed by the hypervisor using the Hypervisor-NVE
protocol at VN connection / disconnection and vNIC association /
disassociation. Then the attached NVE notifies the NVA with the
received VN updating information. The next step is that the NVA
updates the inner-outer address mapping table of the VN at both the
attached NVE and all the participating remote NVEs.
In both above approaches, the NVA is the network entity that
provides reachability and forwarding information to all
participating NVEs. The NVA is the center control point of the NVO3
control plane network. If the NVA is compromised, the entire NVO3
control plane can be damaged. Therefore it is very important to
protect the NVA from any possible attacks.
Comparing the above two approaches, the "With Hypervisor/NVE
Notifications" approach may have additional security risks. The
updating of the inner-outer address mapping table of the VN at the
attached NVE and all the participating remote NVEs is triggered by
the VN updating notifications received from the hypervisor, at VN
connection / disconnection and vNIC association / disassociation. In
both the split-NVE case and the NVE collocated with the hypervisor
case, the updating of the inner-outer address mapping table may be
triggered by incorrect VN updating information received from a
compromised hypervisor or a compromised NVE. And it is difficult to
detect it and prevent it, unless an additional validation procedure
is supported in the NVA.
With the "NVA Configuration only" approach, the updating of the
inner-outer address mapping table at the attached NVE and all the
participating remote NVEs is triggered by the VN updating
information learned from the VM Orchestration Systems. In such
circumstance, a compromised hypervisor or a compromised NVE has
limited security risks on the NVO3 control plane. For instance, the
compromised NVE may send error notifications with incorrect error
information to the NVA, which may trigger the error-handling
procedure. But it should not trigger the inner-outer address mapping
table updating procedure. Once the compromise is detected, the NVA
may have the possibilities to mitigate security damages by informing
the VM Orchestration Systems to relocate the attached VNs from the
compromised NVE to other NVEs.
In both above approaches, there are other security risks in the NVA-
NVE control plane which need to be avoided.
For instance, if the control plane traffic between the NVA and the
NVE has been intercepted or modified, a compromised network
component may attempt to learn the NVO3 network topologic in order
Z. Qiang Expires April 21, 2014 [Page 6]
Internet-Draft Security Requirements of NVO3 October 2013
to initiate an attack. Or a compromised network component may try to
redirect the NVA-NVE traffic as a man in middle. If the control
plane traffic between the NVA and the NVE has been redirected, the
NVEs may not be updated correctly and timely at VN connection /
disconnection or vNIC association / disassociation. And the NVA may
not be able to receive any VN updating or error notifications from
the NVEs.
Another security risk is that a compromised network component may
try to impersonate as a NVA to update the NVEs with incorrect VN
configuration. Or a compromised network component may try to
impersonate as a NVE to notify the NVA with incorrect VN updating or
error information. In those circumstances, the VN traffic may be
redirected to a desired network point, or the data plane
connectivity of a VN may be disabled by removing / redefining the
overlay tunnel end point.
R4. At the NVA-NVE control plane, authentication and authorization
of the NVA MUST be supported to prevent a compromised network
component for impersonating as a NVA when communicate with
NVEs, using incorrect VN updating information, e.g. an untrue
inner outer address mapping table updating.
R5. At the NVA-NVE control plane, ingress filtering SHOULD be
supported at the NVA. Any control plane traffic received from
any unknown addresses MUST be discarded without processing.
This is to prevent a compromised network component for
impersonating as a NVE when communicate with the NVA using
untrue network updating information or error notifications.
R6. At the NVA-NVE control plane, with the "With Hypervisor/NVE
Notifications" approach, authentication of the NVE MUST be
supported, otherwise it MAY be supported to prevent a
compromised network component for impersonating as a NVE using
a snooped NVE address as source address when communicate with
the NVA with untrue network updating information or error
notifications.
R7. The NVA-NVE control plane protocol MUST be protected with
integrity and confidentiality against any off-path or on-path
attacks. This is to avoid the NVA-NVE control plane messages to
be intercepted or modified by a compromised network component,
which may attempt to learn the NVO3 network topologic in order
to initiate an attack.
Z. Qiang Expires April 21, 2014 [Page 7]
Internet-Draft Security Requirements of NVO3 October 2013
5.1.3. NVE-NVE Control Plane
Besides the approaches described in the previous section, it is also
possible to use a NVE-NVE control plane protocol to update the peer
NVEs' inner-outer address mapping table timely at VN connection /
disconnection or vNIC association / disassociation. However, this
approach may require the NVE-NVE control plane packets to be flooded
to all NVEs when no mapping exists, which may have additional
security risks compare to other approaches described in the previous
section.
For instance, a compromised network component may attempt to learn
the NVO3 network topologic by intercepting any NVE-NVE control plane
messages. It may also try to modify the NVE-NVE control plane
messages in order to redirect the control plane traffic to a desired
network point. Or it may impersonate as a NVE using a snooped
participating NVE address to update the peer NVEs' inner outer
address mapping table of the VN in order to redirect the VN traffic.
Moreover, if a NVE is compromised, it may attempt to send control
plane messages to update the peer NVEs with untrue network updating
information. In this circumstance, the VN traffic may be redirected
to a desired network point.
Furthermore, a compromised network component or a compromised NVE
may try to initiate DOS attack by flooding all NVEs with untrue
network updating information. If the NVE-NVE control plane protocol
requires a respond, all the NVEs are exploited to act as reflectors
of the amplification attacks. When the number of involved NVEs is
large enough, it can slow down the NVE-NVE control plane to the
point of impossible to work on.
Especially when a NVE is compromised, it is very difficult to detect
it and mitigate the damage without additional security mechanism.
Therefore it is very important to protect the NVE-NVE control plane
from any possible attacks initiated from a compromised network
component or a compromised NVE.
R8. At the NVE-NVE control plane, authentication of the NVE MUST be
supported to prevent a compromised network component for
impersonating as a NVE when communicate with other NVEs.
R9. The NVE SHOULD apply ingress controls at the NVE-NVE interface
to filter the incoming control plane traffic and discard any
control plane traffic received from non-participating NVEs
without processing. This can prevent a compromised NVE sending
any control plane messages which it is not supposed to send.
Z. Qiang Expires April 21, 2014 [Page 8]
Internet-Draft Security Requirements of NVO3 October 2013
R10. The NVE-NVE control plane protocol MUST be protected with
integrity and confidentiality against any off-path or on-path
attacks.
R11. If the Inter-DC control plane traffic is crossing Public
Internet, it MUST be protected by one or more security
solutions to provide confidentiality, integrity and
availability. This is to avoid the crossing DC NVE-NVE control
plane messages to be intercepted or modified by an attacker
from the public internet.
5.1.4. Hypervisor-to-NVE Control Plane
In [I-D.ietf-nvo3-arch], two different possibilities are allowed for
NVE implementations: "Collocated with Hypervisor" or "Split-NVE".
The Hypervisor-to-NVE control plane protocol is only needed at the
"With Hypervisor/NVE Notifications" approach and the "Split-NVE" use
case. It is used by the hypervisor to update the attached NVE at VN
connection / disconnection and vNIC association / disassociation.
When the NVE is collocated with the hypervisor, there are additional
security risks if the hypervisor may be compromised. As the NVE's
configuration including the security keys may be exposed to the
attacker, the security damages could be multiplied to other NVO3
control plane in some control plane approaches, e.g. using NVE-NVE
for inner-outer address mapping table updates. And it is difficult
to detect and prevent it.
In the Split-NVE case, there are security risks that the NVE may be
polluted by a compromised hypervisor with incorrect network updating
information. However in this circumstance, the security damages can
be limited to the hypervisor and the VNs attached to the compromised
hypervisor. There are still ways to protect the attached NVE itself
and mitigate the damages.
Therefore, when Hypervisor-to-NVE control plane protocol is used, it
is very important to protect the Hypervisor-NVE control plane from
any possible attacks initiated from a compromised hypervisor.
R12. At the Hypervisor-to-NVE control plane protocol, authentication
of the hypervisor SHOULD be provided to prevent a compromised
hypervisor for impersonating as another hypervisor when
communicate with the attached NVE.
R13. The Hypervisor-to-NVE control plane protocol MAY be protected
with integrity to avoid the Hypervisor-to-NVE control plane
messages to be intercepted and modified by a compromised
hypervisor attached to the same NVE.
Z. Qiang Expires April 21, 2014 [Page 9]
Internet-Draft Security Requirements of NVO3 October 2013
5.2. Data Plane Protection
Data plane protection is the primary concern for a NVO3 network. And
it depends on the control plane security described at previous
section.
5.2.1. Security Policies on Tenant Traffic
In a NVO3 network data plane, the overlay network could be exploited
to act as reflectors of the amplification attacks, which can be used
to initiate DDOS / DOS attack on some network services provided by
the NVO3 architecture.
For instance, a compromised tenant system may try to send a
broadcast message to all the VMs in a VN with an intended victim's
spoofed source IP address. The victim could be one of the NVO3
network services, e.g. a L3NVE where the layer 3 routing or
forwarding function of the VN is provided. Most VMs on the VN, by
the default, may respond by sending a reply to the source IP
address. If the number of VMs on the VN to be involved is large
enough, the victim will be flooded. This can slow down the NVO3
network service to the point where it becomes impossible to work on.
Therefore it is important to apply proper security policies on the
received VN data traffic before forwarding it to the next hop, e.g.
an embedded firewall function in the NVE. Any disallowed data
traffic shall be filtered and discarded at an early point.
R14. The NVO3 infrastructure SHOULD support VN based security policy
management, i.e. security policy defined with a granularity
down to VN ID. Additional granularity MAY be supported.
R15. When the security policy management is enabled for the data
packets of a VN, the security policies MUST be applied on the
un-tunneled data packets.
R16. When the security policy management is enabled for the data
packets of a VN, the same security policies MUST be applied on
the VN data traffic during and after VM mobility. The VM shall
have the same security policies wherever it has been migrated.
R17. When the security policy management is enabled for the data
packets of a VN, the security policies MUST be applied on the
inter-VN traffic. This is to avoid a compromised VM trying to
involve more VMs which belong to other VNs in amplification
attacks.
Z. Qiang Expires April 21, 2014 [Page 10]
Internet-Draft Security Requirements of NVO3 October 2013
R18. When Public Internet connectivity is allowed for a VN, it is
often that some layer 3 network services may be provided by the
NVO3 network, such as NAT. This opening created in the layer 3
network services increases its Internet attack surface area. If
vulnerabilities are present, this increased exposure can be
used by attackers and their programs. Therefore the security
policies MUST be applied on the VN Public Internet traffic
before forwarding between the VN and Internet. This is to
ensure that IP traffic from the public Internet cannot be used
to modify the configuration of the VMs, or to mount DoS attacks
on them.
R19. The NVE SHOULD apply security policies on the data packets
received from the End Devices before encapsulation. Any
disallowed traffic MUST be discarded.
R20. The NVE SHOULD apply security policies on the data packets
received from the remote NVEs after de-capsulation, and discard
any disallowed data packets before forwarding to the End
Devices.
5.2.2. Protect the Overlay Tunnel
In a NVO3 network, a compromised network component may impersonate
as a NVE to send data traffic of a VN which it is not supposed to
send. When impersonating as a NVE, the compromised network component
may use a snooped NVE address as the overlay tunnel source point to
skip the ingress filter control at the peer NVE. In this case, per-
tunnel based signatures or digests may provide data origin
authentication, non-repudiation, and integrity protection. However,
in a larger DC, which may have millions of VNs and thousands of
NVEs, the key management scalability can be a concern. Besides, if a
NVE has been compromised, it is difficult to prevent the compromised
NVE from sending data traffic which it is not supposed to send. Even
with a per-VN based key, it is not guaranteed that a NVE will have
the key deleted after a VN is migrated into other NVEs. In that
circumstance, a compromised NVE may use the un-deleted key for
generating data traffic of a VN which is not attached to it any
more.
To avoid that, NVE authentication and ingress control on both the
inner address and outer address of an encapsulation tunnel is
important. The ingress control can mitigate the security damage
within a smaller amount of NVEs, i.e. the participating NVEs.
Z. Qiang Expires April 21, 2014 [Page 11]
Internet-Draft Security Requirements of NVO3 October 2013
R21. The NVE SHOULD filter on the outer source address of the
tunneled data packets received from the remote NVEs, and
discard any data packets received from any non-participating
NVEs or unknown address. This is to prevent a compromised NVE
or a compromised network component from sending data traffic of
a VN which it is not attached to it.
R22. The NVE SHOULD filter on the inner source address of the
tunneled data packets received from a remote participating NVE,
and discard any data packets which the participating NVE is not
supposed to send. In the case that a participating NVE is
compromised, this can prevent the compromised NVE from sending
data traffic of a VN which it is not attached to it.
R23. The digital signature MAY be supported in the NVE to prevent a
compromised network component for impersonating as a NVE when
generating tunneled data traffic of a VN using a snooped NVE
address as the overlay tunnel source point. It also can reduce
the risks of a man in middle attack.
R24. When Layer 3 routing/forwarding service is supported for a VN,
the NVE SHOULD discard any tunneled IP packets that specify
additional routing, as recommended in [RFC6169], though it may
be allowed for the End Device to configure what source-routing
types are allowed.
R25. Additional security mechanisms MAY be supported on the
interworking function when supporting multiple encapsulation
formats in a NVO3 network.
5.2.3. Protect the Tenant Traffic
In a NVO3 network, if the tenant traffic privacy is the concern,
cryptographic measures must be applied in addition. Confidentiality
and integrity on the tenant data plane traffic could avoid the
tenant traffic to be redirected, intercepted or modified by a
compromised underlay network component.
R26. All data plane packets MAY be protected in transit with
confidentiality and integrity, including the un-tunneled
traffic between the End devices and the NVEs, and the tunneled
traffic between the NVEs.
R27. If the inter-DC data plane traffic is crossing Public Internet,
it SHOULD be protected by one or more security solutions to
provide confidentiality, integrity and availability.
Z. Qiang Expires April 21, 2014 [Page 12]
Internet-Draft Security Requirements of NVO3 October 2013
5.3. Operation and Management
The Operation and Management data protection is also the concern for
a NVO3 network.
R28. The NVO3 Operation and Management traffic MUST be isolated from
any other underlay traffic in order to minimize security
exposure of the Operation and Management traffic, and mitigate
any damage due to an attack, as recommended in [RFC6169].
R29. The NVO3 Operation and Management data MUST be protected with
confidentiality, integrity and availability while in transit.
5.4. Logging
Logging function is very important at network security risks
detection.
R30. All NVO3 network components, e.g. NVA and NVE, SHOULD support
collection of security logs and sending them to a centralized
logging service.
R31. A centralized security logging and audit handling mechanism
SHOULD be supported. Any access to the NVO3 resources SHOULD be
recorded and stored in the centralized logging and audit
storage.
5.5. Scalability
Scalability is a big concern in NVO3 network especially where a DC
may have large amounts of VNs.
One example is that some security solutions may require a per-VN
based key management. In a large data center, where the number of
VNs can be huge, even there is no technology issue when generating
that amount of security keys, but it may be a scalability issue at
security credential management. Therefore optimized security
credential management solution shall be allowed.
R32. The NVO3 network security solutions SHOULD minimize the impact
on scalability and allow for simple configuration, e.g. shared
security credential management.
5.6. Extensibility
R33. The NVO3 network security solution SHOULD be extensible to
allow new security functionality to be introduced in the
future.
Z. Qiang Expires April 21, 2014 [Page 13]
Internet-Draft Security Requirements of NVO3 October 2013
R34. The NVO3 network security solution SHOULD be defined such that
End Devices existing security solution can be supported without
implementation impacts.
6. Security Considerations
This is a requirement document for the NVO3 network security and in
itself does not introduce any new security concerns.
7. IANA Considerations
No actions are required from IANA for this informational document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC6169] S. Krishnan, D. Thaler, J. Hoagland, "Security Concerns
with IP Tunneling", RFC 6169, April 2011.
8.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[I-D.ietf-nvo3-overlay-problem-statement] Narten, T., Gray, E.,
Black, D., Fang, L., Kreeger, L., and M. Napierala,
"Problem Statement: Overlays for Network Virtualization",
draft-ietf-nvo3-overlay-problem-statement-03 (work in
progress), May 2013.
[I-D.kreeger-nvo3-hypervisor-nve-cp] Kreeger, L., Narten, T., and D.
Black, "Network Virtualization Hypervisor-to-NVE Overlay
Control Protocol Requirements", draft-kreeger-nvo3-
hypervisor-nve-cp-01 (work in progress), February 2013.
[I-D.ietf-nvo3-framework] Lasserre, M., Balus, F., Morin, T., Bitar,
N., and Y. Rekhter, "Framework for DC Network
Virtualization", draft-ietf-nvo3-framework-03 (work in
progress), July 2013.
Z. Qiang Expires April 21, 2014 [Page 14]
Internet-Draft Security Requirements of NVO3 October 2013
[I-D.ietf-nvo3-arch] D. Black, J. Hudson, L. Kreeger, M. Lasserre,
T. Narten, "An Architecture for Overlay Networks (NVO3)",
draft-narten-nvo3-arch-00 (work in progress), July 2013.
9. Acknowledgments
Many people have contributed to the development of this document and
many more will probably do so before we are done with it. While we
cannot thank all contributors, some have played an especially
prominent role. The following have provided essential input: Suresh
Krishnan, David Allan I, Makan Pourzandi, Melinda Shore.
Authors' Addresses
Zu Qiang
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x47370
Email: Zu.Qiang@ericsson.com
Alan Kavanagh
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: alan.kavanagh@ericsson.com
Z. Qiang Expires April 21, 2014 [Page 15]
