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

[Christian Vogt <chvogt@tm.uka.de>]

>> Deterministic FastRA could be an option for networks where RA
>> ordering is important and routers can mutually authenticate each
>> other, such as NETLMM.  This wouldn't break things; the routers
>> would just ignore the Nonce option used by MNs in RSs and come up
>> with their own, deterministic RA ordering.
> 
> That's not exactly what I meant :)

:-)

> I'd really prefer there's one solution, if possible.

Yep, that's certainly right.

What I meant is that NETLMM routers could really use any (possibly
proprietary) mechanism for scheduling RAs.  Even if the DNA
specification defined MN-generated nonces to randomize the input for the
FastRA scheduling algorithm, that really would not keep NETLMM routers
from using their own solution for both security and scheduling.

There would certainly be problems where different administrative domains
overlap, but I'm not sure if NETLMM is currently chartered for such
scenarios.  Same thing for deployments with heterogeneous access
technologies.

Be it as it may, I agree with you in that there should be one single DNA
mechanism.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/



Greg Daley wrote:
> Christian Vogt wrote:
> 
>> Hi Greg!
>> 
>>> 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.
>> 
>> 
>> I see, so much the better.
>> 
>> Deterministic FastRA could be an option for networks where RA 
>> ordering is important and routers can mutually authenticate each 
>> other, such as NETLMM. This wouldn't break things; the routers 
>> would just ignore the Nonce option used by MNs in RSs and come up 
>> with their own, deterministic RA ordering.
> 
> 
> That's not exactly what I meant :)
> 
> I'd really prefer there's one solution, if possible.
> 
> The solution would drop straight in to a constrained network 
> scenario, but wouldn't work in a scenario with any form of mixed 
> deployment (caveat deployer!).
> 
> At this stage, let's see what the issues are which need resolving, 
> and we'll work out what the solutions are from there (I really like 
> HashFastRA, and it has the blessing of DT and WG).
>
> Greg
>