Subject: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08

From: Tom Herbert <[email-masked]>
Date: Thu, 20 Apr 2017 10:14:42 -0700

Hi,

Here are some more comments on UDP options...

There are many possible error conditions that need to be considered
and for each of these the action to be taken by a receiver needs to be
specified. I highlighted some of these error conditions, there may be
more.

Is there a limit to the number of options, or size of option space?.
For instance, could someone send a 64K IP packet with 20 byte IP
header, 8 byte UDP header with zero length, and 65000 worth of
timestamp options or NOP (aka a DOS attack).

I suggest the following requirements to a reasonable limits:
* With the exception of NOP, no options can appear more than once
* Four or more more consecutive NOPs is not allowed
*  At the first instance of either of the above conditions the
violating options as well as any subsequent ones are ignored and not
processed

In LITE the UDP length needs to be restored to the original value
before handing packet to application.

>From the draft:

"When present, the option checksum SHOULD occur as early as possible,
preferably preceded by only NOP options for alignment and the LITE
option if present."

Ordering requirements options are in various places in the draft. It
might be clearer to consolidate all these requirements in one section.

What about options 9-127, I assume these are reserved in the draft also?

What is handling if an option with unknown kind is received?

What if an the length of an option is incorrect for the kind of received option?

Why doesn't OCS use the normal Internet checksum? Is this just to save
one byte in the options?

What if the length of an option would make that option go beyond IP length?

What is the action if ACS fails, same as OCS?

What is the action if AE fails to authenticate? If the action is same
as OCS it would be somewhat odd to me to accept a packet with a field
we failed to authenticate...

What if there is a checksum option but the kind has been corrupted
such that it no longer indicates a checksum? Should checksum always be
in a fixed header to avoid this case?

How would the UDP MSS option be used for path MTU discovery? Does this
expect that routers will be putting their MTU in the field?

What happens if a host receives a well formed FRAG option but has not
sent the initial one? 1) Is the packet accepted as a non-fragment, 2)
Is it reassembled? 3) Is the packet dropped? This can happen in the
NAT eviction scenario (see below).

>From the draft: "The reassembly checksum SHOULD be used, but MAY be
ignored in the same situations when the UDP checksum is ignored" --
this wording is imprecise. A non-zero UDP checksum is never ignored by
a receiver. It may be set to zero on transmit (no checksum) for
UDP/IPv4, but is required for UDP/IPv6 (except for an allowance with
tunnels described in RFC6935 and RFC6936). I'm pretty sure the draft
means that the fragmentation checksum may be set zero to indicate no
checksum. Also, it should be specified what the fragmentation checksum
covers. Presumably, it covers the reassembled UDP payload and the
checksum value in the option. Since there is no pseudo header, the
checksum can always safely be zero (like an IPv4 UDP checksum). In
practice, I doubt a fragmentation checksum would be used, we already
get the UDP checksum computation for free in NICs and the
fragmentation checksum would be mostly redundant to that and costly to
perform the calculation.

What is the normative requirement for using FRAG + LITE?

"UDP options MUST NOT follow the FRAG header in non-terminal
fragments." If a host receives a packet that violates this what is the
action to take?

>From the draft: "It has been reported that Alcatel-Lucent's "Brick"
Intrusion Detection System has a default configuration that interprets
inconsistencies between UDP Length and IP Length as an attack to be
reported. Note that other firewall systems, e.g., CheckPoint, use a
default "relaxed UDP length verification" to avoid falsely
interpreting this inconsistency as an attack."

It's subjective to say that inconsistency in lengths should not be
considered attack. I can easily imagine an DOS attack against
bandwidth in a network where tiny UDP packets are placed in full MTU
sized packets. Blocking packets with inconsistent lengths is a
reasonable mitigation. Maybe in addition the limits I suggested above,
there should also be a limit on IP_length - UDP_length as guidance to
firewall vendors. (maybe 40 bytes just to be consistent with TCP?)

