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

[JinHyeock Choi <jinchoe@diffeo.com>]

Dear Greg

Kindly fine my in line comments. 

[omitted]
> I think this is important to work through,
> so please don't be offended if I speak plainly.

Don't worry about it. It's my policy not to be offended by honest 
and correct feedbacks. (This doesn't mean they don't hurt. :-))

Also I make the same request. I wish we disagree in an agreeable 
way like gentlemen. :-)

[omitted]
> > 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.

ok. Let me clarify it. 

While a host performs DNA procedure, if it receives a prefix in the 
existing prefix list, that confirms that it still remains at the same link.  

> >  > 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).

Hmmm. Is this the official & widely accepted definition of on-link prefix? 
I am afraid we encountered an another terminology ambiguity. Erik wrote 
the following phrases and he is a co-author of RFC 2461. 

                                           this specification uses
   both 'on-link' and 'addrconf' prefixes [4], that is, prefixes that
   have either the 'on-link' flag set, the 'autonomous
   address-autoconfiguration' flag set, or both flags set.  
  
> Perhaps we need to say:
> 
> "prefix list is complete if all prefixes on the link belong to it"

ok. I agree that is more clear. 
 
> >  > (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.

Kindly take notice of the word 'GENERALLY'. I think that's how 
routers generally work, even though not always. Also even it is 
'SHOULD' instead of 'MUST', I can't imagine a case that a router 
would send only a partial list of prefixes.  

But if that makes you still uncomfortable, I will change the above with 
'every router ... would receive the RS and USUALLY reply with all the
prefixes'. I wish you think that this is rigorous enough. (You don't seem 
like a person who is not afraid to be less rigourous. :-))

> >  > 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.

ok. 
 
[omitted]
> >  > (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.

Sorry I found typo errors. What I tried to say is 

Without a link-up hint, it's difficult for a host to keep its prefix list 
from including a false prefix list with certainty. 

Do you disagree with that? 
 
> >  > 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.

Kindly elaborate how a host can divide the collected prefixes into separate lists. 
In other words, how a host can keep separate prefix lists such that each prefix 
list contains only the prefixes on the same link? With what criterion a host can 
classify prefixes?  

It takes time to collect the prefixes on the link. A host can't collect all 
the prefixes instantly. So before the host completes the collecting process, 
if it happens that it moves to a new link without its knowledge, and, it 
will generate the prefix list containing the prefixes from two different links. 
 
> I'm loathe to mandate requiring Link-layer hints to provide
> basic DNA function.

What do you mean by basic DNA function? BCP or Solution/ Extension 
or others?

For me, it's ok to recommend link-layer hints to provide efficient 
DNA schemes. 

> >  > (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.

Actually it does. Kindly look at the end of Sec 3. 

   In summary, first a host makes the complete prefix list.  When a hint
   occurs, if the host decides that the prefix list is complete, it will
   check for link change with just one RA (with a prefix).  Otherwise,
   in case that the host can't be so sure, it will perform additional
   RS/ RA exchanges to corroborate the decision.

   [omitted]

   In this way, we may provide a fast and robust solution.  If a host
   can make the complete prefix list with certainty, it can check for
   link change fast.  Otherwise, it can fall back on a slow but robust
   scheme.  It is up to the host to decide which scheme to use.

[omitted] 
> > 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.

Renumbering is a problem when a router starts advertising a new prefix, 
not when the old 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.

You are right. Your suggestion will keep the analysis simple 
without hurting the correctness too much. Thanks. 

[omitted]
> >  > 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"

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'.

ok. 
 
> >  > 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.

We are of different opinions. It seems to me that the original 
phrase means

When SEND is in use, an attacker need to satisfy certain conditions 
to attack. (1st part) 
Even when SEND is not in use, an attacker still need to satisfy other
conditions to attack. (2nd part)  

> It's also nice to avoid starting sentences with a But.

ok.  

[omitted]
> 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.

I agree that it would be the solution work to enhance CPL to design 
a way to efficiently generate the complete prefix list with certainty. 

Thanks for your detailed comments that make the draft more clear. 

Best Regards

JinHyeock