[142841] in North American Network Operators' Group
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was:
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 14 21:51:12 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAAAwwbWV8SG_SJkR0V8MqKDZPvKVSv0Sa3uRegEEWrWh0QWHrQ@mail.gmail.com>
Date: Thu, 14 Jul 2011 18:47:26 -0700
To: Jimmy Hess <mysidia@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:
> On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont <fernando@gont.com.ar> =
wrote:
>> On 07/11/2011 09:17 PM, Karl Auer wrote:
>> Vulnerability to this specific issues has a great deal to do with the
>> implementation. After all, whenever there's a data structure that can
> Yes
>=20
>> In this particular case, if the implementation enforces a limit on =
the
>> number of entries in the "INCOMPLETE" state, then only nodes that =
have
>> never communicated with the outside world could be affected by this
>> attack. And if those entries that are in the "INCOMPLETE" state are
>> pruned periodically (e.g. in a round-robin fashion), chances are that
>=20
> Not only that but it's possible to differentiate _how_ an entry is =
added to
> the table when the table reaches a "high water mark" it's possible
> to drop the packet that was attempting to cause a NDP discover, fail =
to add
> the INCOMPLETE entry to the table, but _still_ send the outgoing =
NDP
> neighbor solicitation, and complete the entry or "whitelist" the =
destination
> if the neighbor advertises itself.
>=20
> That is: if the destination is good, the neighbor will respond to the
> NDP solicit,
> even though the neighbor doesn't have an entry in the table.
>=20
> So a small number of packets are lost at initial setup, due to the
> attack, but further
> packets are unaffected,
>=20
> So long as the attack does not overwhelm router CPU, and so long as =
the
> INCOMPLETE entry high water mark is at a low enough level,
> so there is still ample space in the table.
>=20
>=20
> Even more sophisticated strategies may be available.
>=20
> It should be possible to mitigate this, so long as the attack does not =
actually
> originate from a neighbor on the same subnet as a router IP interface =
on
> an IPv6 subnet with sufficient number of IPs.
>=20
>> even those "new hosts" would be able to get into the neighbor cache =
and
>> hence remain unaffected by this attack.
>>=20
>> Thanks,
>=20
> --=20
> -JH
Very true. This is where Mr. Wheeler's arguments depart from reality. =
He's right
in that the problem can't be truly fixed without some very complicated =
code added
to lots of devices, but, it can be mitigated relatively easily and =
mitigation really
is good enough for most real world purposes.
Owen