NAT eviction might be challenging. Consider that in TCP, if a NAT
state is evicted the connection will be broken and both sides will
(eventually) close the connection. But with a UDP eviction, then next
time a packet behind the NAT sends a packet on the evicted flow the
NAT can create a new flow state. This new flow state may use different
source port or address than previous one. To the device behind the NAT
nothing has changed, it still uses the same tuple. But for it's peer
it now sees a completely new flow, if has no way of knowing about the
change. This is one reason that QUIC has a connection identifier to
keep its own persistence across a NAT state change. This might break
the option negotiation described in the draft. For instance, the
device behind the NAT might send a FRAG option since it had seen the
initial FRAG from the peer in its tuple, but the from the peer's point
of view it never sent the FRAG option on its tuple. To make matters
worse, if the peer lives behind an L4 load balancer (common) the new
flow may wind up on a completely different machine that might not even
support UDP options (for instance it happens to run an old OS).

>From the draft: "The UDP OCS provides protection against such events
and is stronger than a static "magic number"."

I don't understand why this would be true on two accounts:
1) OCS has very little entropy. It is only 8 bits and the whole option
size is 16 bits. A static magic number, like that considered for SPUD,
was at least 64 bits.
2) It's not required AFAICT

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Apr 2017 11:16:11 -0700

Hi, Tom,

> Is there a limit to the number of options, or size of option space?.
Only the size of the IP payload.

> * Four or more more consecutive NOPs is not allowed
It might be easier to say that NOPs should occur no more than 3 times
between other options.

> violating options as well as any subsequent ones are ignored and not
Sure.

> before handing packet to application.
I'm not sure what "original value" means.

If a user sends a UDP LITE-option message (whether by the UDP option
method or UDP-LITE), they are indicating two parts: checksummed and not.
Just like UDP-LITE, the UDP length field only ever indicates the amount
of data that is covered by the checksum. There's nothing to "restore".

The exception would be the LITE/FRAG case, which we do need to restore,
but it ought to be restored by reassembly already. I'll double-check
that and see if we need a special case for LITE+FRAG processing.

> might be clearer to consolidate all these requirements in one section.

Sure.

> What about options 9-127, I assume these are reserved in the draft also?
They'll be added as "unassigned". I'm not sure whether we really need to
reserve 128-253 (that was in case we wanted to try to use the high bit
as a flag, but I'm not sure that's a good idea).

> What is handling if an option with unknown kind is received?
Silently ignore - I'll add that text.

> What if an the length of an option is incorrect for the kind of received option?
Treat the packet as corrupt and silently drop. I'll add that too.

> Why doesn't OCS use the normal Internet checksum? Is this just to save
And keep things half-word aligned.

> What if the length of an option would make that option go beyond IP length?
Same thing as above - treat as corrupt and silently drop.

> What is the action if ACS fails, same as OCS?
Silently drop (possibly log in aggregate for diagnostics, though I would
suggest doing that only for checksum failures, not semantic errors as
above).

> we failed to authenticate...
A packet would have to pass all the authentications and checksums to pass.

AE works like AO, though - things silently pass until you turn it on for
a given socketpair. That's worth nothing explicitly in the AE section
and I'll add.

> such that it no longer indicates a checksum? 
Then it's not a checksum option anymore.

> Should checksum always be
The user can set the socketpair as "OCS required if options used" if
they want. IMO, that's a system configuration issue.

> How would the UDP MSS option be used for path MTU discovery?
The same way the TCP MSS option is - not at all. MSS indicates the max
receiver reassembly size.

>  Does this
Same as TCP MSS - no. This is information to be used on the return path
as a hint about reassembly limits.

> NAT eviction scenario (see below).
FRAG, like other soft-state options - must be confirm-before-use. That
means it would be silently dropped.

If NAT eviction is a concern, then we need to ensure that soft state is
refreshed. I can add that to the discussion of soft state.

> checksum.
Yes - that can be clarified.

>  Also, it should be specified what the fragmentation checksum
> checksum value in the option.

Coverage is already indicated in 5.8:

   ...the terminal FRAG option
   is indicated as a longer, 12-byte variant, which includes an
   Internet checksum over the reassembled payload (omitting the IP
   pseudoheader and UDP header, as well as UDP options)

No, it does not include the checksum value in the option (that's
recursive!).
> Since there is no pseudo header, the
The fragmentation reassembly checksum ensures that the reassembly is not
corrupt. No amount of component checksums ensures that.

