I'd say yes, but that won't necessarily solve the problem. Besides
misconfiguration is the problem of poorly designed implementations.
It might be that the poor design is a result or an imprecise
specification, specifically a loose specification on retry strategies.
In provreg, one of the IESG comments was that we need to be wary of
congestion control (which is an aspect of the retry strategy issue),
and as a result are considering barring the use of UDP as a transport
layer mechanism. So, in some sense, the IESG is already looking at
it in currently developed protocols.
The problem may be in old protocols with old implementations already
deployed. The IESG can do little about that - but perhaps promote
active filtering or "smoke stack" scrubbing protocols. (**Not** a
serious suggestion, and not meant to be sarcastic.)
At 16:28 -0500 12/4/02, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
We are fast approaching a state where the *majority* of Internet traffic is
either the result of misconfiguration (see the CAIDA report where it has
reached 98% for at least one root nameserver), or malicious action
(spam, Smurf
attacks, Klez/Sircam/etc, and so on). For a number of reasons (most notably
cluelessness at the edge host, so it won't get fixed there, and the fact that
all this traffic is billable if you're a transit provider, so there's little
economic incentive to fix it, particularly in the wake of the
dot-bomb bubble),
there is little hope that this situation will miraculously correct itself.
Should the IESG require that standards track protocols be analyzed for
their resilience in situations where the majority of requests are either
malicious or broken? RFC3426, sections 9 and 10, already discusses this, but
it is merely "Informational".
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer