[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt
Dear Margaret
We discussed with Thomas to address his discuss and believe
that we have reached an understanding.
We reflected IESG review, both discuss & comments, to update
the draft and the current version is available at
http://www.diffeo.com/drafts/draft-ietf-dna-goals-04.txt
Kindly find in-line comments.
> Discusses and Comments
> Harald Alvestrand:
> Comment:
> [2004-12-01] Reviewed by Spencer Dawkins, Gen-ART
>
> Only one serious concern raised, about the ambition level of goals:
>
> 3. Goals for Detecting Network Attachment
>
> The DNA working group has been chartered to define an improved scheme
> for detecting IPv6 network attachment. In this section, we define
> the goals that any such solutions should aim to fulfil.
>
> DNA solutions should correctly determine whether a link change has
> occurred. Additionally, they should be sufficiently fast so that
> there would be no or at most minimal service disruption. They should
> neither flood the link with related signaling nor introduce new
> security holes.
>
> Spencer - concern - is this high-level "should be sufficiently fast"
> consistent with the 1.5-2-second delays described in section 2 of
> this document? I guess I'm asking, is interactive voice clearly in
> scope/out of scope?
1.5-2 second delays in Sec 2 indicate the current state of art.
They are the delays related to particular DNA schemes. DNA
process can be faster & interactive voice is clearly in scope.
> Russ Housley:
> Comment:
> [2004-12-01] In section 3.1, G8: s/man in the middle/man-in-the-middle/
ok.
> Allison Mankin:
> Comment:
> [2004-12-02] Good, clear document
>
> The IAB has a good document that's worth your reviewing, including issues
> of links that can be confusing about whether there is a change or not:
>
> draft-iab-link-indications-00.txt
Thanks.
> Thomas Narten:
> Discuss:
> [2004-12-02] These are all pretty minor, so should be easy to fix.
>
> > Detecting Network Attachment in IPv6 Goals
>
> change to something more readable?
With Thomas' suggestion, we have changed the title to
Goals of Detecting Network Attachment in IPv6
> > When a host has established a new link-layer connection, it can send
> > and receive some IPv6 packets at the link, particularly those used
> > for configuration. On the other hand, the host has full Internet
>
> s/at the link/on the link/
> s/particularly/including/
ok.
> > detects the identity of its currently attached link to ascertains the
>
> s/ascertains/ascertain/
ok.
> > refer [10].
>
> s/refer/refer to/ (or "see")
ok.
> > difficult for a single RA message to indicate a link change. Third,
> > Router Discovery may take too long and result in service disruption.
>
> clarify? are there some unstated assumptions being made here? e.g.,
> why doesn't a host just send out an RA immediately upon detecting a
> link up? Is this "too long"?
After discussing with Thoams, we have changed the above to
............................................. Third, the current
Router Discovery
specification specifies that routers wait a random delay of 0-.5
seconds prior to responding with a solicited RA. This delay can be
significant and may result in service disruption.
> > Usually a host gets the information necessary for IP configuration
> > from RA messages. Based on the current definition [1], it's
> > difficult for a host to check for link change upon a single RA
> > reception.
>
> True, but there are huristics that make good hints. Not absolute, but
> good hints.
We wish to make those good hints into better confirmation.
We found out that a few factors such as 'link-local router address'
or 'prefix omission', may result in a false link change detection.
We explained more about the difficulties/ ambiguities concerning link
identity detection with a single RA reception in Sub-sec 2.2 'Link
identity detection with a single RA'.
> > Before a host sends an initial solicitation, it SHOULD delay the
> > transmission for a random amount of time between 0 and
> > MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router
> > Advertisement sent in response to a Router Solicitation MUST be
> > delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
> > seconds).
>
> is this text quoting another RFC? If so, please make that clear. Or,
> is this document defining normative behavior (which is probably
> inappropriate for this document).
After discussing with Thoams, we have changed the above to
According to RFC 2461 [1]:
- before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY (1 second).
- Furthermore, any Router Advertisement sent in response to a Router
Solicitation MUST be delayed by a random time between 0 and
MAX_RA_DELAY_TIME (0.5 seconds).
> > G2 When upper-layer protocol sessions are being supported, DNA
> > schemes should detect the identity of an attached link with
> > minimal latency lest there should be service disruption.
>
> What does this mean? In particular, if the intention is that
> upper-layer communication failures should trigger DNA action, I
> suspect that is not a good idea.
No, that is not our intention.
We put 'upper-layer' part to underline the necessity of a fast DNA
procedure. However, it seems that the part is not so much illuminating
as confusing. So we have removed the part all together as below.
G2 DNA schemes should detect the identity of an attached link with
minimal latency lest there should be service disruption.
> Bert Wijnen:
> Comment:
> [2004-12-02] *** matchref -- match citations and references.
> Input file: draft-ietf-dna-goals-03.txt
>
> !! Missing citation for Normative reference:
> P013 L013: [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
>
> !! Missing citation for Informative reference:
> P013 L031: [7] Droms, R., Bound, J., Volz, B., Lemon, T.,
> Perkins, C. and M.
>
> !! Missing citation for Informative reference:
> P013 L035: [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP
> Security Document
We have removed all un-cited refs.
> Additional comments from OPSDIR review (by Pekka):
>
> This is a good document.
>
> Substantial issue:
> ------------------
>
> G1 DNA schemes should detect the identity of the currently attached
> link to ascertain the validity of the existing IP configuration.
> They should recognize and determine whether a link change has
> occurred and initiate the process of acquiring a new configuration
> if necessary.
>
> ==> This may be worth a bit more discussion, and/or splitting to two
> Goals. Is it an explicit goal that the DNA scheme gets 100% certainty
> whether a link change has occurred? Or would it be OK to initiate the
> IP reconfiguration event even if you've received a reasonably strong
> hint about it (e.g., the link-local or link-layer addresses of a
> router has changed)?
We aims 'No false positive' but, if necessary, a reasonable false
error rate is acceptable. WG will decide what reasonable/ acceptable
error rate will be. We plan to design a DNA scheme with negligible,
hopefully infinitesimal, error rate.
> To me, it would seem that in most cases it would be very useful if one
> would not have to reach absolute certainty of what has happened: the
> typical IP configuration procedures actually work just fine (there's
> just a bit of extra signalling) even if there has not been an actual
> link change.
It may be ok for a host to falsely assume a link change when it
remains at the same link. However, the inverse case that a host
fails to detect a link change may cause more serious problem.
For example, if a host checks for link change with the link-local
address of its default router, it may fail to detect a chance and
experience a service disruption.
> Section 2.3:
> [...]
> Before a host sends an initial solicitation, it SHOULD delay the
> transmission for a random amount of time between 0 and
> MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router
> Advertisement sent in response to a Router Solicitation MUST be
> delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
> seconds).
>
> ==> The text should be clearer that the uppercase keywords are just
> quoting the specification from RFC2461, not that this spec is making a
> specification of its own (without defininng the RFC2119 keywords).
ok.
> 5. Security Considerations
>
> Because DNA schemes are based on Neighbor Discovery, its trust models
> and threats are similar to the ones presented in RFC 3756 [6].
>
> ==> this is not given, because we don't know what the DNA scheme will
> be; using existing mechanisms is also just a goal. A bit of rewording
> needed here.
We have changed the above to
DNA process is intimately related to Neighbor Discovery protocol [1]
and its trust model and threats have much in common with the ones
presented in RFC 3756 [5].
Kindly let us know if there still is a blocking issue for the draft.
Thanks in advance for your kind consideration.
Best Regards
JinHyeock