Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Ole Troan <[e-mail]>]

>>> And then IETF wonders why operators do not feel like time spent on
>>> providing their input to IETF WGs is well-spent.
>>> 
>>> What else can it be, on a real-world device, in today's Internet?
>> 
>> The failure of a device to run as advertised or the failure of an 
>> operation to select the an appropriate device.
> 
> This is where the "real-world" bit comes into play.
> 
>> Operators that want to conserve resources without cause are welcome
>> to run their routers inside glass boxes in museums.  Routers do
>> work. Packets cause that work. That work is not an attack unless
>> it is *disproportionate*. That is not shown for nearly any of the
>> cases in this document.
> 
> As people have explained in great detail, there's work that the routers
> are built to do, where the number of packets they can handle is nearly
> arbitrarily high.
> 
> Then there's packets that are seen as an exception, and handled in a
> not-as-powerful path.  Back then, when the Internet was new, these 
> exceptional packets were considered "something we'll handle when the 
> need arises", and it mostly worked.  Today, whenever anything is connected
> to the real Internet has a weakness, it will be abused.  Thus, these 
> packets will have to be rate-limited, up to the point of uselessness.  
> 
> Of course you can build a box that can do everything with the same 
> speed.  I would recommend to the reader to make himself familiar with
> current market realities, though, regarding "cost", "power consumption",
> "feasibility to build in time before the increase in bandwidth has them
> obsoleted again" and "willingness of customers to pay serious money for 
> their Internet access”.

While I agree with what you say here, this draft recommends the opposite.
It recommends that routers should do more work, not less.

Filtering out extension headers and options inside of extension headers, is not only costly, it also violates basic Internet Architecture principles.

Ole