I.e., FRAG might be a case where the UDP checksum of each FRAG is zero
but the FRAG checksum is used. I think that's better advice to users.
> What is the normative requirement for using FRAG + LITE?
Not sure what you mean... can you explain?

> fragments." If a host receives a packet that violates this what is the
Silently drop.

> considered attack.
No, it isn't. You can say that inconsistencies are errors, but the
Postel Principle says that anything allowed by the spec should be
accepted by the receiver. Inferring an attack from what could be
legitimate behavior is simply wrong.

> I can easily imagine an DOS attack against
> sized packets. 
Why on earth would anyone bother? Why not just send large packets -
wouldn't they create more damage?

> Blocking packets with inconsistent lengths is a
Please see draft-ietf-tcpm-tcp-edo. No, 40 bytes isn't enough and won't
be enough.

> support UDP options (for instance it happens to run an old OS).
That's a good reason for the soft-state to be refreshed - on both sides.

> size is 16 bits. A static magic number, like that considered for SPUD,
Magic numbers don't protect against errors except within the space of
the magic number itself.

> 2) It's not required AFAICT
We haven't decided that as a WG, but it is on the table.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 09:11:49 -0700

> Silently ignore - I'll add that text.
IMO, a protocol that includes optional data that must be sequentially
processed (parsed) but can otherwise be ignored is an invitation for a
DOS attack. All that an attacker needs to do is fill up a packet with
nothing but bogus options. Even with the rules above that would still
allow an attacker to fill an Ethernet MTU size packet with tiny UDP
options that will be ignored. The processing required to walk UDP
options could kill very well kill a server (e.g. a public DNS server
that happens to support UDP options). I know of two ways to avoid this
issue. Either don't allow options that can be ignored (as we do in
GUE) or artificially limit the amount of option space (as in IP
options). Since UDP options are intended to work on the Internet
without parameter negotiation, I tend to think limiting option space
is the right approach in this case.

> And keep things half-word aligned.
8-bit checksum is significantly weaker than 16-bit checksum, saving
just a couple bytes here does not seem like much of a win. Also, I'm
not sure half word alignment helps all that much. IP protocols tend to
maintain word alignment and we have exploited that fact in
implementation. There are still architectures that have issues with
misalignment of 32-bit words (e.g. Sparc). Sending a bunch of
misaligned options with 4-byte data fields could be another form of
DOS attack. To avoid these issues it may be better to require all
options to be a multiple of 4 bytes in size and have the options start
at a four byte offset relative to the UDP header.

> Then it's not a checksum option anymore.
But the purpose of the checksum is to protect the header against
corruption such that the data is not misinterpreted. In my example the
checksum has failed to do it's job. This is probably why checksums are
not in the options for UDP or TCP...

>    pseudoheader and UDP header, as well as UDP options)
A checksum over reassembled payload is going to be costly. We might be
able to use HW offload if we have the checksum computed over each
segment. But, if we use LITE option that presents another problem
since in that case we'd only get checksum offload over UDP header and
not much larger payload. I think that problem is solvable if there
were a checksum field in LITE option that optional covers the LITE
data. Assuming that NICs properly implement protocol agnostic checksum
offload if should be possible to compute and set the UDP checksum
(over hdr and pseudo headr) in the host CPU, and then arrange for
device to compute checksum of LITE data and set checksum field in
that. A receiver that gets checksum complete should be able to verify
and compute checksum over UDP header and LITE without significant
computation. If you have someone implementing this I could probably
help them with the implementation details.

> legitimate behavior is simply wrong.
Neither attackers nor firewalls adhere to the Postel principle.
Attackers are always trying to masquerade their attack as legitimate
behavior, and firewalls are trying to identify when they are doing
that. A consequence of this is that firewalls will sometimes drop
packets that match an attack profile but still might be legitimate.
Note that firewalls already routinely drop packets with EHs that they
don't understand; that is wrong per the Robustness principle, but
nevertheless a reality we need to deal with in protocol deployment on
the Internet.

> wouldn't they create more damage?

