2.5.9 Routing Protocol Security Requirements (rpsec)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-14


Tony Tauber <ttauber@1-4-5.net>
Russ White <riw@cisco.com>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: rpsec@ietf.org
To Subscribe: rpsec-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/rpsec/index.html

Description of Working Group:

The lack of a common set of security requirements and methods for
routing protocols has resulted in a wide variety of security
mechanisms for individual routing protocols. Ongoing work on
requirements for the next generation routing system and future work on
the actual mechanisms for it will require well documented routing
security requirements.

The products of this working group will be used by routing protocol
designers to ensure adequate coverage of security in the future,
including well known and possible threats.

The scope of work is limited to router-to-router protocols only for
both unicast and multicast systems, and does NOT include
host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a
non-goal at this point to produce new or change the current security
mechanisms in the existing routing protocols.

The RPSEC working group is charged with the following tasks:

- Document threat models for routing systems

- Document security requirements for routing systems

- Document security analysis and requirements for specific routing
    protocols (e.g., OSPF, BGP)

- Provide a common area for discussion between security and routing
    experts on the topic of securing the routing system

Possible Future Work

- Evaluate and document existing and proposed routing security
    mechanisms with respect to established RPSEC requirements

- Recommend mechanism(s)

Goals and Milestones:

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.


  • draft-ietf-rpsec-routing-threats-07.txt
  • draft-puig-rpsec-generic-requirements-02.txt
  • draft-ietf-rpsec-bgpattack-00.txt
  • draft-ietf-rpsec-ospf-vuln-00.txt
  • draft-ietf-rpsec-generic-requirements-00.txt

    No Request For Comments

    Current Meeting Report

    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 Bashing

    Requirements document status

    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

    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

    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

    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

    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.


    BGP Security Requirements