Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

On 2019-07-16 15:06, Tom Herbert wrote:

> On Tue, Jul 16, 2019 at 2:44 PM Joe Touch <[e-mail]> wrote: 
> 
>> On 2019-07-16 14:37, Tom Herbert wrote:
>> 
>> On Tue, Jul 16, 2019 at 2:25 PM Joe Touch <[e-mail]> wrote:
>> 
>> ...
>> We CAN easily set a limit IF we went.
>> 
>> We don't need to design that into the protocol structure. And we don't need to start with something that already impacts things like fragmentation/reassembly, LITE, etc. where the final user data is inside the options area.
>> 
>> Additionally, the comparison to IP is misleading; these are endpoint options and should not have the same kinds of limits as per-hop.
> IPv6 has destination options for which limits are applied by Linux.

Linux is not an example of how to follow specs; if anything, it's THE
example to the contrary. 

>> Finally, the "realities of deployment" should not be designed or limited by what is currently available. UDP hasn't been updated in many decades; I hope we won't need to come back and re-do this in 5 years just because we're too focused on current technology.
> 
> Tell that to the IPv6 guys ;-) It has taken years to derive a
> deployable solution and that has included real world considerations
> like DOS. IMO, it is wise to learn from that experience.
> 
> Consider in the UDP options draft:
> 
> [NOTE: Tom Herbert suggested we declare "more than 3 consecutive
> NOPs" a fatal error to reduce the potential of using NOPs as a DOS
> attack, but IMO there are other equivalent ways (e.g., using
> RESERVED or other UNASSIGNED values) and the "no more than 3"
> creates its own DOS vulnerability)
> 
> Okay, so there is no limit to number of NOPs in a packet.

No, it's still under discussion. 

The problem is the cost of the limit creates its own DOS. 

> So per the
> draft we could full up an MTU or even a maximum size IP packet with
> NOPs. That's going to wreak havoc on a receiver and hence is a great
> DOS attack. If you don't believe, please run the experiment in your
> implemenation and see what happens to your CPU utilization.

Receivers can do whatever they want to check without us setting protocol
limits. 

A good implementation (of anything) checks resources and limits overuse.
Period. We should not need to set limits to make that happen. 

Besides, such limits *change over time and depend on a particular
system's resources* anyway. 

One size does not fit all for all time. 

Joe