[134424] in North American Network Operators' Group
RE: NIST IPv6 document
daemon@ATHENA.MIT.EDU (George Bonser)
Wed Jan 5 23:18:28 2011
Date: Wed, 5 Jan 2011 20:16:54 -0800
In-Reply-To: <AD66B3B4-3C0C-47BB-A511-81F229BA0D42@arbor.net>
From: "George Bonser" <gbonser@seven.com>
To: "Dobbins, Roland" <rdobbins@arbor.net>,
"Nanog Operators' Group" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>=20
> I've understood the problem for years, thanks, and have commented on
it
> in other portions of this thread, as well as in may earlier threads
> around this general set of issues - and it's completely orthogonal to
> this particular discussion.
I suppose what confused me was this:
"
I don't believe that host-/port-scanning is as serious a problem as you
seem to think it is, nor do I think that trying to somehow prevent host
from being host-/port-scanned has any material benefit in terms of
security posture, that's our fundamental disagreement.
If I've done what's necessary to secure my hosts/applications,
host-/port-scanning isn't going to find anything to exploit
(overly-aggressive scanning can be a DoS vector, but there are ways to
ameliorate that, too).
"
I thought the entire notion of actually getting to a host was orthogonal
to the discussion as that wasn't the point. It wasn't about
exploitation of anything on the host, the discussion was about the act
of scanning a network itself being the problem.
If network devices can be degraded simply by scanning the network, it is
going to become *very* commonplace. But the sets of problems are
different for an end user network vs. a service provider network. For a
transit link you might disable ND and configure static neighbors which
would inoculate that link from such a neighbor table exhaustion attack.
For an end network, the problems are different.
