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

[Jari Arkko <jari.arkko@kolumbus.fi>]

Greg Daley wrote:
> Hi James,
> 
> James Kempf wrote:
> 
>> During the design team discussions in SEND, we discussed having the host
>> preprovisioned with the new router's certificate so that there was no 
>> need
>> for ADD when the host came up on the new router.
>>
>> In the latest draft of CARD (draft-ietf-seamoby-card-protocol-07.txt), 
>> there
>> is support for two additional CARD Request/Reply options: the Trusted 
>> Anchor
>> option and the Router Certificate option. These allow a host to 
>> request the
>> certification path for a handover candidate router from the existing 
>> access
>> router, so the host doesn't have to do ADD on the new access router.
> 
> 
> I think this ties in with Eunsoo's description of CARD and DNA
> interactions.
> 
> Of course if we trusted the old router to provide accurate information
> about candidate routers on adjacent links (not predicting which link
> we'll arrive on, but that the routers in the CARD list are real
> routers), we wouldn't necessarily need to undertake the certificate
> chain computation immediately in every case.
> 
> That may be a bit dangerous to trust by itself but would give
> us time to start using the router.  While using the router we
> could corroborate the trust chain received from CARD messages
> or receive one from the router itself after arrival on the link.

There are multiple delay factors involved here:

1. Time to retrieve the certificate chain over the link.
    If the previous router gives you the chain already,
    no time is wasted on this on the new link.

2. Time to verify the chain. This is CPU time on the
    client. But this too can be verified before movement.

3. Time to verify that an RA is signed by the expected
    router. This needs to happen after movement. Presumably
    you must wait for an RA in any case, so no additional
    protocol time is wasted by security. However, you must
    still verify the signature. This is expected to be fast,
    under a millisecond. (http://www.eskimo.com/~weidai/benchmarks.html
    tells me that RSA 1024 verification should take 0.19 ms).

Conclusions? Its likely that certificate chain retrieval takes
some time, because the messages are lengthy and because
there may be many messages. However, if you get this
information from a previous router, most of the communication
and computation effort is spent on the previous link,
before movement. Almost no delay is involved on the
new link, as long as there is _some_ signed message
from the new router that you act upon.

--Jari