2.5.9 Routing Protocol Security Requirements (rpsec)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-10

Tony Tauber <ttauber@genuity.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://www1.ietf.org/mail-archive/working-groups/rpsec
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

- 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.
Jun 03  Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems.
Jun 03  Submit I-Ds documenting threats to routing systems for publication as Informational RFC.
Oct 03  Submit the I-D documenting security requirements to routing systems for publication as Informational RFC.
Mar 04  Evaluate progress, recharter with new goals (see possible future work above) or shutdown.
  • - draft-ietf-rpsec-routing-threats-03.txt
  • No Request For Comments

    Current Meeting Report

    Routing Protocol Security Requirements WG (rpsec)
    Wednesday, November 12 at 1300-1500
    CHAIRS: Russ White <riw@cisco.com>
            Tony Tauber <ttauber@genuity.net>
    Agenda Bashing - Tony Tauber
     no comments
    Threats document status - Tony Tauber
     Went through WG Last Call
     Went through IESG review
      Comments received, will be sent out
     Need to:
      - integrate comments
      - revise, review and/or respond
      - return to the process to progress.
     No other comments from the microphone
    Requirements document - Danny McPherson
     Building off Threats document in large part and figuring what items in 
    there ought to receive mitigation and what level of requirements (eg. MAY, 
    SHOULD, MUST) is warranted.  Also touches on system resource concerns.
     Needs much help from the community.
     How many have read this document? 4 or 5 hands.
     Consensus call:
      Should this draft be accepted as a WG work item?
      Sense of the room: Yes
      Will be taken to the list for confirmation.
    Charter Discussion - Tony Tauber
     Routing ADs would accept protocol specific work on the charter
      Generic work muct be completed before the protocol specific work
     How many would commit to work on protocol specific documents?
      Some hands
     How many would commit to comment on protocol specific documents?
      Some hands
     Should the charter be modified to accept protocol-specific work in this WG 
    with the provision that it not advance ahead of current chartered work (ie. 
    Generic Threats and Requirements documents)?
     Consensus call:
     Should the charter be ammended to include protocol-specific work?
      Sense of the room:  Generably favorable, with at least one opposed.
     At the microphone:
      Steve Kent suggested that this work should go to the protocol 
    specific groups, because the issues are different enough for each 
    protocol to warrant seperate work by the experts in those protocols, and the 
    participation isn't heavy enough in RPsec to do the work.
     WG Chairs will revise charter and send to the list for 
    consideration and comments.
     Consensus call:
      Should this draft be accepted as a WG work item?
      Sense of the room: Yes
      Will be taken to the list for confirmation.
    BGP Attack Tree - Sean Convery
     Presented information on the updates made since the last revision.
      Discussed presentations to the operational community.
      Discussed lab and real world testing of BGP security.
     Consensus call:
      Should this draft be accepted as a WG work item
       Sense of the room: Clearly in favor with no opposition.
       If modified charter is accepted on list, then this item will be 
    accepted as a WG item.
    OSPF Vulnerability Analysis - Emmanuele Jones
     At the microphone:
      Acee Lindem: No disagreements on the vulnerabilities, other than the 
    flooding, most people have implemented the flooding steps in the 
    opposite direction. Check for its for me, before flooding the LSA. Once you 
    are on someone's network, you could cause other damage.
      Tony Tauber: What sort of mitigations are avaiable?
      Emmanuele Jones: OSPF security is important, even if you could do other 
    things. You have to bypass authentication/etc.
      Felix Wu: Some of this has to do with implementation, is this a 
    protocol design issue?
      Emmanuele Jones: It is a protocol design issue, since the RFC does state 
    the order of steps to take, which allows the attacker this hole.
      Vassilis Prevelakis: The approach between generic threats and the OSPF 
    threats seem to be quite different. Should we try to standardize the 
    framework of these sorts of drafts?
      Padma: I believe that we can't do much against insider attacks.  I would 
    prefer to have more protection against outsider attacks.  I would like to 
    see outsider/insider attacks addressed in the doc.  We should copy this 
    draft to the OSPF list, as well.
      Emmanuele Jones: The draft does address insider and outsider attacks, but 
    they are not easy to seperate.
      Tony Tauber: There's the notion of Byzantine failure, detection, 
    recovery which is mentioned in the Threats draft and well discussed in 
    other literature.  This threat relates to mis-behaving insiders 
    (routers) and it's not really acceptable just to write off threats 
    related to compromised routers entirely.  Consider at least checking and 
    reporting errors such as receiving packets on unexpected interfaces, with 
    unexpected source addresses, etc.  Some of that's done today.
      Acee Lindem: To defend this work, most implementations have some way to 
    drop things cooming from unexpected interfaces, though they are not in the 
      Tony Tauber: Then we should consider those things.
      Acee Lindem: Say you have a unix box running OSPF with no 
    authentication, there's no checking of where packets came from, so it's 
    good to document that the implementations should check this sort of 
      Felix Wu: Is it a protocol design issue really or 
      Emmanuele Jones: Yes. Per the spec, order is problematic.
     Should this work be accepted as a WG item?
      Yes: Lots of hands
      No: One vote
     If the WG charter amendments are accepted, this item will be accepted as a 
    WG item.
    Path Security - Russ White
     Point is that some amount of information in distance-vector and 
    path-vector protocols is hidden or removed as a matter of course (eg. for 
    reasons of optimization or policy).  Attempts to derive security for those 
    protocols must take into account this property.
     Steve Kent: Understand what you're trying to say.  Wasn't entirely clear in 
    the draft.
     Russ White: Yes, the fact that the draft's language needs 
    clarification been made obvious by some of the feedback and revision is 


    Security Requirements for Routing Protocols
    BGP Attack Tree
    OSPF Security Vulnerabilities Analysis
    Considerations in Validating the Path in Routing Protocols