The new section "Constraints on Protocol Features" seems to be punting
the issues that were raised concerning processing of TLVs to a control
plane which itself is still TDB. This is not normative and if someone
were implementing a dataplane for Geneve today this provides no
practical guidance on how to make it interoperable.

Alternatively, to address the TLV processing concerns, I would suggest:

1) Eliminate non-critical options. This is the most likely source of
DOS attacks where an attacker just fills up a packet with tiny fake
options. The counter argument to this is that it's need to roll out
new features, but TBH I am am skeptical this is really use in the
datacenter for that. It's more typical we just configure the allowed
options on both sides or rely on negotiation to specify the known
options like we do in TCP.
2) Enforce an ordering on options as was discussed previously. Maybe
just require the TLVs to be ordered by type. This eliminates the
combinatorics of TLVs and since it would be a requirement on the
protocol the order is well known and should yield interoperable
implementations.

Tom



On Mon, Mar 13, 2017 at 2:55 PM,  <[email protected]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Virtualization Overlays of the IETF.
>
>         Title           : Geneve: Generic Network Virtualization Encapsulation
>         Authors         : Jesse Gross
>                           Ilango Ganga
>                           T. Sridhar
>         Filename        : draft-ietf-nvo3-geneve-04.txt
>         Pages           : 26
>         Date            : 2017-03-13
>
> Abstract:
>    Network virtualization involves the cooperation of devices with a
>    wide variety of capabilities such as software and hardware tunnel
>    endpoints, transit fabrics, and centralized control clusters.  As a
>    result of their role in tying together different elements in the
>    system, the requirements on tunnels are influenced by all of these
>    components.  Flexibility is therefore the most important aspect of a
>    tunnel protocol if it is to keep pace with the evolution of the
>    system.  This draft describes Geneve, a protocol designed to
>    recognize and accommodate these changing capabilities and needs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-nvo3-geneve-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-geneve-04
>
>
> 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/
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to