Subject: [nvo3] I-D Action: draft-ietf-nvo3-dataplane-requirements-03.txt

From: [email-masked]
Date: Tue, 15 Apr 2014 06:57:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Virtualization Overlays Working Group of the IETF.

        Title           : NVO3 Data Plane Requirements
        Authors         : Nabil Bitar
                          Marc Lasserre
                          Florin Balus
                          Thomas Morin
                          Lizhong Jin
                          Bhumip Khasnabish
	Filename        : draft-ietf-nvo3-dataplane-requirements-03.txt
	Pages           : 18
	Date            : 2014-04-15

Abstract:
       Several IETF drafts relate to the use of overlay networks to support
       large scale virtual data centers. This draft provides a list of data
       plane requirements for Network Virtualization over L3 (NVO3) that
       have to be addressed in solutions documents.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-dataplane-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nvo3-dataplane-requirements-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-dataplane-requirements-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Apr 2014 11:30:58 -0700

Hi, here are some comments on NVO3 Data Plane Requirements:

- Data Path Overview

    - I think there should be description of visibility of network
virtualization between NVE's. It seems reasonable that the network may
parse fields in the encapsulation for purpose of filtering and
routing, however I think it might be a MUST that the network should
not modify the encapsulation header or encapsulated packet. In the
case that the encapsulation header is authenticated (see security
comments below) this wouldn't even be possible.
  - Support for NAT inevitably comes up in discussions about
tunneling. It would be nice to have some requirements or
non-requirements about interoperability with NAT.

- Under "Virtual Network Context Identification"

    -  What are are global and local identifiers, do these have formal
definitions? Are global identifiers meant to be globally assigned
numbers?
    - "this field MUST be large enough to scale to 100's of thousands
of virtual networks". This is a vague requirement. We need to account
for hierarchical allocation, identifier classes (like trusted vs.
non-trusted), and multiple network assignments to customers. For a
large deployment, we really need to be able to scale into the millions
of identifiers and fragmentation is inevitable. Also, we may want to
obfuscate identifiers or rotate them for a tenant for security
purposes. I really hope we can get at least 32 bit identifiers...

- Security

    - Considerations for the dataplane seems very lacking in this
document. In reality, security is probably the biggest issue we face
in deploying network virtualization. When we allow third party VMs to
running within the network every we must assume these are untrusted
and present a new security risk. We now regularly have attacks
originating from within our own networks!
    - It should be a MUST to protect the virtual network context
identification against corruption. Sending a packet to the wrong VM is
a fundamental violation of the isolation requirement. Minimally, this
as least this should be covered by a checksum (e.g. UDP), but a
stronger mechanism like CRC should be encouraged. Also, there should
be an even stronger mechanism to authenticate the identifier.
    - It should also be a MUST to allow  packet security to work with
the dataplane. The simplistic answer in some drafts seems to use IPsec
(e.g. AH, ESP) on the encapsulated packet, however that likely hides
the encapsulation layer from the network. The dataplane should allow
both strong packet level security but also allow for encapsulation to
be visible to network (this would be important for instance if we need
to physically partition traffic of different tenants).

- Data Plane Optimizations

    - "Data plane forwarding and encapsulation choices SHOULD consider
the limitation of possible NVE implementations, specifically in
software based implementation" I'm not sure what the point of this
requirement is. Is this another way of saying that the dataplane
protocols must not be HW specific?
    - "The NV03 encapsulation/decapsulation processing in
software-based NVEs SHOULD make use of hardware assist provided by
NICs..." This is vague and could really use more detail, however it
will be important to provide clear guidenace so HW vendors and SW
implementation is on the same page. Does this requirement refer to
existing hardware assist techniques which might be generic enough, or
to new HW implementation which can support specific protocols? For
instance, most NICs currently support the common offloads of RX and TX
checksum, LRO, TSO, and RSS. A dataplane protocol could be designed to
leverage RX checksum (CHECKSUM_COMPLETE) and RSS (via UDP encap)
without any additional support. TX checksum should work as is if there
is only one checksum in the packet, extending to support two is
already done in some NICs. TSO and LRO are a little harder to make
generic, however there are things that can be done in protocol design
to allow feasibility (like don't use per packet information such as
checksums or sequence numbers in the encapsulation).

Thanks,
Tom

On Tue, Apr 15, 2014 at 6:57 AM,  <[email-masked]> wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3