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.