Because the surplus data may be transparent to a firewall and thus
could possibly be used to circumvent the firewall. This might not very
different from the way that ICMP data has been used as a trojan to
ship sensitive data out of a network. The danger is that if there is
an ever attack or event the perception of a security hole, then some
network operators could start blocking packets like this
indiscriminately. If that happens the wide-scale deployment of a
potentially useful feature like this might never happen. We've seen
this many times before (new EHs for instance). IMO the best way to
avoid is to provide reasonable limits and assume up front that
firewalls and other intermediate boxes will parse and make decisions
(that we may not always agree with) on any plain text in a packet.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 10:20:39 -0700

On 4/25/2017 9:11 AM, Tom Herbert wrote:
> DOS attack.
That's already true for TCP headers and for any extensible protocol that
allows new extensions to be ignored (including IPv4 and IPv6).

> All that an attacker needs to do is fill up a packet with
> options).
IPv4 options have limited space. IPv6 has no such limit because of
similar chaining.

However, you're ignoring the fact that critical servers could easily
decide that they would parse messages with unknown options only given
available capacity. We include text warning protocol designers to use
these options sparingly and note that servers MAY ignore any subset
(including all) options, as long as they do so consistently on a per
socketpair basis.

>  Since UDP options are intended to work on the Internet
We've been down this road too many times to think it will end well.
Whatever limit you put will need to be exceeded at some point, whether
it's a pure length limit or a limit on the number of options.

We can say that each option can occur only at most once (except for
NOP), which would limit the number of non-experimential options in a
given packet to roughly 250. But we can't limit the length of any option
- to do so undermines the use of the paired LITE/FRAG solution.

> just a couple bytes here does not seem like much of a win
We can debate and adjust that if/when this becomes a WG item.

> . Also, I'm
That's not how TCP, IPv4, or IPv6 options work, and it isn't how UDP
options should work either.

And it's not tenable for many of the proposed options (notably FRAG).

> not in the options for UDP or TCP...

There have been checksum options (and other integrity checks, such as
TCP MD5 and AO) for TCP.

However, what you're asking is like "how does a TCP checksum protect
against errors in the IP proto field?". It can't. If that field changes,
the packet isn't interpreted as TCP.
> A checksum over reassembled payload is going to be costly. 
It depends on where the reassembly happens. It can easily occur during
any copy (e.g., to user space) - nearly for free.

> We might be
> segment. 
That doesn't protect against reassembly errors.

> But, if we use LITE option that presents another problem
> data.
Most uses of LITE would never want it, and it won't help FRAG as per above.

>  Assuming that NICs properly implement protocol agnostic checksum
The checksum of the FRAG components could easily be done incrementally
(over each fragment) and summed later, accomplishing the same thing.

The only change would be that we would need to limit the fragments to
16-bit boundaries, which means making the offset 14 bits instead of 16.

> Neither attackers nor firewalls adhere to the Postel principle.
We don't care if they do.

> packets that match an attack profile but still might be legitimate.

A device that infers an attack from legitimate behavior has a false
positive, and I'd send that back and demand a refund.

However, it may be possible for such a device to drop those packets if
it can claim that even legitimate behavior is causing problems - but
then that's claiming that standards-compliant behavior can cause an
attack. That's always been true (e.g., SYN flooding).

> nevertheless a reality we need to deal with in protocol deployment on
It is pointless to design laws for the lawless.

The best we can do is design laws for those who follow them.

> could possibly be used to circumvent the firewall.
That's true for every area that is currently undefined.

Sure, if I'm running a highly secure facility, I allow only the
capabilities I know I support and need, and drop all others.

But again, that rule already applies to IPv4, IPv6, and TCP - and IPv6
in an unfettered way.

> This might not very
> ship sensitive data out of a network. 

Sure, and then that ends up breaking PMTUD to and from your own hosts.

> The danger is that if there is
> indiscriminately. 
They already block lots of things - e.g., some ISPs block email to force
you to use their web interfaces. Some hotel nets block VPN access.

That doesn't cause the IETF to deprecate these protocols.

> If that happens the wide-scale deployment of a

UDP options are a case where the operator decides what's reasonable, and
either helps or hurts their customers/clients.

