RE: [DNA] Quick review of draft-jinchoi-dna-cpl-00.txt

["Bound, Jim" <jim.bound@hp.com>]

As a note I concur with Greg's input and statements completely as WG
member and good guidance to achieve a working strategy.
/jim 

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley
> Sent: Wednesday, July 21, 2004 9:45 PM
> To: JinHyeock Choi
> Cc: Samita Chakrabarti; Erik Nordmark; dna@eng.monash.edu.au
> Subject: Re: [DNA] Quick review of draft-jinchoi-dna-cpl-00.txt
> 
> Hi JinHyeock,
> 
> Sorry for not responding, My mailer thought it was clever and 
> put your email from yahoo into a sandbox.
> 
> I think this is important to work through, so please don't be 
> offended if I speak plainly.
> 
> JinHyeock Choi wrote:
> > Dear Greg
> >  
> > Please see my in-line comments.
> >  
> >  > Hi JinHyeock (et al).
> >  
> > Kindly be considerate to, instead of 'et all', refer 
> 'Erik'. There are 
> > only two of us.
> 
> I was also trying to include DNA and Samita.
> 
> >  > Firstly, I think that maintaining a set of on-link  > 
> prefixes is a 
> > good idea.
> >  
> > Glad to hear that. I think we'd better to base BCP work on 
> this idea. 
> 
> Some of.. There's more to DNA than knowing whether a 
> particular RA is from a new router.
> 
> 
> >  > The BCP draft attempts to
> >  > capture this in a less rigourous way in section 7.4  > (page 22) 
> > for comparison.
> >  
> > Far less, I am afraid.
> 
> ;-)
> 
> That's OK, I'm not afraid to be less rigourous.
> 
> I appreciate the rigour which Erik and yourself have applied 
> to the idea, though.
> 
> > [omitted]
> >  > Additionally, I largely agree with Samita's comments  > on the 
> > document (although I guess there needs to be  > discussion 
> about hints 
> > and completeness timing,
> >  
> > I see.
> >  
> >  > and
> >  > I don't mind the analysis which could be moved to an  > 
> appendix).
> >  >
> >  > Initially, not discarding the analysis gives an idea of the  > 
> > robustness of the method while introducing it, but it  > may not be 
> > necessary in a final version of a document.
> >  > (Also, I think JinHyeock is happiest when he's able to  > show 
> > something mathematically :)
> >  
> > Right. If only a thing can be proven mathematically, we can 
> advance it 
> > quickly. Too bad that too few things can be proven (and too many 
> > things are proven to be unprovable.) :-(
> >  
> > [omitted]
> > 
> >  > (2.3)
> >  > I've got no major issues (yet) until we come to section 
> 2.3  > The 
> > third last paragraph sounds stilted.
> >  > It seems to continue a thread from the previous 
> paragraph  > which 
> > talks about reception of a single RA for determination  > of 
> > attachment.
> >  >
> >  > Really the paragraph (3rd last) paragraph is talking 
> about the  > 
> > tradeoff between time delay to gain additional information about  > 
> > routers on a link, and the chance of getting a false 
> detection  > of 
> > movement.
> >  >
> >  > What has possibly been mentioned by Samita (whose point 
> seemed to  
> > > be missed) is that non-movement can _always_ be detected 
> with  > a 
> > single RA if that RA contains any single prefix in the 
> prefix  > list.
> >  >
> >  > This doesn't even require completeness of prefix list 
> information.
> >  >
> >  > Waiting in this case is unnecessary (although it may 
> cost nothing),  
> > > but retransmission of RS is wasteful.
> >  > I think that this is stated in section 3.2 (paragraph 
> 3), but the  
> > > paragraph in 2.3 misleads one into thinking otherwise.
> >  
> > I guess you mention the following paragraph
> >  
> >    Otherwise, to make matters certain, the host may need at 
> least wait
> >    for more RAs than a single one, or additionally perform 
> multiple RS/
> >    RA exchanges after the hint.  After each RS 
> transmission, the host
> >    waits for all RAs that would have been triggered by the RS as one
> >    aspect of trying harder, and then sending multiple RSs 
> (and waiting
> >    for the resulting RAs) is a way to try even harder.
> >  
> > In this case, a host waits additional RAs NOT to detect a 
> link change 
> > when it actually moves to a new link BUT to prevent itself from 
> > falsely assuming a link change while it remains at the same link.
> 
> I think it needs to be made clear that the reception of a RA 
> containing a prefix already in the list confirms that the 
> node is on the same link without waiting.
> 
> As described below, when we've got a prefix list which we 
> estimate as complete, we should just use it, since we're sure 
> to within a small portion of a percent that we've seen router 
> advertisements from each router.
> 
> The cost of waiting is too great in the case we've moved 
> (which is more likely than having missed a router's prefixes 
> in a CPL) to worry about whether or not we received hints.
> 
> >  > (3.)
> >  >
> >  > second paragraph:
> >  >
> >  > "prefix list is complete if all the prefixes belong to it"
> >  > Could we add 'on-link' before prefixes?
> >  
> > No. We will also consider the prefixes whose on-link bit is 
> not set. 
> 
> The on-link prefixes are all the prefixes on the link, not 
> just those where all neighbours are on link (on-link flag set).
> 
> Perhaps we need to say:
> 
> "prefix list is complete if all prefixes on the link belong to it"
> 
> >  > (3.1)
> >  >
> >  > Paragraph 4:
> >  >
> >  > The behaviour of sending all prefixes in solicited RAs 
> is defined  
> > > in RFC2461, and is a SHOULD.
> >  > 'every router ... would receive the RS and reply with 
> all the prefixes'
> >  > Is therefore not entirely correct, since routers may 
> choose not  > 
> > to send all prefixes.  changing 'would' to 'should' is better.
> >  > The second paragraph should therefore cite RFC 2461.
> >  >
> >  > If the citation is there, you could even say 'SHOULD'.
> >  
> > Hmmm. I tried to describe the way that routers generally operate.
> > No mandating was intended.
> >
> Well, the text is then wrong, since that's not how routers work.
> 
> It's how they should work, which is different.
> 
> >  > Paragraph 7
> >  >
> >  > The description of collection of additional groups of 
> RA's from  > 
> > a subsequent RS tends to give the idea that the RA sets are  > 
> > compared after the end of a 4 second RS interval.
> >  
> > It is the unintended impression. I tried to describe the 
> end result, 
> > the union of all prefix sets, not how the end result is achieved.
> 
> Indeed, although we're able to recommend a process to achieve 
> a goal, since host performance is based on this.
> 
> > [omitted]
> >  
> >  > (5th last paragraph)
> >  >
> >  > I do not agree that with the statement in this sentence.
> >  > This is not the safest, but the simplest method.
> >  > It can lead to false prefixes being added to the current 
> prefix list.
> >  
> > I agree. I substitute it with the simplest.
> >  
> >  > (3rd and second last paragraphs).
> >  >
> >  > Are we still talking about rapid movement?
> >  >
> >  > If we have a good prefix list which doesn't contain  > 
> superfluous 
> > prefixes, no link-up hint is required  > to determine link change 
> > (since the newly received RA  > comes from a different 
> router/has no 
> > prefixes in common).
> >  
> > This is about how to prevent superfluous prefix list. 
> Without link-up 
> > hint, it's difficult for a host to keep its prefix list including a 
> > false prefix.
> 
> Actually, it's not, as described below.
> 
> >  > Since we cannot immediately identify if link change has 
> occurred  > 
> > after sending an RS (no llink-up hint), subsequent (n*RS)  > 
> > retransmission can be used to can be used to identify if a  
> > router 
> > is really part of the set (since if a router doesn't  > respond the 
> > second and third time it may be on the old link).
> >  > If we're not sure, exclude them, and don't treat the 
> prefix list  > 
> > as complete.
> >  >
> >  > It makes sense to exclude routers from the list we're not sure 
> > about,  > at the cost potential false positive attachment detection 
> > events,  > since the cost is so much lower than the 
> situation where we 
> > have a  > false negative.
> >  
> > The above is not clear to me. The prefix list doesn't 
> contain a router 
> > (address, I guess.) at all.
> 
> We need to keep separate lists until we can determine if the 
> lists belong to the same link.
> 
> Otherwise we'll get highly undesirable fake entries in the list.
> 
> This doesn't preclude collecting the information without L2 
> Hints, and just reconciling them after attempting to build a 
> new prefix list.
> 
> I'm loathe to mandate requiring Link-layer hints to provide 
> basic DNA function.
> 
> >  > (3.2)
> >  >
> >  > I think there's too much caution here regarding the 
> identity  > of 
> > a link when we have a CPL.
> >  >
> >  > If we're fairly sure (99.97% from section 4) that we know all  > 
> > the prefixes on a link, reception of any single RA which  > doesn't 
> > contain any prefixes in the CPL confirms movement  > 
> (except in about 
> > 00.03% of the cases)  >  > We shouldn't wait around sending 
> out RS's 
> > and RAs unless  > we need further information from this router.
> >  >
> >  > This is the case even if there is no link-up trigger  > 
> (although 
> > as mentioned in 3.1, building this list may  > be more difficult if 
> > multicast RA is used).
> >  >
> >  > So long as we're fairly confident that we have a CPL,  > 
> we should 
> > accept the false positive as an attachment detection  > 
> event, because 
> > waiting 4 seconds to check takes too long, and  > the cost of false 
> > positive is lower.
> >  
> > Right. When hosts can be sure of the completeness of the 
> prefix list, 
> > it can base DNA decision on a single RA. The choice is theirs.
> 
> Indeed.
> 
> The draft should say so explicitly.
> 
> >  > first half of page 11:
> >  >
> >  > My comments about waiting to compare each set of 
> receivers  > from 
> > above also applies here.  Merging the sets can wait  > until it is 
> > safe to do so, comparing doesn't have to.
> >  >
> >  > Even in the case we've not got a complete prefix list 
> (but have  > 
> > a PL), we can still use this for more than a hint if we 
> receive  > an 
> > RA with no prefixes in the PL.
> >  > This may be a false positive movement, but conceivably 
> we can  > RS 
> > at the same time, as we BU (or perhaps we RS'ed because we got  > a 
> > link-up before CPL creation completed).
> >  > In this case, the first RA can initiate configuration  > 
> procedures 
> > if we've got any confidence in the existing PL (99% not  > 
> required).  
> > Subsequent RAs would either help build the pref ix list  > 
> on the new 
> > link, or complete the prefix list of the old.
> >  
> > Right.
> >  
> >  > last part of page 11:
> >  >
> >  > Renumbering can be handled by putting lifetimes in each 
> Prefix, and  
> > > updating them when received in an RA.
> >  > The CPL can remove prefixes which are no longer 
> advertised,  > but 
> > keep Lifetime 0 advertised prefixes in the cpl until they are  > no 
> > longer advertised (as described in section 12 of RFC2461).
> >  >
> >  > More complicated procedures aren't necessary.
> >  > Certainly link hints aren't required because of renumbering.
> >  
> > Renumbering is a problem when a router starts advertising a 
> new prefix 
> > that may cause hosts to falsely assume a link change. The 
> paragraphs 
> > are about this problem.
> 
> Renumbering isn't a problem, since the old prefix will be 
> advertised for a period with 0 lifetime.
> 
> These prefixes can't be assigned to another link in the mean 
> time, and so don't cause any harm.
> 
> It is simple enough to change the CPL when the prefixes are retracted.
> 
> >  > Section 4.
> >  >
> >  > This doesn't indicate:
> >  >
> >  > 1 Assumption of independence of packet loss events.
> >  >
> >  > 2 That RS losses are disregarded (since no RA is received, the
> >  >   MN suspects it may have been lost).
> >  
> > We tried to indicate the above in the below.
> >  
> >    We assume there is a host, H, and when the host sends a Router
> >    Solicitation, let P be the probability that it fails to receive a
> >    RA[i], whether because of a RS loss or a RA loss.
> 
> Then the packet loss probabilities for each RA aren't 
> independent, and you can't use the calculations mentioned.
> (since loss of one RS affects multiple RAs equally).
> 
> It's better to say that RS losses aren't counted and don't 
> matter for the calculation.
> 
> >   > section 6
> >  >
> >  > The first paragraph is from [7], please cite it.
> >  
> > ok
> >  
> >  > second paragraph is a bit stilted:
> >  >
> >  > The threats specific to DNA is that an attacker might 
> fool a node 
> > to  > detect the attachment to a different link when it is in fact 
> > still  > attached to the same link, and conversely, the 
> attacker might 
> > fool a  > node to not detect the change of a link.
> >  >
> >  > suggested replacement:
> >  >
> >  > The threats specific to DNA are that an attacker might 
> fool a node 
> > to  > detect attachment to a different link when it is in 
> fact still  
> > > attached to the same link, and conversely, the attacker 
> might fool a  
> > > node to not detect link change.
> >  
> > ok. But in the last line, I prefer 'detect the change of a 
> link'. As 
> > written before, now I avoid the expression 'detect link change'.
> 
> OK. This is actually a language issue I think.
> 
> Perhaps we can rephrase it, since it doesn't sound natural at 
> all with that text, and my proposal may have difficulty being 
> read by others with different language backgrounds.
> 
> The link itself hasn't changed.
> so 'the change of a link' doesn't sound right.
> 
> perhaps it could say:
> 
>   "The threats specific to DNA are that an attacker might 
> fool a node to
>   detect attachment to a different link when it is in fact still
>   attached to the same link, and conversely, the attacker might fool a
>   node to not detect attachment to a new link"
> 
> 
> >  > third paragraph:
> >  >
> >  > Strictly speaking, we're not talking MIPv6, so CoA's  > aren't 
> > required terminology, but I think I get your point.
> >  >
> >  > s/to register new/to register a new/
> >  
> > ok
> >  
> >  > s/from detecting any new link/from detecting a particular link/
> >  
> > We talked this before. I don't see the point of adding 
> 'particular' yet.
> 
> I think the problem may actually stem from the use of 'any'.
> perhaps we could replace it with 'a'.
> 
> >  > I'd reverse the sense of the statements:
> >  >
> >  > "...The protocol as specified would require an attacker to be
> >  >     on-link and be authenticated and authorized to send router
> >  >     advertisements when Secure Neighbor Discovery [9] is 
> in use.  But
> >  >     even without SEND, an attacker would need to send router
> >  >     advertisements containing the prefixes to which it 
> wants the host to
> >  >     be unable to detect movement.  This can be done for 
> a small number of
> >  >     prefixes, but it isn't possible for the attacker to 
> completely
> >  >     disable DNA for all possible prefixes on other links.
> >  > ..."
> >  >
> >  > to:
> >  >
> >  > "...
> >  > When SEND is not in use, an attacker could send router  > 
> > advertisements containing prefixes to which it wants  > the 
> router to 
> > be unable to detect movement. This can  > be done for a 
> small number 
> > (<=45) of prefixes, but it  > may not possible for the attacker to 
> > completely disable  > DNA for all possible prefixes on other links.
> >  > When Secure Neighbor Discovery [9] is in use, am 
> attacker  > would 
> > have to be on-link, authenticated and authorized  > to send router 
> > advertisements.
> >  > ..."
> >  
> > I think this is a matter of taste.
> 
> I prefer to think the issue is taste and style.
> 
> When reversed the sense of the paragraph is:
> 
> There are potential problems with the method.
> These can be rectified with SEND.
> 
> Otherwise (as origianlly phrased), the statement is:
> 
> You need to use SEND but if you don't bad things will happen.
> 
> The second part seems redundant.
> 
> It's also nice to avoid starting sentences with a But.
> 
> 
> >  > section 7.1
> >  >
> >  > s/frequence /frequency /
> >  
> > ok
> >  
> >  > section 7.2
> >  >
> >  > As explained before, once we've built a complete prefix 
> list  > (or 
> > one which we can predict from our RS'ing is likely to be  > 
> complete 
> > for each router: the chance of losing all RAs from a  > particular 
> > router is P(loss)^T, if there's no RS loss),  > then 
> there's no need 
> > to wait for the RAs containing P5,P6 and P7.
> >  >
> >  > We know (to within a confidence margin) that the RA 
> indicates  > a 
> > new link when we receive P4.  If P4 is an acceptable prefix to  > 
> > configure, we should do so.
> >  
> > The problem is that a host can't be 100% sure that it has 
> the complete 
> > prefix list. So complication. If only it can be sure of it without 
> > ambiguity, we can stream down the protocol substantially. But that 
> > needs new standard extension, maybe a new bit.
> 
> 
> No we don't need a new bit (You and I proposed that a long 
> time ago and CPL is significantly better than that).
> Extensions should wait until we've got standards track work 
> going.  If we've got to define new information, there may be 
> better ways of doing it. In that case we'd have to plan a solution.
> 
> I'd like to stress the point that we don't need to be 100% 
> sure about the completeness of the prefix list, and that 
> we're undervaluing CPL if we do so.
> 
> What we have to do in the WG is engineer a solution which has 
> close to best mean case performance (upon link change), and 
> good worst case behaviour.
> 
> If we perform a spurious handover 3 times in every 1000 as in 
> your example, then that's probably 'good enough'.
> 
> Any extra signalling to reduce the chance of incorrect 
> handover represents a diminishing return, and the cost of 
> extra signalling will be incurred every time we check.
> 
> We may even be able to stand 5% spurious handovers, since in 
> the spurious handover case, there's no interruption to packet 
> reception during that period.  (I'm not recommending this as 
> a goal, but illustrating).
> 
> I believe CPL should provide a 'good enough' solution which 
> reduces the number of spurious handovers, and provides fast 
> link change detection.
> 
> I think ensuring that prefix list state is complete (as 
> opposed to estimated as roughly complete) is actually 
> damaging because of the  duration and signalling required to 
> ensure the completeness.
> 
> Greg
> 
>