Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 19 Jul 2005 14:34:41 +0200

Hi again,

I also started wondering how the solution works with SEND and especially
when the timestamp and nonce options are present.

In addition what if the router(s) is/are configured to send RAs
relatively seldom, say once every 60 minutes, would it be required that
the PoA decreases prefix lifetimes in the cached entries? Just
wondering...

/Tero

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 20 Jul 2005 14:52:45 +0900

Tero

> the PoA decreases prefix lifetimes in the cached entries? Just

Good point. This is tricky part but, we think, isn't insurmountable. 
Our line of thoughts are as below. 

First, we checked with people who run IPv6 router and heard that usually
RA information is static. Once configured, the same RA is sent over and 
over again. Usually RA doens't change its information. So I think for the 
most case the scheme is ok. 

Second, for the case RA having a kind of timer value, we can use the 
following trick. PoA may keep checking the validity of the cached RA 
and before timer expires, send an RS to refresh the cached RA. 

But this seems complicated and the simplest & safest solution may be 
to establish a kind of secure path between AR and PoA wish a kind
of scheme described in MICS section. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Wed, 20 Jul 2005 16:01:35 +1000

Hi Tero,

> the PoA decreases prefix lifetimes in the cached entries? Just

I've done an analysis on this (which may yet have flaws) and there
are some tricky issues with the caching and SEND.

With SEND, the options cannot be modified by an intervening device
(as it doesn't have the CGA private key), so all RA contents remain
the same, including lifetime and SEND Timestamp options.

With the existing SEND specification, differences in clocks between
a host and a router are accounted for by allowing the first RA
to arrive with an allowed window.  This defaults to +-300 seconds
(from section 5.3.4.2/10.2 of RFC3971).

Therefore the cache cannot last beyond 5 minutes (without even
accounting for different clocks) by default.

The Receiver's timelog - RDlast (and the received timestamp TSlast) of
the first RA message are then stored for comparison, and new RAs
are tested against the following inequality (the newly received
timestamp option containing TSnew, and the reception time on the
host being RDnew), only those new RAs conforming to the following
inequality are acceptable as fresh SEND RAs (sec 5.4.3.2):

TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz

The drift and fuzz factors being defined as the maximum rate of
clock drift, and the maximum (absolute) value variation in
reception of individual packets across a link, respectively.

Using the defaults from section 10.2 (in seconds):

TSnew - TSlast > 0.99x(RDnew - RDlast) - 2

Upon the first reception of a non-cached RA (after the cached RA),
TSnew - TSlast will be greater than RDnew - RDlast, since
(assuming minimal clock skew over the period):

RDnew - RDlast = delta_t
TSnew - TSlast = delta_t + t_cache

This then is an accepted RA, as the inequality holds.  Such an RA
updates the RDlast and TSlast timers with the fresh RA's information
(as described in 5.3.4.2 of SEND).

Where either the first received RA was non-cached, and had an up-to-date
timestamp, or a later uncached RA updated the RDlast and TSlast
parameters as described above, the situation is not as clear cut.

Any subsequently received cached RA will be delayed by t_cache'.

Therefore, in this case:

RDnew' - RDlast' = delta_t'
TSnew' - TSlast' = delta_t' - t_cache'

Using the inequality above (again assuming no significant skew)

delta_t' - t_cache' > 0.99 x delta_t' -2

which implies:

t_cache' <= 0.01 x delta_t' + 2

So the cache time has to be less than 2 seconds plus 1% of the
interval between received RAs in order to be accepted as a fresh
RA by the SEND host.

This affects subsequent RA reception when transiting to the
new PoAs within the same link.

It also affects the return of a node to a previously visited
link for which it has previously received SEND messages
(with parameters and Timestamps).  As described in sections
5.3.4, 9.2.5 (and Appendix B) of SEND, hosts are likely to
keep such information beyond the lifetime of a particular
neighbour cache entry in order to prevent replay attacks.

So long as the SEND timer information is kept, return to
a link will ignore a Cached RA (if the cache duration is
outside the boundaries of the skew and fuzz factors for SEND).

I'm still not quite sure about this analysis, so I'd appreciate
feedback on the issue.

Greg

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 21 Jul 2005 17:08:45 +0900

Dear Greg

> I'm still not quite sure about this analysis, so I'd appreciate

Thanks for a detailed and useful analysis. I'll think it through. 

Best Regards

JinHyeock