> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
