At Tue, 18 Nov 2008 13:22:02 -0600,
Fred Baker <fred@cisco.com> wrote:
> This is to initiate a two week working group last call of draft-chown-
> v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt. Please
> read these drafts now. If you find nits (spelling errors, minor
> suggested wording changes, etc), comment to the authors; if you find
> greater issues, such as disagreeing with a statement or finding
> additional issues that need to be addressed, please post your comments
> to the list.
I've read draft-chown-v6ops-rogue-ra-02.txt. While I think this can
be a useful document, I have a concern about its scope.
This document looks to me too generalized by attempting all kinds of
"rogue" behavior, and could lead to a misleading conclusion.
Specifically, it seems to me that by discussing 'malicious
misconfiguration' this document makes the whole discussion complicated
and distracting.
I thought the original motivation of this document was 'user
misconfiguration' that we've seen various places in actual deployment
of IPv6. I agree discussion in this scope makes sense and is useful.
But, have we really experienced 'malicious misconfiguration' of RA and
recognized it as a problem to be solved as a pragmatic sense? Of
course, this could be a real problem as discussed in RFC3756, and I
don't deny the value of discussing it per se. But since this is
essentially a security issue (while limited within a single link),
discussion on the solution will be much more complicated. For
example, it's not sufficient in this sense to just avoid a rogue
default router by some measure, because if it's a malicious attempt we
should also worry about other attacks such as stealing the L2 address
of a valid router using rogue NAs.
I understand this document notes limitations of possible solutions,
and I'm not arguing every document that discusses a rogue behavior
must provide a complete solution. But, in this specific case, it
overly dismisses solutions for non-malicious behavior (for which
we'd really want a workable solution) by introducing the consideration
on malicious (security) viewpoints. As an example, it states in
Section 3.5 ("Use the Router Preference Option") as follows:
This of course would only work in some scenarios - an attacker would
certainly seek to use High priority anyway - and would also rely on
clients having implementations of the protocol.
If our focus were limited to erroneous (i.e. not 'malicious') rogue
behavior, the discussion could be simpler and would in fact help many
people realistically. But by mentioning "attacks", this document
makes solutions sound much less promising.
(again) to be clear, I'm not saying we should ignore security
implications. But IMO the current content of this document tries to
be too generic (by including security topics) and makes useless
conclusions, while there can be realistic and useful solutions with
limitations wrt security that can be acceptable for certain users.
So, if it's okay to make this level of comment, I'd like to propose
either
a) remove the 'malicious misconfiguration' considerations (but
explicitly note they are out of scope somewhere, possibly in the
security consideration section), or
b) discuss cases limited to non-malicious misconfigurations
separately.
I have a few other minor comments that follow:
- Section 3.11
"Catch-22" sounds like a jargon to me. Can't this be a more
conservative word such as "dilemma"?
- Table in Section 4
I don't understand the "If Auth" entry for the "Admin Error"x"DHCPv6
gateway option" cell. What does "auth" mean here, and what kind of
"admin error" does it avoid? Doesn't authentication help when a
valid administrator misconfigures the DHCPv6 server with valid
DHCPv6 authentication?
- Section 5.5
e.g. considering the '2 hour rule' of
Section 5.5.3 of RFC4862 (though this applies to the prefix lifetime
not the router lifetime).
This is not 100% correct. The 2hour rule applies to the valid
lifetime of addresses. Using the term "prefix lifetime" could be
misleading because it may be interpreted as the lifetime of on-link
prefixes.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.