Re: [DNA] Small security flaw in Hash FastRA (with proposal)

[Julien Laganier <julien.laganier@laposte.net>]

Hi Greg,

I agree it is important to assess what you are proposing w.r.t. to the
expectation that FastRA scheduling is predictable.

I however have one question. If I understood correctly the attack you
described:

- The rogue AR needs to configure an address that would trick other
on-link ARs to believe that rogue AR ranks first for a specific host
sending an RS (at time t_RS.)

- To achieve that the rogue AR has to use that address to send an RA
(at time t_RA.)

This implies that t_RA < t_RS.

Section 5.1.8 says:

 " A Host Token is needed from the RS to calculate the router's
   ranking. The first 64 bits of an SHA-1 hash of the source address
   of the RS MUST be used as the RS host token."

So either the rogue AR knows the IP address of the attacked node
before it uses it to send the RS, or it has to discover it in the RS,
which would imply that t_RS < t_RA, which contradict with the above.

So do you assume that the rogue AR already knows the attacked node IP
address or did I missed something in FastRA or the attack you
described? I'd think it's unlikely that the rogue AR knows the IP
address of the node in advance...

Anyway, if you assumed that the rogue AR already knows the attacked
node IP address, a similar mitigation of the attack that would also
works with non-SEND nodes would be to add to the RS a source of
entropy elsewhere than in the (not present) SEND nonce.

This could be achieved by mandating that DNA nodes sending RS includes
a random nonce either into a DNA-specific parameter (e.g. DNA_Nonce)
or into Fragment header with offset set to 0 and last fragment set to
0 (i.e. no fragmentation.)

Thanks.

--julien

PS: I didn't get the email from James replying to your initial post.
Perhaps the ML server still has problems...

On Friday 31 March 2006 22:38, Greg Daley wrote:
> Hi All,
>
> There's a small security flaw in Hash FastRA which
> can be used to force all routers to respond
> more slowly than the bogus router for a particular
> solicitor.
>
> With an initially passive attacker, the host can identify
> all good routers on the link, and identify which of
> the routers will be the first responder, by XORing
> each of the routers' hashes with that of the host,
> and then generating new addresses whose XORs beat
> the leader.
>
> This takes on average O(2^L) passive address generations
> where L is the number of leading one bits in the best
> router's XOR.  For a small number of routers, this is
> likely to be achieveable, with limited computational
> cost for an attacker.
>
> This can be improved greatly for SEND hosts if any
> Nonce received in a solicitation is incorporated into
> the soliciting Host's hash generation.
>
> This will change the hashed value for each incoming RS
> and consequently randomize the XOR values for the
> responding routers.
>
> No router or host will be able to predict which responder
> will be first, until the RS is received.
>
> Original Host token generation:
>
> left_64(SHA-1( host link-local address  ))
>
> Modified Host token generation:
>
> left_64(SHA-1( host link-local address, Nonce  ))
>
> Hosts which don't send Nonces (non-send hosts?) don't
> receive the benefit.
>
> This is detailed in my thesis (not yet submitted :-/ )
> but I'm placing it here now because it may be important
> to consider as people are assuming predictable scheduling
> for all of a host's received RAs.
>
> Greg