Re: Re: Fast Address Validation - about

[Töma Gavrichenkov <[e-mail]>]

On Fri, Nov 1, 2019 at 5:47 PM Qing An <[e-mail]> wrote:
> For initial flood, there are approaches like
> source address statistics

This is a very rough and biased method at best.  Generally (which
would be IMNSHO 98% of the cases), the statistics about past events
doesn't tell you with an accuracy anywhere close to being reliable if
this particular new packet could be from spoofed source or not.

E.g. an attacker who would generate spoofed packets from the typical
source addresses for your type of business in your country (e.g.
popular cellular NAT pools for news sites) would circumvent that check
easily.  With the overwhelming majority of HTTPS resources there's
hardly any point in giving the latter a shot.

> and speed limitation.

And you'll be limiting the speed for legitimate clients as well in the
above example (and many other scenarios).  This is a nice way to
amplify the effects of an attack, much less to handle those.

***

With the greatest of respect, speaking more broadly, please take into
account that a good engineering practice (no matter if it's Internet
engineering or whatever) must not rely on the assumption that
something which is perceived as typical would always happen, and
something perceived as non-typical would never occur just because it
has to date never occurred in the past.

The example commonly seen in university books on engineering would be
e.g. the Oppau explosion — caused by the factory workers tearing
through ammonium with dynamite, just because ammonium has never
detonated during that operation before and was thus believed to be
unlikely to explode in future.  An example more close to the content
of this WG would be middlebox vendors hard-coding "typical" protocol
behaviour into their products (causing transport protocol ossification
which the WG spends I believe no less than 50% of time fighting
against) just because the said vendors do not appear to see the
standard but non-typical behaviour in their sample network dumps.

Both approaches you propose are vulnerable to a few simple
circumvention techniques, and while I totally accept that probably
you've never seen those techniques applied against your network, they
are quite extensively documented.  Therefore it's hard to see, at
least for me, why the IETF should account for the flawed mitigation
approaches during the transport protocol design.

--
Töma