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

[JinHyeock Choi <adelaide_00@yahoo.com>]

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.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Best Regards

 

JinHyeock

---

Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.