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

[Sheng Jiang <[e-mail]>]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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)" <[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.

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.

Regards,

Sheng
 
> Regards,
> Mark.
> 
> 
> 
>