Re: [Mobopts] review of <draft-irtf-mobopts-ro-enhancements-06.txt>

Hi Juergen,

thanks for your detailed review.  I revised
draft-irtf-mobopts-ro-enhancements-06.txt according to your
suggestions.   Below are some comments and change logs, and here is a
link to the updated draft version:

http://doc.tm.uka.de/2006/draft-irtf-mobopts-ro-enhancements-07.txt

> I have reviewed <draft-irtf-mobopts-ro-enhancements-06.txt> and I 
> believe this document is basically ready for publication. It contains
>  a nice survey of MIPv6 optimizations which I consider useful. Note 
> that I am not an MIPv6 expert - I understand its basic principles,
> but my expertise clearly lies in other areas.
> 
> Given my background, I would have loved to see also some discussion
> of operational issues of the various approaches (kind of management 
> considerations), that is, how difficult will it be to debug problems,
>  what needs to be configured where, when and by whom, what needs to
> be monitored to detect abuse or ongoing attacks, etc. On the
> operational side, simplicity usually wins and hence understanding the
> management impact of the various proposals is IMHO an important
> criterium for the evaluation.

While the main focus of this document is an analysis of the pros and
cons of different mechanisms with respect to handoff latency, security,
and signaling overhead, it also weighs the mechanisms' efficiency with
administrative requirements and deployment costs.  So, yes, the document
needs to consider administrative issues.

The trade-off between the mechanisms' effectiveness (small handoff
latency, strong security, reduced signaling overhead) and their
deployment and administration costs is already considered in different
parts of the document.  But this may not always be as prominent as it
should be.  Especially, the introduction of section 4 was lacking some
more attendance to this matter.  Here is how I modified it:

4.  Discussion

   Common to the proposals discussed in Section 3 is that all of them
   affect a trade-off between effectiveness on one hand and economical
   deployability, administrative overhead, as well as wide applicability
   on the other.  Effectiveness may be equated with low latency, strong
   security, reduced signaling, or increased robustness.  Economicalness
   implies no, or only moderate, requirements in terms of hardware
   upgrades and software modifications.  Administrative overhead relates
   to the amount of manual configuration and intervention that a
   technique needs.

   The standard return-routability procedure avoids costly pre-
   configuration or new network entities.  This minimizes both
   deployment investments as well as administrative expenses.  Variants
   with optimistic behavior and proactive or concurrent IP-address tests
   have these advantages as well.  CBIDs allow for public-key
   authentication without a public-key infrastructure.  They constitute
   a more secure alternative to home-address tests and are as such most
   effective when combined with concurrent reachability verification.
   CBID-based authentication may require nodes to be programmed with a
   mapping between human-readable identifiers and the corresponding
   CBIDs.  Pre-configuration is another approach to avoid home address
   tests.  It does without computationally expensive public-key
   algorithms, but requires pair-wise credentials and, therefore,
   administrative maintenance.  Where suitable infrastructure is
   available, end nodes may delegate authentication and encryption tasks
   to trusted network entities which, in turn, vouch for the end nodes.
   Delegation could resurrect the use of certificates for the purpose of
   mobility support.  But it introduces a dependency on the delegatees,
   adds the provisioning costs for new network entities, and is likely
   to be limited to communities of authorized nodes.

> I have a more general observation I like to raise: I counted 29 
> citations of Internet Drafts out of 62 citations in total, which
> means almost 47% of all citations are "work in progress". I checked
> up to reference 22 and it seems that 5 out of the 17 cited IDs among
> the first 22 references have already expired. How much should we be 
> concerned about publishing an RFC which points to quite a bit of 
> documents not really archived (in the sense that there is not a 
> defined entity in charge of maintaining access to the cited 
> documents)? This issue clearly has a wider scope and may require some
>  discussion or a policy within the IRTF as a whole. I did not go back
>  to the document to check what the purpose of those citations are,
> that is, whether the main optimization idea is sufficiently
> summarized in the mobopts draft under review so that the reference
> more serves as a way to give credits. In such cases, I would not see
> a problem. If, however, a reference is really needed to fully grasp a
> proposal, then having dangling pointers is kind of problematic.

