Document: draft-ietf-opsec-current-practices-07.txt Reviewer: Gray, Eric [Eric.Gray@marconi.com] Review Date: Wednesday 9/27/2006 4:34 PM CST IESG Telechat Date: 28 September 2006 Summary: This draft is nearly ready for publishing as an Informational RFC. Minimally, it needs a good grooming for editing mistakes. In fairness, most of the editing mistakes I noted occur in the up-front text sections (introduction, etc.) that may not have been thoroughly reviewed recently. This is a very useful work and I am glad to have had a chance to look it over in detail. Comments: ======== General comment(s) - ------------------ The introduction says that the draft is based on a survey. It would be useful to include a few generic statistics about the survey: when was it conducted, how many responses were received, other non-compromising information of that nature. I am not sure why we include L2 in the ID's scope (section 1.1) - you mention IPv4 and IPv6, but the document seems to ignore L2 security in at least a few key points. There is - for example - no mention of specific L2 technology information (as there is for L3). Also, some of the attack information appears to omit discussion of variations of attacks that apply to L2 networks. Section 1.2 ("Threat Models") - ----------------------------- Not all "attacks" are against "system security" - in fact, from a user perspective, attacks against "system security" matter only to the extent that they induce a "system security" failure (either directly, or as a distraction result). It seems to me that only attacks which affect availabilty of services, or confidentiality of information, can be deemed "successful" - although there is certainly room to include un-authorized use (even if it does not affect availability). As an analogy, someone's being in my yard without my permission is not a violation of my fences (or - in my case - stone walls). Section 2.2.1 ("Threats / Attacks") - ----------------------------------- I am not sure that I agree that "a topology subversion is required to reroute traffic and essentially bring the attacker on-path" - at least not within the L2/L3 scope of this draft. I believe a re-direction can be created through misrepresentative service advertisements at higher layers (not subverting L2/L3 topology at all) - such as occurs in phishing attacks. Section 2.3.4 ("Additional Considerations") - ------------------------------------------- On the topic of rate limiting, you make the statement "some [...] ISPs believe [rate limiting] is not really useful since attackers are not well behaved ([paraphrased]). What does this mean? Is it a reference to congestion avoidance? Can we make this explicit? NITs: ==== Section 1.2 ("Threat Models") - ----------------------------- Last sentence (starting with "Many of the threats to a network infrastructure occur ...") - "a network infrastructure" seems awkward. Perhaps "network infrastructure" or "a network"? Second paragraph (ending with "vulnerabilities") needs a period. Fourth paragraph - "Protocol Vulnerability Exploitation: An attack which takes advantage of known protocol vulnerabilities due to design or implementation flaws to cause inappropriate behavior" - the phrase "due to design or implementation flaws" appears to be parenthetical (and should be parenthesized). Fifth paragraph ("Message Insertion") - "reply" should be "replay" (wording of this parenthesized phrase is extremely awkward - containing the word "which" twice, omitting an article, etc.). Suggest instead: "(for example - a replay attack, which is a scenario where a message is captured and resent at a later time)." Seventh paragraph ("Message Modification") - this definition is awkward for several reasons. According to what I've been told by security experts, a man-in-the-middle attack is not an attack until a message modification occurs (eavesdropping is itself not a MITM attack) - consequently (for the MITM case), a message could be captured as part of a MITM attack (as opposed to "using a [MITM] attack"). Also, as worded now, the definition seems to exclude message modification as part of a "replay" attack variation. Finally, message modification seems to be part "Insertion" and part "Diversion/Deletion" - as opposed to being "a subset of a message insertion attack". I believe that - in the last paragraph of section 1.2 - you want to say "sometimes Denial of Service is listed as a separate attack category." Section 1.3 - ----------- When you say "can be sourced" do you mean "can originate" or "can be categorized" (I suspect the latter)? The subject matter does not seem to agree with the section name. Perhaps the section name should be "Attack Categories"? This comment (or question) applies generally to this section as you refer to attack "sources" in at least one other place in this section. The specific examples you list for "passive attacks" all start as "active attacks." This could be construed as an implication that purely passive attacks do not exist. Since you include L2 security in the scope for this ID, you could include L2 snooping - or promiscuous listening - on shared access networks as a purely passive form of attack. This goes to whether or not you should be including L2 security in the scope for this ID (see general comments above). Also, a device that is located in the same subnet with IGP routing devices can usually passively snoop on IGP routing traffic. In the last sentence in the sub-section entitled "On-path vs off-path attacks" - I cannot determine the purpose for the citing of RFC 3552 ("Guidelines for Writing RFC Text on Security Considerations") at the beginning of this sentence. Suggest omitting "or illegitimate" from the last sentence of the sub-section entitled "Insider or outsider attacks". In sub-section entitled "Deliberate attacks vs unintentional events" - you should use "perpetrator" instead of "miscreant" as a deliberate attack might occur legitimately (as a result of testing of network security, for example, and not be at all criminal, malicious or heretical). :-) Note: you use the term miscreant elsewhere in what appears to be a correct manner, so it is just this instance that might need to be changed. Section 1.5 - ----------- Last sentence in the section, suggest rewording "due to bugs or lack of ease of use" to something like - "due to bugs or insufficient ease of use." Section 2.2 - ----------- Last sentence needs a period. Section 2.4.2 - ------------- The list of included BGP routing policies would be easier to read as a list (with bullets) - as follows: "These include: o incoming and outgoing prefix filters for BGP customers, o incoming and outgoing prefix filters for peers and upstream neighbors, o incoming AS-PATH filter for BGP customers, o outgoing AS-PATH filter towards peers and upstream neighbors, o route dampening and rejecting selected attributes and communities." Section 2.4.4 - ------------- I think the last two words in the first paragraph should be "vendors' products" instead of "vendors products'" (single quote/apostrophe relocated). Alternatively, it could simply be "vendor products." Section 2.5.1.4 - --------------- The phrase "unbeknownst to them" is (I believe) parenthetical (and should be parenthesized). It is difficult to parse the entire sentence without first determining where the "pauses" should occur in reading it.