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

From: Sathya Narayanan <[email-masked]>
Date: Wed, 10 Nov 2004 16:29:19 -0500

> >> It was left as an open question how fast to proceed with
> >> the draft.  The chairs suggested of quickly proceeding to
> >> a WG last call, but some other people thought that it
> >> might be better to wait for the design team to come up
> >> with at least some initial ideas before going forward.
> >> I would encourage people to express their opinions on this.
> >
> > I have a hard time understanding proceedingly quickly with
> > a solution framework document, when we dont have stable
> > solutions (atleast agreed to by the WG) in the WG.
> 
> Maybe it is better to wait; I am open to both options.
> Opinions, please!
I too think its better to wait. We don't have to wait till the solutions work is completed, but we need to atleast go through one(or few)-cycle(s) of the solutions discussion before we move the framework document.

- Sathya

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 10 Nov 2004 16:59:21 -0500

> Pekka Nikander wrote:
>  better to wait; I am open to both options.
> > Opinions, please!
> > 
> > I'm just trying to keep us making progress and not lag
> > too far behind our milestones; OTOH, it there is a reason
> > it is not that hard to update the milestones.
> 
> Seems like folks are confusing "framework" and "summary" or 
> "overview".A framework is the thing you build before you place 
> things into it.
> For instance, you build the supporting structure of a building 
> before 
> you place the wallboards.
> 
> I agree that we can't write a summary or overview document until 
> we know 
> what we end up with, but we should be able to write a framework 
> document 
> which provides the frame into which the puzzle pieces will fit.
> If we can't do that, then we must be fumbling around in the dark.

I think the framework document is very useful and provides us with a nice, well, framework to begin work - but my only suggestion is, it makes sense to go through an iteration of the solution work, come back and may be make some changes to the framework document and then move it forward through WGLC etc. , instead of moving it forward now and making it absolete if the solutions fall outside the proposed framework.

- Sathya

---

From: Sathya Narayanan <[email-masked]>
Date: Thu, 11 Nov 2004 10:40:21 -0500

Erik -

<snip> 
> Yes, but don't we want an immediate RA whether on the same link or 
> on a 
> different link? (Making sure we agree on the goal.)
I am going to take the risk and suggest that how immediate the response is generated should also be part of the cost analysis. i.e. if we can guarantee a response within say 10 ms, but save a lot of overhead based on this compromise rather than requiring the response to be immediate, I think we should consider it.

<snip>

> You can't think about the security overhead without knowing what 
> to 
> secure which requires some idea of the threats. I don't think this 
> is 
> particularly complicated - just requires sitting down seeing what 
> an 
> attacker can accomplish by spoofing the linkid to the routers.
Agreed. We should do this ( I will try to work on this).

thanks,
Sathya

---

From: Greg Daley <[email-masked]>
Date: Fri, 12 Nov 2004 03:18:57 +1100

Hi Sathya,

----- Original Message -----
From: Sathya Narayanan <[email-masked]>
Date: Friday, November 12, 2004 2:24 am
Subject: Re: [DNA] Confirming today's face-to-face meeting decisions

> <snip> 
> > > 2) Whether immediate change is detected in link-scoped 
> > identifier is actually not clear - this is primarily because of 
> > the non-dependency of the method on L2 trigger (and that is 
> > arguably a good thing), so the average gain in the detection time 
> > for link-scoped identifier approach MAY not be very high. Again, 
> > we need some analysis.
> > 
> > I think this is a separate problem.  The point is in being able 
> to 
> > makea correct decision based on the reception of a single RA.  
> How 
> > you get that RA is a separate problem.
> Yes. It is a separate problem, but when we are talking (comparing) 
> the quickness of link-change-detection we need to look at the 
> complete picture. If the link-scoped approach has the property of 
> link-change-detection when a unsolicited RA is received (which is a 
> good thing about it), but how useful is it if you need the RS 
> message to initiate it for rapid-detection is a valid point to 
> consider in terms of the cost. If the link-scoped approach depends 
> on a RS message, than host-scoped approach is (arguably) as good as 
> the link-scoped approach with less out-of-band cost.
> 

L2 Trigger isn't needed, if in MIPv6 the RA rate is 20/second.
In this case, the only issue is establishment of trust with the router,
which is a problem in both cases.
 
> > > 3) I am not recommending timeout as the only change detection - 
> > if you think about the mechanism proposed in RRD, when the 
> > 'landmark still exists?' question is asked, if you receive a 
> 'this 
> > NEW landmark exists' answer thats an indication of link change. 
> > Ofcourse, you need to authenticate this response - but in most 
> > cases the router that responded is likely to be the router you 
> are 
> > going to use as default router and you need to authenticate it 
> anyway.> 
> > I can't remember the details of RRD - are you saying that there 
> is 
> > a way
> > for an RA with a prefix that you haven't seen before indicates a 
> link> change as oposed to a new router on the same link?
> Yes - if we can design a mechnism that with a high probability can 
> ensure that the confirmation of current landmark (from current AR) 
> is likely to happen before any other router responds. Thats what I 
> am trying to achieve with my MaxDelayForCurrRouter and 
> MinDelayForOtherRouters variables. If these two variables are equal 
> to zero, the probability is 1 - packet loss probability and the 
> time window involved can be few milli-seconds (this needs to be 
> confirmed using simulations, ofcourse).

There's a reliance on Positive Ack here in the case where there's
no negotiation amongst peers.

Packet loss is obviously a considerable factor, but it's not clear
without simulation whether the false positive movement in this case
causes more work or harm than the cost of explicitly changed LinkIDs.

Where there is any trust or knowledge of the prefixes or router id's
on a link, this has exactly the same issue as Link Identification 
in establishing trust between routers as Link ID.

These approaches Explicit LinkID and Landmarks are still likely to be
required in backwards compatability for non LinkID routers on the
same or different link.

For hosts which need landmarks it's possibly worthwhile working along
the lines of confidence intervals somewhat like CPL.

If we're confident that the landmarks are representative of the link 
(Link ID stored for a while across RS/RA, routerids stored), 
then any response which doesn't match the stored landmarks may be acted
upon immediately.

If we're not sure, but have an indication throgh reception of a non
matching landmark, then we should check the reachability of the landmark
explicitly (possibly with hysteresis). 
This may require a further test or waiting for a timeout...

Greg

---

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

Erik -

> And what's the problem?
No problem at all. It was just a comment ;-)
 
> I the interest of making progress it is useful to try to 
> understand what 
> we see as desirable properties of a solution, and I don't see how
> your comment above helps with this.
Only in the sense that, we need to be careful not to become dependent on all the routers agreeing on the same landmark - thats why I said 'towards'.

thanks,
Sathya