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

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

Hi Christian,

Christian Vogt wrote:
> Greg,
> 
> this is an important observation.  I have one comment about your
> proposed solution:
> 
> Your approach is based on randomizing the XOR input that comes from the
> MN.  Given that your proposed security solution is based on SEND, how
> about verifying the XOR input that comes from routers?
> 
> Specifically, a router identifies neighboring routers by listening to
> transmitted RAs.  Currently, it accepts all received RAs.  But if SEND
> is used, that router could drop received RAs if they cannot be
> authenticated to originate from a legitimate router.  The router would
> thus ignore the attacker's FastRA token when doing the XOR.
> 
> This approach should have an effect comparable to your proposed solution
> (unless I am missing something).  Yet, the order of transmitted RAs
> would not change due to randomization.


I think that we have been trying very hard to not require explicit trust
between routers, as we already had a solution which did that,
called Deterministic FastRA.

It doesn't reorder responses, it relies on the trust chains being
mutually authenticated between the routers.  This is an all-or-nothing
approach as a single router on-link which doesn't understand the
other's trusted root will cause scheduling collisions on every RS
reception.

If we could count on them knowing each other, we'd ditch the Hash FastRA
system, and go with Deterministic.  I don't think we want to do that,
because the non-SEND routers are still an important subset of the
networks we want DNA to work on.

(I'm not biased, Deterministic has my name first on the draft, and
Hash FastRA was thought up at the same time by Erik and Brett in an Aha!
design team e-mail thread).

Please remember that any non-SEND node can add a Nonce option to its
packet and gain the same protection against a nasty lurker.

Greg