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

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

Hi JinHyeock (et al).

I think that it's best to discuss general ideas before
going into specifics.

Firstly, I think that maintaining a set of on-link
prefixes is a good idea.  The BCP draft attempts to
capture this in a less rigourous way in section 7.4
(page 22) for comparison.

I think that the idea which comes out in this draft
is that an MN having completeness of RA information
is very useful, and once an MN has what it considers
'complete' information.

There are several places where I differ in opinion
to the document, but I hope to explain these in my
review later.


Additionally, I largely agree with Samita's comments
on the document (although I guess there needs to be
discussion about hints and completeness timing, 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 :)


There are some issues raised by Samita which seem to
have been overlooked or missed in the responses to comments,
so I'll try to get my view on them down below here.



Review.
-------

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

(3.)

second paragraph:

"prefix list is complete if all the prefixes belong to it"
Could we add 'on-link' before prefixes?

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

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.

This is unnecessary, as the main issue is to get additional prefixes,
rather than checking if there are set changes.  Comparing each
RA as it arrives is better for this purpose, and allows
intermediate results for prefix lists to be used (with lower
confidence) even in the case of incomplete router probing.

Of course, if there has been a link transition between RS's there
may be some danger of just adding RAs without prefixes in common
with others. If any single RA which can be correlated to a later
RS contains a prefix in common with the PL, all routers so far
known to be discovered from the same RS belong to the PL.

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


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

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.



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


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 prefix list
on the new link, or complete the prefix list of the old.

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.



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

section 6


The first paragraph is from [7], please cite it.

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.

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/

s/from detecting any new link/from detecting a particular link/

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


section 7.1

s/frequence /frequency /

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.

Greg