On Thu, Feb 16, 2017 at 1:21 PM, Joe Touch <[email protected]> wrote: > > > On 2/16/2017 1:14 PM, Tom Herbert wrote: >> On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch <[email protected]> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
