Last Modified: 2004-09-14
| Done | Submit initial I-D (or set of I-Ds) which details the threats to routing systems. | |
| Done | Submit I-Ds documenting threats to routing systems for publication as Informational RFC. | |
| Done | Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. | |
| Done | Recharter to include protocol-specific work. | |
| Done | Submit initial I-D describing BGP Attack-Tree analysis. | |
| Done | Submit initial I-D describing OSPF vulnerability analysis. | |
| Done | Submit initial I-D describing BGP security requirements. | |
| Oct 04 | Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. | |
| Oct 04 | Submit BGP Attack-Tree analysis for publication as Informational RFC. | |
| Oct 04 | Submit OSPF vulnerability analysis for publication as Informational RFC. | |
| Dec 04 | Submit BGP security requirements for publication as Informational RFC. | |
| Mar 05 | Evaluate progress, recharter with new goals or shutdown. |
|
----
Routing Protocol Security Requirements WG (rpsec) Tuesday, November 9 at 1300-1400 =================================== CHAIRS: Russ White <riw at cisco.com> Tony Tauber <ttauber at 1-4-5.net> AGENDA: Agenda Bashing Requirements document status draft-ietf-rpsec-generic-requirements-00.txt Made contact with the Editor (Jean-Jaques Puig) who has gotten busy with other things lately but will have more time to devote in Jan. Likewise engaged some other contributors (Danny McPherson and Emanuele Jones). Will work to revise in that timeframe. OSPF Vulnerability Analysis status draft-ietf-rpsec-OSPF-vuln-00.txt Is a WG doc but must wait to progress until the progression of the Generic Threats and Requirements docs. Have talked with the primary Author (Emanuele Jones) and asked that increment the version number and re-submit the document to ensure that it does not expire from the I-D repository. Threats document status Sandy Murphy draft-ietf-rpsec-routing-threats-07.txt Sandy presented her changes to the document. Some changes were refinements to the language to collapse a number of redundant or conflicting terms. Also worked through other dangling or otherwise problematic references. Byzantine Failures (section 4.8) removed The document will go to Working Group Last Call. BGP Attack Tree document status draft-convery-bgpattack-02.txt Similarly to the OSPF Vulnerabilities draft, this document may not progress yet. BGP Attack Tree Risk Analysis R. Kuhn et al. "Incorporating Subjective Risk Values in BGP Attack Trees" Risk assessment of BGP attacks, using NASA/AIAA standard procedure for fault trees Includes costs associated with countermeasures and the effectiveness of countermeasures in reducing risks. Kent and Metzger vigorously disputed the usefulness of this approach for security risk assessment. Sandy Murphy wasn't too sure about it either. Uses NASA/AIAA for trying to quantify probability of certain risks. Spreadsheet to do this stuff with goal to model the effect of countermeasures also. DOS attacks particularly hard to model. Steve Kent: The methodology developed by AIA was appropriate for their environment, but they tend to be wanting when applying them to attacks, because the propbablility generally goes from close to 0 to close to 1. Why did you decide to do this sort of analysis for security. R Kuhn: This is common in many industries, so we decided to use this one. S Kent: I believe this methodology is questionable in this environment. R Kuhn: There is always the risk of human mistakes, even in the nuclear industry, for instance. Perry M: You're making certain statistical assumptions that are not valid. Before a fault is found, it won't be exploited at all. When a fault is found, it will be exploited in bulk until it's fixed. The variables are not independant. R Kuhn: We don't expect to get accurate numbers, but rather a risk comparison. Perry M: This analysis won't give you even a good risk comparison. R Kuhn: This is the type o feedback we're looking for. Sandy Murphy: One of the items in the attack tree said something about disabling a certain portion of the Internet, is your analysis in respect to a single router, or in respect to the entire Internet. How are you doing analysis on the entire Internet. R Kuhn: We are following the attack tree, as it's been published. Sandy M: How did you do these calculations? R Kuhn: There's a standard fault tree calculation, we can look at them later. Sandy M: The reason I ask is because faults are not exploited equally throughout the network. The nuclear power plant error does add some randomess, but the malcious operator are applicable to the malicious operator case. R Kuhn: Most of these attack tress work with a single router. Sandy M: While DOS is a big problem, the biggest problems have not been DOS attacks, but rather misconfigurations of routers. The calculations then lead away from the obvserved results. R Kuhn: The countermeasures we're looking at should however impact Markus Leach: This work is interesting, but I'd be hesitent to let this work broadly impact the work the WG is doing. It wouldn't occur to me use AIAA analysis to work with the types of systems we are dealing with here. AIAA analysis is for failure analysis, rather than malicious attacks, or malicious actors. R Kuhn: I agree completely. It doesn't map completely, but we thought it might be useful. BGP Security Requirements Blaine Christian draft-christian-bgpsecreq-01.txt Goal: Provide a means to verify and assure peering relationships and prefix advertisements, etc. Threats: Unauthorized announcements Must support increment deployment Web of trust must be supported, also Strict hierarchy of authority (users should be able to decide which one they want) Need to make this a working group document. Steve Kent: Biggest concern is the lack of rationale. We need to motivate each of those requirements. Start from the semantics of the protocol, and say: "These are security things that must be done, and these are the performance concerns." For instance, we're concerned about computational speed, we're concerned about update size, etc. You need to start from: "This is what BGP is supposed to do," and how to secure them. Once you're past that, you can get to work on performance issues, and then think through processes. Blaine C: The hope was, through the process, and get comments. Steve K: I'd be glad to send you text showing what text we used when to come to these conclusions. Sandy Murphy: One thing I had noticed is that the doc covers requirements for solutions, and other requirements for security of the protocol. These should be better defined in the document. Sandy Murphy: BGP is a distributed system, you might have a strong requirement for security, but someone three hops away might not. How can people trust, or understand, the levels of trust other people might have when they produce their information? Blaine C: This is a big question--can you actually put that sort of thing in the decisions process. Tony T: Should we accept this as a WG doc? Russ W: If we accept this as a WG doc, should we take the work off the DT list, or pushed to the main list. Bill Fenner: If we make it a WG doc, then we should push it onto the main list. [ Consensus call on adoption of the document as a WG work item. ] Tony T: The sense of the room is that it should be a WG doc. We'll confirm on the list. |