The rest is for the market to decide.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 10:59:44 -0700

> decide that they would parse messages with unknown options only given

Servers would not know a priori which message contain unknown options
and which don't. To find out, they have to parse the options and
there's no guarantee that known options won't follow unknown ones so
they need to walk the whole list (that could be resolved by enforcing
order of options). The only relevant decision I currently see here is
whether a server is going to implement UDP options or not. If there's
another viable option then the rules for that should be specified in
the protocol, otherwise implementations will make their own rules to
address the DOS threat which quickly breaks interoperability.

> given packet to roughly 250. But we can't limit the length of any option

Please make sure that whoever implements this protocol tests the
analyzes this worst scenario for performance and susceptibility for
DOS attack. I'm pretty certain we will require this analysis before
ever accepting mechanism like this into Linux.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 11:09:29 -0700

Hi, Tom,

On 4/25/2017 10:59 AM, Tom Herbert wrote:
> ...
> and which don't.

Whatever rule you're thinking of (e.g., "only 100B of options", no more
than 3 unknown options, no unknown options, etc. ) is what they could
implement. We don't need to build that into the protocol.

> To find out, they have to parse the options and
> order of options). 
They either will see options they support (which is fine) or ones they
won't. If the limit how many unknown options they allow for that
connection or server, they should be just as fine as they would be if
the protocol forced that for everyone.
> The only relevant decision I currently see here is
So does limiting the option space. If we allow the space to be used as
endpoints see fit, we allow the endpoints to decide by mutual consent.
That's what transport protocols are for.

> ...
That is not uniquely required for this protocol.

>  I'm pretty certain we will require this analysis before

You're kidding, right? The OS that is the poster child for taking
everything? (you don't want to know how many errors we've already found
the TCP stack along these lines).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 11:29:13 -0700

> the TCP stack along these lines).
No, I'm not kidding. We are not going to blindly take protocol code
that has possible new DOS vector which is going to be deployed on
billions of devices! Really, testing this case is not rocket science.
(you don't want to know how many errors and inadequacies in standard
protocols we've already found because protocol developers failed to
test their protocol :-) ).

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 11:43:11 -0700

On 4/25/2017 11:29 AM, Tom Herbert wrote:
> billions of devices! 
You'll have to start by explaining all the code you've already taken,
some of which (e.g., TCP use of experimental ports) is prohibited by
existing RFCs.

> Really, testing this case is not rocket science.
Check out Linux processing of TCP option 253 and 254 and tell me you
have a leg to stand on.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 13:25:12 -0700

> Really, testing this case is not rocket science.
FWIW, I do agree that the doc does need some advice on how designers who
are concerned with potential vulnerabilities MAY or even SHOULD
constrain use of UDP options, e.g., enforcing some limits on how many
and how large options should be skipped over before "giving up".

AFAICT, we can decide the details by consensus once the doc is accepted
as a WG item, IMO.

However, I don't see a good reason to limit the mechanism by fiat any
more than IPv6 limits header chaining at the endpoint.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 13:50:34 -0700

> AFAICT, we can decide the details by consensus once the doc is accepted
That's reasonable, potential vulnerabilities should be discussed and
address in WG item.

> more than IPv6 limits header chaining at the endpoint.
I'm not sure IPv6 header chaining is a good example of successful
protocol extensibility. The limit issue with EH has come up on the
IPv6 lists before. IIRC, originally, there was no limit and that has
since been changed so that the EH chain must fit into one MTU. It
would certainly be an interesting experiment for some on to load up a
packet with a bunch of unknown options in an EH (DO maybe) to see what
the impact is. Fortunately, or unfortunately depending on your point
of view, many intermediate devices drop EH anyway so a DOS attack
using long list of IPv6 extension headers and options might not be
very effective.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 14:03:23 -0700

On 4/25/2017 1:50 PM, Tom Herbert wrote:
> IPv6 lists before. 
yes, but this is for a different set of reasons:

1) network relay devices (routers) have different capabilities than end
systems
2) it may not be possible to relay a message without having the context

But we should have different expectations of end system services, with a
very small set of exceptions (e.g., DNS is one). Ultimately, the OS
already has to limit how much it invests in processing messages for
different streams (no stream should be able to trigger the OS to hog
resources), and if that's true, then the only penalty is to the
individual connection.

