Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

[Tom Herbert <[e-mail]>]

> In the security section you provided text for, we talked about the
> possibility of authenticating the tunnel header and payload via extensions
> to address concern of spoofing VNI and payload security.

Please look at draft-herbert-gue-extensions, that draft realizes the
"possibility of authenticating the tunnel header and payload". These
extensions could, along with the others in that draft, be considered a
good set of fundamental extensions. They could be implemented as TLVs
in Geneve. One caveat though-- processing order of extensions is
important. For instance, it makes sense to authenticate the header
before decrypting the payload. Processing order in GUE is not an issue
since bit-fields allow random access at O(1). This is harder with
TLVs. Searching for one particular TLV is an O(N) operation for number
of TLVs in packet, searching for M of them becomes O(M * N). There are
known techniques to get the search back to O(N), but they tend to be
somewhat complex. One common method is to build a scoreboard in one
walk over the TLVs and then processing them in order from the
scoreboard-- this is how we implement options processing in TCP.

> If you think we need to beef the text more to discuss how C bit could help?
> Or how can we withstand DOS attack? Please suggest some text?
>
The problems of TLVs, particularly that they are unordered, require
iterative processing, and are susceptible to DOS are well known. I and
others have raised these issues as serious technical concerns of
Geneve several times for quite some time now (please look through all
the discussion in nvo3 list). Not only that, there are high profile
low level dataplane protocols that have included TLVs, notably IP
options and IPv6 EHs, for which TLVs have never achieved widespread
use. It's not like we don't want to use these, in fact just last week
we proposed some good use cases for HBH options in Facebook network,
but we also seem to get tripped up by some deployed devices that don't
handle them. If you look at the discussion on v6ops you'll see a
similar story, a lot of service providers disallow IPv6 EH because
they are a known DOS vector.

Answers to how to these problems have yet to be forthcoming. The
proposed answers usually seem to involve imposing ordering
requirements on TLVs, as the draft alludes to in the discussion of
using a control plane to enforce order. But that inevitably leads to
more complexity, more error handling, and in the case of this draft
creates dependencies of the dataplane on a control plane that has yet
to be defined.

> However, wouldn’t discussing a solution such as (1) defining TLV(s) and (2)
> Exact operational characteristics be out of scope of this draft?
>
This not about knowing exact operational characteristics for the
protocol, the problem is without any implementation at all we don't
know anything about how these protocol mechanisms will function or if
they are even feasible (except that we could try to extrapolate from
experiences with similar deployed protocols as I mentioned, but then
that doesn't seem to bode well for Geneve).


Tom