Many of the discussed mechanisms were published only as Internet Drafts.
 This is unfortunate, given that the mechanisms are quite interesting
and would deserve more lasting documentation.

I went through the references and replaced the drafts to be journal
articles or conference papers wherever possible.  Authors of the
mechanisms under consideration may know better references, in which case
I would be happy to receive a note with a suitable BibTeX entry (or,
even better, Xref entry for the xml2rfc tool).

> Next to these quite general comments, I do have a few concrete 
> comments and editorial suggestions:
> 
> a) I suggest to move the first paragraph of section 1 to the end of 
> section one. I find it a bit strange to start an introduction by 
> explaining who has reviewed the document.

Not sure if it's a policy to have the consensus statement at the
beginning of the Introduction.  But you are right that the section
becomes more readable when the paragraph is at the end of the section.
So I moved it.

> After moving the paragraph, the first sentence in the now first 
> paragraph should be reworded so that it does start a bit more reader
> friendly and not just "RFC 3775 [42] specifies".

Done.

> b) Section 1.1 page 4 last line: Do you really mean "not reluctant"?

Thanks, yes.  s/not...reluctant/unwilling/

> c) Section 1.1 page 5 last bullet: s/in the certifications/in
> certificates

Ok.

> d) Section 1.2 page 6: introduce acronym BU the first time you use it
> 
Spelled out now.

> e) Section 2 surprises me. The usual convention is to acknowledge 
> contributors and reviewers at the end of an RFC but not in the 
> middle. I suggest to move this section to the very end. Note that 
> this also requires changes in the introduction.

Hmm, we put this section after the Introduction before we added the
consensus statement to the Introduction.  Should be ok to move the
Acknowledgments section down now that we have the consensus statement.

> f) Section 4.7 talks about the credit-based authorization approach 
> while 4.8 talks about heuristics. I am wondering whether credit-based
> authorization is no just another heuristic approach.

No, it's not.  CBA prevents amplification during a redirection-based
flooding attack.  In this, CBA is proactive and bullet-proof.  In
contrast, heuristics are by definition reactive.  They seek to identify
illegitimate behavior based on specific properties, and they may produce
false positives and/or false negatives.

> g) Section 5.2: I would like to know whether there are "standard" 
> scenarios people use in the community to compare the various 
> approaches. Ideally, such "standard" scenarios would be derived from
> real-world measurements. If such "standard" scenarios exist, it might
> be useful to point to them so that researchers can easily publish
> comparable results. If such "standard" scenarios do not exist, you
> might want to raise the construction of such things in order to
> produce comparable results as a potential future work item.

That's a good point.  Actually, there was a bullet item in section 5.2
that was somewhat related to this, namely:

   OLD:
   o  Measurements of a realistic network scenario, enabling all
      features that would likely be needed in a commercial deployment.
      These features include link-layer access control, for instance.

I modified this in the following way to also reflect your point:

   NEW:
   o  Conception of a set of standard scenarios that can be used as a
      reference for comparable measurements and experimentation.
      Ideally, such standard scenarios ought to be derived from real-
      world environments, and they should include all features that
      would likely be needed in a commercial deployment.  These features
      include link-layer access control, for instance.

> h) idnits complains that the document does not distinguish between 
> normative and informative references. I guess all references are 
> informative and I have no idea how strict today's rules are.

Yes, all references are of informative nature, except for RFC 3775.
Changed that.

> i) Reference [48] says "to be presented" and the date is November 
> 2004 - perhaps this actually got meanwhile presented?

Hmm, this is quite right. :-)

> j) Given my background, I would have loved to see also some
> discussion of operational issues of the various approaches (kind of
> management considerations), that is, how difficult will it be to
> debug problems, what needs to be configured where, when and by whom,
> what needs to be monitored to detect abuse or ongoing attacks, etc.

Yes, see my comments from above.

> k) Reference [45] seems to be a bit screwed up.

Yes, thanks.

> l) How useful is it to cite mailing list messages (I am referring to 
> references [59] and [60])? Are there no other suitable references for
> the "optimistic" approach?

I changed the references to a conference paper which, hopefully,
describes quite well what the optimistic approach is compared to the
conservative approach.  I have to emphasize that I am a co-author of
this paper, however.

