(Oops, sent from wrong account--sorry for the repeat.)
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rserpool-threats-09
Reviewer: Ben Campbell
Review Date: 2008-04-08
IETF LC End Date: 2008-04-14
IESG Telechat date: (if known)
Summary: This document is not ready for publication. It may or may not
be on the right track, depending on the answer to my first comment.
Comments:
--General:
It is not clear to me what this draft seeks to accomplish. Without
being an expert in RSerPool, it is not clear to me if the draft
intends to offer requirements for new security mechanisms into the
RSerPool protocol itself, or to offer guidance to implementors on how
to securely implement the protocol.
If the former, then it is vague in many places, but is probably on the
right track. However, would this mean that the other rserpool
documents currently in last call will need significant changes
indicated by _this_ draft? That is, if this draft progresses then the
other are by definition not ready? (I fully admit not knowing the
details of those drafts.)
If the latter, then it is not helpful in its current form, as the
offered requirements say nothing about what mechanisms to use. I will
offer more details below
The document does not use normative language, nor does it reference
RFC 2119. I know normative language is not always required for
informational RFCs, but it seems appropriate for this document, since
it offers up important security requirements.
It seems like a lot of references are missing (e.g. ENRP, ASAP, etc.)
--Specific Comments:
Section 1:
The purpose of the draft is not clear from the introduction (See
general comment above).
It would be nice to see a background paragraph describing what
RSerPool is. There is a quick mention in the abstract, but the
document should be "complete" without the abstract.
The introduction needs some references. (Actually, as far as I can
tell the entire document is devoid of references.)
Section 1.1:
Definitions for "internal agent" and "external agent" would be helpful.
Section 2.1.2:
The first sentence is a sentence fragment. This occurs in many of the
"Effect" sections--I am not going to repeat this comment each time,
but please proofread for this. The RFC Editor will probably fix it,
but it's always nice to save them work.
Section 2.2.2:
The attack is characterized as a DoS. The described attack allows data
interception, which makes it a lot more than a DoS attack.
Section 2.3.2
s/hacker/attacker (throughout the document.)
Section 2.3.3
This section needs more discussion. Is it possible for an
authenticated PE to send misinformation about another PE? Is this also
an authorization issue?
Section 2.4.3:
Authorized to do what? I can infer that from the previous section, but
the requirement should be explicit.
Section 2.5.3
Is this really just an authentication issue? Is it enough to know the
identities? Are there authorization decisions here?
Section 2.5.3: What does the attacker need to do to accomplish this
attack?
Section 2.6.3
Is this advice to the implementor? If so, the document should describe
what mechanism to use to authenticate the server. Or is the intent to
say that the RSerPool protocol does not provide such a mechanism and
needs to do so?
Section 2.8.3:
Same question about mechanism as in my previous comment.
Section 2.9.1:
I do not know the RSerPool details, but I would assume that if PE A
could take over for PE B for a given user, the user would have to have
the same trust relationship with PE B as for PE A. Is the point of
this section to say that RSerPool does not require this and should?
Section 2.9.2:
The "Effect" section seems to simply restate the "Threat" section.
What are the actual consequences of the attack?
Section 2.9.3:
Are you saying that RSerPool fails to give tools so that a user can
establish the correct trust relationships with the new server when
failing over and needs them? Or do you mean to say that implementation
should use certain tools to do this? If the second, please call out
the mechanism.
Section 2.10.1:
Is this one threat, or three different threats?
2.10.2:
What are the consequences of corrupt information in this case?
2.10.3:
Section needs more specifics. Which interfaces need integrity
mechanisms? I can probably infer that from the Threat and Effect
sections, but a "requirement" should state it explicitly.
2.12.-1 and 2.12.2:
The organization of these sections is confusing, and not consistent
with that of the earlier sections. It is not clear to me how the
effects line up with the threats. That is, is effect a. related to
threat a., or is it related to all listed threats?
2.12.1 a.
How would the attacker do this? Does it require a MiTM?
2.12.1 c.
How does the attacker make such a claim?
2.12.3:
None of the attacks described in 2.12.* seem to be about
confidentiality per se.
2.13.1:
s/"These messages"/"Endpoint unreachable messages"
Also, under what circumstances would a PU cause a message flood? Does
the non-malicious case require an incorrect implementation?
2.13.2:
Section needs more detail? What service is denied, and to whom?
2.14.1:
s/"These Messages"/"Endpoint keep-alive messages"
Also, Is this not really the a consequence of 2.13, rather than a
separate attack?
2.14.2:
Section needs more detail? What service is denied, and to whom?
Section 3:
The first paragraph says that it will be noted which mechanisms are
required vs optional. Unless I missed something, the document does not
do this in any formal way. I think this would be a good use of RFC
2119 normative language.
Section 3.1 and 3.2
It seems to me that sections 3.1 and 3.2 belong in the main body of
the document.
Section 5:
As far as I can tell, none of the references are actually referenced
anywhere in the document.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf