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

[Ole Troan <ot@cisco.com>]

>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org 
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mark Smith
>> Sent: Thursday, April 08, 2010 5:45 AM
>> To: Hemant Singh (shemant)
>> Cc: IPv6 Operations
>> Subject: Re: draft-jiang-v6ops-nc-protection-01.txt
>> 
>> On Fri, 26 Mar 2010 12:24:38 -0500
>> "Hemant Singh (shemant)" <shemant@cisco.com> 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.
> 
> That's exactly what we are aiming to. We admit that our mechanism may not be
> able to solve this vulnerability totally. But it reduces the rish very
> largely. Quantitatively, it reduces the attack frequency to a level less
> that 1% before.

but only for on-link attacks? it does nothing for off-link attacks, correct?

/ot