> m) Where was [8] published?

This was re-published as draft-ietf-dna-protocol-00.txt.  Changed that.

Juergen, thanks again for your review.  It's greatly appreciated!

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Juergen Schoenwaelder wrote:
> Hi,
> 
> I have reviewed <draft-irtf-mobopts-ro-enhancements-06.txt> and I 
> believe this document is basically ready for publication. It contains
>  a nice survey of MIPv6 optimizations which I consider useful. Note 
> that I am not an MIPv6 expert - I understand its basic principles,
> but my expertise clearly lies in other areas.
> 
> Given my background, I would have loved to see also some discussion
> of operational issues of the various approaches (kind of management 
> considerations), that is, how difficult will it be to debug problems,
>  what needs to be configured where, when and by whom, what needs to
> be monitored to detect abuse or ongoing attacks, etc. On the
> operational side, simplicity usually wins and hence understanding the
> management impact of the various proposals is IMHO an important
> criterium for the evaluation.
> 
> I have a more general observation I like to raise: I counted 29 
> citations of Internet Drafts out of 62 citations in total, which
> means almost 47% of all citations are "work in progress". I checked
> up to reference 22 and it seems that 5 out of the 17 cited IDs among
> the first 22 references have already expired. How much should we be 
> concerned about publishing an RFC which points to quite a bit of 
> documents not really archived (in the sense that there is not a 
> defined entity in charge of maintaining access to the cited 
> documents)? This issue clearly has a wider scope and may require some
>  discussion or a policy within the IRTF as a whole. I did not go back
>  to the document to check what the purpose of those citations are,
> that is, whether the main optimization idea is sufficiently
> summarized in the mobopts draft under review so that the reference
> more serves as a way to give credits. In such cases, I would not see
> a problem. If, however, a reference is really needed to fully grasp a
> proposal, then having dangling pointers is kind of problematic.
> 
> Next to these quite general comments, I do have a few concrete 
> comments and editorial suggestions:
> 
> a) I suggest to move the first paragraph of section 1 to the end of 
> section one. I find it a bit strange to start an introduction by 
> explaining who has reviewed the document.
> 
> After moving the paragraph, the first sentence in the now first 
> paragraph should be reworded so that it does start a bit more reader
> friendly and not just "RFC 3775 [42] specifies".
> 
> b) Section 1.1 page 4 last line: Do you really mean "not reluctant"?
> 
> c) Section 1.1 page 5 last bullet: s/in the certifications/in
> certificates
> 
> d) Section 1.2 page 6: introduce acronym BU the first time you use it
> 
> 
> e) Section 2 surprises me. The usual convention is to acknowledge 
> contributors and reviewers at the end of an RFC but not in the 
> middle. I suggest to move this section to the very end. Note that 
> this also requires changes in the introduction.
> 
> f) Section 4.7 talks about the credit-based authorization approach 
> while 4.8 talks about heuristics. I am wondering whether credit-based
> authorization is no just another heuristic approach.
> 
> g) Section 5.2: I would like to know whether there are "standard" 
> scenarios people use in the community to compare the various 
> approaches. Ideally, such "standard" scenarios would be derived from
> real-world measurements. If such "standard" scenarios exist, it might
> be useful to point to them so that researchers can easily publish
> comparable results. If such "standard" scenarios do not exist, you
> might want to raise the construction of such things in order to
> produce comparable results as a potential future work item.
> 
> h) idnits complains that the document does not distinguish between 
> normative and informative references. I guess all references are 
> informative and I have no idea how strict today's rules are.
> 
> i) Reference [48] says "to be presented" and the date is November 
> 2004 - perhaps this actually got meanwhile presented?
> 
> j) Given my background, I would have loved to see also some
> discussion of operational issues of the various approaches (kind of
> management considerations), that is, how difficult will it be to
> debug problems, what needs to be configured where, when and by whom,
> what needs to be monitored to detect abuse or ongoing attacks, etc.
> 
> k) Reference [45] seems to be a bit screwed up.
> 
> l) How useful is it to cite mailing list messages (I am referring to 
> references [59] and [60])? Are there no other suitable references for
> the "optimistic" approach?
> 
> m) Where was [8] published?
> 
> /js

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts