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

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 20 Jul 2005 07:56:25 +0200

Hello JinHyeock,

Thanks for the answers. There is an additional question below.

>I assume your question concern mostly about RA Proxying with 
>Scanning. Am I right?

Correct.

> > Just a couple of quick questions...
> >
> > Should entries in the cache suppose to have the lifetime stated in
an
> > RA?
> 
> No. We don't think it's desirable for PoA to modify an RA, unless
> it gets permission from AR.

Ok. I was just thinking how long PoA should keep an entry in the cache.
Unlike it the second mail sent later, at this point I was not wondering
should the lifetime in the cached entry also be decreased.

> 
> > I guess PoA uses sending router's source address to index entries in
the
> > cache, i.e. if a router sends an updated RA, PoA finds the old entry
by
> > using the source address (or source link layer address in the option
> > field).
> 
> Right now, we design the scheme in the simplest way and PoA doesn't
> manage index entries.
> 
> Assume there are two routers on a link, AR1 and AR2. First AR1
> sends RA1 and PoA caches it. Afterwards AR2 sends RA2, then
> PoA substitutes its cached RA with RA2. This doesn't affect DNA
> performance as long as both RA1 and RA2 can properly indicate
> link identity, i.e. RA optimized for DNA.

Oh, I see. There is only one cached entry instead of multiple entries
(i.e. RAs from different APs).

/Tero

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 20 Jul 2005 08:06:50 +0200

Hi Greg,

> Hi Tero,
> 
> Tero Kauppinen (JO/LMF) wrote:
> > 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...
> 
> 
> 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.

True. The later question was actually meant for the case when SEND is
not applied / available. I should have stated that in the sentence,
though. :(

Thanks for the detailed description.

Tero

> 
> 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: Greg Daley <[email-masked]>
Date: Fri, 29 Jul 2005 14:39:54 +1000

Hi Syam,

----- Original Message -----
[cut]
> > Can I ask what the source address of the RS from the AP is?
> 
> We are using unspecified source address. The otherway way we thought
> is to construct the link local address for the MN based on its MAC.

No, you're doing it the better way (though it always seemed hacky
to have the TSLLAO in an unspecified source RS).

Some nodes won't ever configure an EUI-64 (they're not
SEND securable).

Greg

---

From: Greg Daley <[email-masked]>
Date: Sat, 30 Jul 2005 00:46:36 +1000

Hi Syam, 

----- Original Message -----
[cut]
> > Also, you definitely need modified routers, but I guess
> > that's handled by TSLLAO.
> 
> Yes. Also TSLLAO is not required all the time, in such cases 
> the router would send multicast RA.

I think that it's OK for the router to send a multicast RA,
but it may be necessary to get a fast response from the router
to use TSLLAO in the RS, otherwise the response is at the 
mercy of the MIN_DELAY_BETWEEN_RAS interval.

[cut]
> > 
> > It's really not possible to tell how much simpler it is, though.
> > The APs need to track a list of all routers, some of which may
> > not be trusted at L3 (Do they do SEND?).  
> 
> APs either can be manually configured or can be learnt from RAs.
> I am thinking that APs/Base Stations are more trustable nodes.
> Are you saying the APs may be trustable at L2 but not at L3?
> I do not know much about SEND, but I think it can be used if
> required.

I was thinking the other way around: that the APs may need
to be able to trust the routers, in order to select appropriate
routers to solicit.

Also I don't think APs are trustable, except if there's a particular
reason to trust them - which could be described if need be (I was
concentrating on trust of ARs though so this may not be necessary).

Greg