Gen-ART Last Call review of draft-ietf-rserpool-threats-09

(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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf