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

[Greg Daley <gregd@research.panasonic.com>]

Hi Julien,

Julien Laganier wrote:
> 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. 

You're right, I'm assuming some prior knowledge
(t_RA < t_RS), please see below.

> 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...

Yes, I'm assuming that the router can guess the IP address of the host.

This isn't particularly difficult, if the target has been seen before,
is using an EUI-64 or a CGA.   The prefix is unchanging, so this may
have been seen on a different link.  This even works with 3041 addresses
which are preserved after a link-layer hint.

It depends on the value of the target. If there's a value in
tracking the target someone may put in that effort.  For
example, if the person was a government official, or
a movie star, people may want to play man-in-the-middle.

It shouldn't be easy for them to do this though.

> 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. 

There's no source entropy except the source address (and the link-layer
address, which is constant) in the RS.  There aren't even any flags.

Always changing the source address (3041-style) will work too,
although it's not clear if this would create a large number of
Neighbour cache entries on peer routers (I guess it would...
but would that be acceptable?)

> 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.)

Adding an RFC3971 Nonce option even to non-SEND hosts would
achieve the same thing.

It doesn't have to be a new option, it could be the same one.
Let's not hack fragment headers ;)

That's not to say I'm proposing Nonce options for all hosts,
it would work though, without further changes to options and formats.


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

Please let me check.

Greg