Router Security and FastRA (Re: [DNA] FastRA draft)

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Daniel,

Soohong Daniel Park wrote:
>>Yes, sorry.  It is just the boilerplate that has changed.
> 
> Not at all,
> 
> To enforce the security aspect of ND, SEND WG is 
> currently working for that (also Jak already engaged
> in this job), however I think FastRA is beyond of this
> enforcement. If adopted SEND, FastRA is not *Fast*
> because it has to treat on SEND functionalities of RS
> on the router which supports FastRA.

FastRA would probably be sufficiently fast even with
SEND.  The ND processing delays associated with the
prototype linux SEND implementation which I saw
in Minneapolis(?) were in the low 10s of milliseconds.

It's not the RS which is slow, but the authorization for
the RA.

SEND already has text regarding the use of routers
and their ADD (Authorization Delegation Discovery),
which covers the issue of unsecured routers, and
their adoption.

It's fairly easy to apply the same mechanisms to
ADD as it is possible to do with FastRA.
The deterministic FastRA draft doesn't explicitly
cover multicast RA (although Deterministic FastRA does
touch on it).

You'd need to have a valid multicast RA/ADD scheme
to undertake this since the Certification Path Advertisement
(previously called the Delegation Chain Advertisement)
needs to be advertised as a multicast message.

The 'devil' is in the detail, as they say,
but this may be reasonable to add on to FastRA
(later?? in another document??) if people think
FastRA itself is a good enough idea.

There is still the possibility that a router can be
used (tentatively) if it has a valid CGA signature
(without having fast ADD).   In this way it may be
possible to extort initial configuration packets
from the host but this wouldn't last beyond ADD failure.

If we take this into consideration in building a
DNA solution, it may be possible to build a DNA
solution which doesn't necessarily wait for ADD
to complete but is aware of the consequences of attack,
and may move to a more secure form of operation in 'risky'
environments, or at administrator command.

Greg