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

[Soohong Daniel Park <soohong.park@samsung.com>]

Hi Greg. I see what you saying. 

I am just curious this is an specification 
issue or implementation issue.


Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of Greg Daley
> Sent: Tuesday, July 20, 2004 11:56 AM
> To: Soohong Daniel Park
> Cc: Brett Pentland; dna@eng.monash.edu.au; James Kempf; Mohamed Khalil
> Subject: Router Security and FastRA (Re: [DNA] FastRA draft)
> 
> 
> 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
> 
> 
>