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

[Greg Daley <greg.daley@eng.monash.edu.au>]

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