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

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

Hi Jari,

Jari Arkko wrote:
> 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.

At this stage, we'll probably not try to optimize for the
case where the certificate is available before arrival on
link, but the illustration is good.

We need to get the fallback case working where the CARD isn't
successful.  (arguably this is done in SEND, though there may
be some need to say something in DNA/refer to SEND).

Greg