Preventing DOS attacks at that point means rejecting load based on
utility; certainly connections that make progress, regardless of how
complex, should get priority over those that don't (regardless of how
simple). That's why I prefer advice that allows the implementer to
decide what progress means and how to shed load, rather than locking up
a protocol to ensure that.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 14:26:32 -0700

> resources), and if that's true, then the only penalty is to the
Syn attacks, attacks on UDP, or IP are all connectionless-- every
packet would have a random source address and port. These attack the
stack processing so as to cause collateral damage to unrelated flows.
There are attacks trying to hit a specific connection or flow queue
(like a tuple attack); for these we do have good mitigations to
isolate the bad traffic to some degree.

> a protocol to ensure that.

Consider, that some OS that could unilaterally define a limit on UDP
options that are processed in the receive path (say 40 bytes). The
draft seems to allow since it is a limit applied at the
implementator's discretion. If we were to happen to do this in Linux
then MS and IOS might follow. So essentially this limit becomes an ad
hoc standard for the protocol. Another implementation that attempts to
use more bytes than this limit is now interoperable. I don't think
this is your desired outcome.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 14:59:14 -0700

> isolate the bad traffic to some degree.
The impact of SYN floods - even across a set of ports  - on other
connections is mitigated by limiting the rate of processing SYNs.

The same rule can apply here - if option processing becomes overloaded,
then deprioritize packets that are causing the overload (with many
unknown options in long chains), e.g., by "giving up" on those earlier
(sort of like the circuit breaker approach for UDP flows in RFC8085).

> options that are processed in the receive path (say 40 bytes). 
It could do the same for TCP and limit the options to 10 bytes...

> The

That might be true, right up until we define a new, known option that is
100 bytes long. At that point, a box that understand the option isn't
constrained by boxes that don't. That *is* (at least partly) the desired
outcome.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 16:14:49 -0700

> It could do the same for TCP and limit the options to 10 bytes...

I don't think it could do this without violating the spec. This
definitely can't be done for IP options. Per RFC1122:

"All IP options (except NOP or END-OF-LIST) received in datagrams MUST
be passed to the transport layer (or to ICMP processing when the
datagram is an ICMP message).  The IP and transport layer MUST each
interpret those IP options that they understand and silently ignore
the others."

The requirements in RFC1122 for TCP options are not quite as precise,
but I think the spirit is that same: hosts are not permitted to ignore
known options which means all options up to the maximum limit must be
examined.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 16:21:40 -0700

On 4/25/2017 4:14 PM, Tom Herbert wrote:
> definitely can't be done for IP options.
But it is exactly what happens when we limit EHs in IPv6.

The net effect is the same - both are violations of the spec.

Never mind the fact that routers that drop fragments or packets with any
options are absolutely violating spec.

When a device is under overload, there are lots of things that can be
done. That's my point here - we might provide some guidance as to how
this can be done in general, but we shouldn't be forcing a hard limit on
the protocol design.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 17:33:26 -0700

> this can be done in general, but we shouldn't be forcing a hard limit on
FWIW, here's what the Christmas tree packet with IPv6 EH might look like.

IPv6 header: 40 bytes, next header is DO
DO header: 2 bytes. length is 181 (times 8 gives 1448), next header is UDP
160 * [ 7 * PAD1 (1 byte each), Ignored dest option (2 bytes) ]
2 * PAD1
UDP header with zero length

Each ignored dest option is some unknown type beginning with 00 to
indicate that the option if unknown is to be ignored. Linux only
support Home Address destination option so any type number less than
64 and greater than one should work for this. Length field is zero so
ignored option is two bytes.

This gives packet length of 1498 bytes and results in 1282 iterations
through the TLV parsing loop. If PAD1 is easier process than a TLV
with a length field then we could use those instead to have 724 two
byte destination options in the packet. Either way, this is a whole
bunch of conditionals, cache misses on the packet, and code that must
be done but results in no useful work. .i.e. unbounded lists of TLVs
that can be ignored are a DOS attack waiting to happen IMO. :-(

Tom