Re: draft-jiang-v6ops-nc-protection-01.txt

[Mark Smith <[e-mail]>]

On Fri, 26 Mar 2010 12:24:38 -0500
"Hemant Singh (shemant)" <[e-mail]> wrote:

> The problem this document is trying to solve and any other ND related
> security problem can be solved by use of SEND. 

It seems to me that SEND is protecting against illegitimate ND traffic.
The specific problem as I see it is that SEND won't protect against
illegitimate _non-ND_ traffic i.e. offlink traffic to non-existent
onlink destinations (i.e. enters router on interface A (Internet), exits
on interface B (LAN /64), triggers ND on subnet attached to interface
B), that then triggers legitimate ND traffic. So SEND will ensure the
router's NS is a legitimate one, but SEND doesn't verify that the
destination address in the NS exists, without creating state in the
router to allow the SEND ND transaction to complete. The attack is
about remotely being able to utilise outstanding NS
state in the router to trigger the DoS.

> If SEND is not used, as
> I said on the mike, read section 5.3 of the RFC 4861 which will purge
> bogus entries due to NUD timeout.  This document is of no use at all.  
> 

I've had a look at that section of 4861, and I don't think what is
stated there will prevent this issue.

Firstly it says that there is no need for active garbage collection
under normal circumstances, as NUD will purge entries that become
stale. However, the specific issue occurs before NUD kicks in - NUD
fundamentally detects a neighbor disappearing, after it has existed.

This attack is taking advantage of a neighbor never existing in the
first place. The vulnerability is in the state that is kept while the
initial ND NS is outstanding, for an address that doesn't exist.

Secondly, it says that if there is a need to limit the size of the
Neighbor Cache, then a least recently used policy should be used to
purge entries, with a period of use up to 10 minutes.

So it seems to me that there are potentially three types of entries in
the Neighbor Cache:

(1) Valid entries i.e. NS/NA has completed, and NUD will detect if
and when the neighbor disappears.

(2) Incomplete entries for valid addresses. NS has been issued,
waiting for a corresponding NA to arrive.

(3) Incomplete entries for non-existent addresses. NS has been issued,
waiting for an NA that will never arrive. This is the attacker's
traffic, generated by incrementing through the /64 (LAN or P2P link)


If the attacker fills up the neighbor cache with (3) entries, then
presumably the LRU garbage collection routine will kick in straight
away. If it's as simple as that described in RFC4861, then I think it's
probable that it'll start purging (1) and (2) entries, because the
attacker is both creating and therefore keeping the (3) entries most
recently used. By removing (1) and (2) entries, it creates a DoS for
existing nodes for which the router has already completed the NS/NA
transaction, and for existing nodes for with the router has an
outstanding NS. The neighbor cache can end up with no completed
entries, only (2)s and (3)s, resulting in a complete DoS for legitimate
offlink sources trying to access the link.

If the garbage routine is more selective that what is specified in
RFC4861, and restricts it's LRU purging to Incomplete NS/NA
transactions, then it still causes a DoS for existing nodes that
haven't completed their NS/NA transaction. This is certainly
significantly better than the simple garbage collection routine,
however it still facilitates a remotely triggered DoS for nodes that
may have recently become available.

If the draft you are commenting on provides a mechanism that closes
this vulnerability, or there are other effective methods that prevent
remote attackers being able to create traffic triggered state in
routers, I think they're well worth pursing.

Regards,
Mark.