[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Quick review of draft-jinchoi-dna-cpl-00.txt
Dear Greg
Thanks for kind and detailed feedback. I'll look
over it and reply.
Also this whet my appetite for your comments
on 'dna solution framework' more.
Best Regards
JinHyeock
----- Original Message -----
From: "Greg Daley" <greg.daley@eng.monash.edu.au>
To: <adelaide_00@yahoo.com>
Cc: "Samita Chakrabarti" <Samita.Chakrabarti@eng.sun.com>; "Erik Nordmark" <Erik.Nordmark@sun.com>; <dna@eng.monash.edu.au>
Sent: Tuesday, July 13, 2004 4:01 PM
Subject: [DNA] Quick review of draft-jinchoi-dna-cpl-00.txt
> 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
>
>
>