Subject: Re: [DNA] Confirming today's face-to-face meeting decisions

From: Sathya Narayanan <[email-masked]>
Date: Thu, 11 Nov 2004 09:11:28 -0500

JinHyeock -

<snip>
> Landmark approach don't have to be host scoped. Many hosts can share the same landmark.
It is the minimum requirement - similarly the same linkID can conceivably be used in more than one link (as long as they are further apart), I don't remember global uniqueness of LinkID being agreed upon. But, the linkID MUST ATLEAST BE the same within the link in one case (link scoped) and its enough if the host picks its own in the other (host scoped).

> 
> > The question to ask is, whether the cost of establishing the 
> unique link identifier among all the nodes (routers) in the link 
> is worth to avoid an extra 'does this landmark still exists' 
> question and answer?
> >
> > Link scoped identifier scheme requires completely securing the 
> link so that nobody can spoof a RA message or confuse the link 
> identifier, while we (I am not sure about this) may not need 
> complete security as long as a secure association between the host 
> and the current AR is good in the host scoped identifier approach.
> 
> Even with host scoped (?) approach, if there is only the secure
> association between a host and the current AR, the host can't securely
> detect that a link change has happened. The host can't receive a 
> secure 
> message confirming a link change when it actually happens.

In the host scoped approach, link change is inferred when the current landmark is not confirmed by the network (timeout) - I know, packet loss will have the same effect as link change and this becomes a additional cost for host scoped approach.

My only request is that we do a cost comparison (atleast a preliminary one) before deciding to go with either approach.

with regards,
Sathya

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 11 Nov 2004 23:33:50 +0900

Sathya

[omitted]
> It is the minimum requirement - similarly the same linkID can conceivably be used in more than one link (as long as they are further apart), I don't remember global uniqueness of LinkID being agree…
 
ok. Can I assume that now we have agreed that a link identifier 
must be the same within the link? 

> In the host scoped approach, link change is inferred when the current landmark is not confirmed by the network (timeout) - I know, packet loss will have the same effect as link change and this beco…

ok. I clarify my statement. 

Even with host scoped approach, if there is only the secure association 
between a host and the current AR, the host can't quickly detect that 
a link change has happened in secure manner. 

> My only request is that we do a cost comparison (atleast a preliminary one) before deciding to go with either approach.

ok. I am afraid that timeout approach takes too much time 
that would result in service disruption.   

Best Regards

JinHyeock

---

From: Brett Pentland <[email-masked]>
Date: Fri, 12 Nov 2004 02:04:03 +1100

Sathya Narayanan wrote:

> It is the minimum requirement - similarly the same linkID can
> conceivably be used in more than one link (as long as they are
> further apart), I don't remember global uniqueness of LinkID being
> agreed upon. But, the linkID MUST ATLEAST BE the same within the link
> in one case (link scoped) and its enough if the host picks its own in
> the other (host scoped).

How unique a LinkID has to be is a matter for debate, but I think the
requirements are greater than link scope.  Having the same LinkID on all
routers on link provides the positive acknowledgement that "yes, this is
the same link that I last received an RA from".  This is not really any
better than sending out an RS and getting an RA with a prefix that we
have already seen.

A LinkID needs to be unique within the set of links that a host might
potentially move to (possibly within some limited timeframe) so that a
change in the LinkID received from a previous one gives us the negative
acknowledgement that "no, this is definitely not the same link as one
we last received an RA from" (rather than having to wait for a timer to
expire).

Brett.