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

[Tom Herbert <[e-mail]>]

On Thu, Feb 16, 2017 at 1:21 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 2/16/2017 1:14 PM, Tom Herbert wrote:
>> On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch <[e-mail]> wrote:
>>>
>>> On 2/16/2017 12:27 PM, Tom Herbert wrote:
>>>> The problems of TLVs, particularly that they are unordered, require
>>>> iterative processing,
>>> That's trivially avoided by forcing the order.
>>>
>>> As I noted before, all that is required for equivalently easy processing
>>> is that both TLVs and bitfields use only known variants in only known
>>> orders.
>>>
>> Joe, do you know of any protocols that enforce such an ordering?
>
> No, because in most cases the "T" is intended to allow arbitrary reordering.
>
I'd feel more comfortable with calling this a "trivial" solution for
TLVs if there was a working example of protocol that has implemented
it and had been successfully deployed.

> My point is just that it isn't TLV itself that affects hardware and
> parallelization; it's the potential for variation.
>
> The same variation and need for serial processing could be true for new
> definitions for previously undefined bitfields values. E.g., consider
> that the first few bits of an IP packet determine whether the addresses
> are 32 bits or 128 bits, etc.
>
Not in the same way. At question here is how the packet is parsed to
identify the protocol fields, not how individual fields are processed.
Since TLVs are unordered that means the number of discrete packet
header formats including extensions is combinatoric. Specifically, the
number of possible combinations is

SUM(K! * (N choose K)) == SUM(N! / (N-K)!) == N! * SUM(1 / K!), for K
= 0..N which approximates to e * N!.

For bit-fields the number of possible combinations is always 2^N (or
2^(N+1) to allow both plain IPv4 and IPv6)

The former function grows at a much steeper rate. For instance, with
just 8 extensions there are 109601 possible combinations of TLVs in a
packet. For bit-fields there are just 256. So without some constraints
applied to ordering, TLVs are not amenable to use with HW
parallelization techniques such as TCAM. If the problem is
unconstrained, HW processing degenerates to be iterative over the
packet (alignment and making TLVs same size don't help here). The
situation in SW is not particularly better, bit-fields processing can
be loop free, whereas TLVs will require a loop.

Susceptibility of the TLV protocol mechanism to DOS is demonstrated
when an attacker spoofs a packet containing the maximum number of
minimum sized TLVs. An attackers job is made easier if the protocol
allows TLVs that can be ignored. For instance, to attack Geneve they
could just create a list of random tiny "ignore" TLVs and set the
C-bit to ensure the receiver processes the TLVs. An obvious mitigation
to this might be to require mandatory options to appear before
ignorable options (that is introduce a weak ordering requirement).
With that the C-bit could be completely eliminated since it's just as
easy to check the type of the first option to see if mandatory options
are present. Also, if the receiver only processes mandatory options
then they know to stop processing when they hit the first
non-mandatory option. This might be sufficient defense against the DOS
attack I described, but then of course if everyone were to ignore
non-mandatory TLVs in this manner then we'd have to ask what the point
is of even including them in the protocol definition.

Admittedly, without any actual TLVs defined in Geneve all of this is
all just speculation on my part!

Tom