NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

Fernando Gont fernando at gont.com.ar
Fri Jul 15 04:13:49 UTC 2011


On 07/15/2011 12:24 AM, Jimmy Hess wrote:

> A similarly hazardous situation exists with IPv4,  and it is basically
> unheard of  for IPv4's Layer 2/ARP security weaknesses to be exploited
> to create a DoS condition, even though they can be (very easily),

IMO, the situation is different, in that the typical IPv4 subnet size
eliminate some of the attack vectors.

For example, it would be virtually impossible for an ARP cache to grow
without bounds, and consume all kernel memory, because the typical IPv4
subnet size imposes a limit on the number of entries. That is *not* the
case with v6.


> IPv4  Layer 2 DoS conditions are often due to a malfunction or error
> than intended attack;   more likely,   IPv6 Layer 2 security
> weaknesses will be used to  intercept traffic for snooping, or quietly
> subvert network policy.   LAN DoS conditions are noticed quickly, and
> usually result in physical unplugging of the attacking  (or
> malfunctioning)  node.

Assuming the admin of the possibly-ipv6-enabled-by-default router is
IPv6 aware, etc.


> Methods can be designed to protect against spoofed NDP flooding on the
> LAN that do not require the router's involvement.

Which ones?




> For IPv4 switched networks there is a technology referred to as
> 'Dynamic ARP Inspection'.
> 
> Untrusted IPv6 LAN environments will need to implement SEND  or  some
> form of  'Dynamic ND inspection'   plus RA-guard.

Good luck with deploying SEND.

OTOH, forget about current implementations of RA-Guard:
* http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt
* http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt


> If it comes down to   solving a  remote DoS issue at the cost of
> creating a LAN DoS issue that comes down to   'hosts on the LAN having
> to spoof'
> 
> I would say that's easily well worth it.

You *can* fix the remote DoS issue, *without* introducing the
locally-exploitable one. That's the point.

Thanks,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1







More information about the NANOG mailing list