2.5.11 Routing Protocol Security Requirements (rpsec)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

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.
Jul 04  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-06.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

    Proposed RPsec Meeting Minutes
    (many thinks to Rena Yang)

    -=> Agenda Bashing

    -=> Working Group Update

    Alex: Generic routing protocols threats document status: approved, in RFC editor queue

    Russ: Charter expansion when Alex says we can, when we get a handle on BGP requirements. BGP attack tree, OSPF work in the queue already.

    -=> Generic Security Requirements for Routing Protocols
    presented by Jean-Jacque Puig
    (referred to as JJ below)

    JJ Query: Any opinion on what should be done about security of neighbors discovery? Should we implicitly rely on other work (like IPSEC) or be explicit?

    ???: If you're doing it in a routing protocol, cover it in this group

    Alex: Leave it up to designer of protocol. Can list several options

    JJ Query: Should we enforce correctness?

    ???: What do you mean by correct state of routing?

    JJ: What is not correct. You expect something to be signed.

    Alex: we're mixing authentication, syntactical correctness, and semantic correctness

    JJ: For all operations there is an issue. Correct an error. If something is happening that do you not

    Alex: If the router is not authorized to announce, that would have been caught in the security part of the protocol. This is that the semantical part of the announcement is correct.

    JJ: Do we want to check what we know already?

    Alex: that case is about forwarding. Traffic is affected by static routes and neighbor AS. You can't make decisions based on the traffic you receive.

    JJ: 2 improvements: Try to reach router. If unreachable, there is a problem. That is a ___ check

    Alex: this is outside of the scope of routing protocol security

    JJ: This is routing operations

    ???: Analogy: LSP ping. Verifying the forwarding plane matches control plane. MPLS working group is doing this.

    ???: If this is what you're doing. For short periods these will be out of sync.

    Comments on the Presentation:

    Steve Kent: I don't understand why you're talking about this. You should be covering requirements of secure operation, not how you should be doing them.

    JJ: Do you think we can't get requirements related to this part. These are the consequences.

    Steve: We are able to use terminology to differentiate requirements and the [mechanisms to implement them]

    Russ: Send comments/questions to the list

    Russ to JJ: publish items to discuss

    -=> BGP Routing Protocol Security
    presented by Blaine Christian

    The authors of this are many
    What this won't cover: path of packets, IGP, best practice for BGP

    There is much contention on terminology

    Web of trust:
    - Peers sign for peers
    - Number of peers for a distant peer improves the trust level
    - Hierarchy is not mandatory
    - Looks like the world

    Steve Kent: Second bullet is not true

    Blaine: Not yet

    Steve Kent: Not in an absolute sense. It's who says what, not how many.

    Prefix authentication:
    Originator AS signs originated prefixes
    May be delegated
    Should be signed per hop
    Paths should be verifiable (not plausible)
    Aggregation under discussion

    Prefix Accounting
    Essential part of security
    Seems to always get missed
    Format needs to be standard and reviewable online and loggable
    Tracking structures to be used to improve security in mixed mode

    Chunk of information that proves you originated a chunk of information

    Session Security
    (MD5 was painful)
    Implemented badly today
    Keys must be easy to rotate

    Must also exist
    Allows troubleshooting
    May allow verification of the authenticity of prefixes

    Degrees of assurance
    Path traceability
    Path plausibility
    Session Security
    What already doing stinks (key changes)
    Originating AS signature

    This draft is still quite rough. More polish at next IETF
    Hope to present at NANOG to get more consensus


    Steve: Concerned from the first slide that this is about solutions, not requirements

    Blaine: We discussed that several times. This is what we expect. That web of trust is like the web of trust that we have, but better

    Steve: That is already heading down a solution path. It will be vulnerable when one of your trusted peers screws up. You're doing what you're doing today.

    Blaine: You're into authoritative sources.

    Steve: Be clear that this has already moved away from requirements to solution path, and carries a set of limitations on what you can accomplish.

    Blaine: Every provider I talked to wasn't into the central authority model. If we want to get something through, then do something that doesn't say central authority. The mechanism on central authority exists. This is given by hierarchy. Central first and peers next.

    John Scudder: if we can't express preferences, then this will be very short

    Michael: What do you mean by trust?

    Blaine: Depends on the peer. If you complete trust, if they send something, believe it. If neighbor of that peer, maybe different level of trust. Web of trust is not quite defined to the extent need to be. 3 classes A, B, C. It's like a spider web: further out implies less trusted

    Chris: There is nothing saying a web of trust can't be used to implement central authority. ie. I trust implicitly stuff signed by central authority

    Bora: In other regions of the world, one model may work better than another. Don't preclude any. You could have both working.

    Sue: The aggregation problem is hard. If you've got a web and someone starts to lie, you have a lying web of trust.

    Blaine: We need to be able to backtrack.

    Sue: Prefix accounting. At a certain level, you can't ignore some other stuff

    Blaine: If you have a /12 and someone else has a /24. How do I delegate something someone else can send?

    Sue: This is a good start. Make sure we do aggregation. Get SPs to give you all of their horror stories. Get a broad spectrum: SPs, VOIP, government

    Blaine: One model is to only accept things from web of trust

    Sue: 7007 gave us an example. You may end up flopping when you get to the tough problems. L2VPNs? 2547? autodiscovery?

    Blaine: we're doing interdomain routing

    Sandy: Speaking of process. Separate requirements and consideration of requirements for solutions. We can't make convergence 3x harder. Can't make processing 12x harder. Crypto has to do it just as fast if not faster. Decisions to be made on properties of the solution should be put in the requirements

    Blaine: Legacy requirements.

    Sandy: incremental deployment. Other problem: lack of freshness. BGP is not a fresh protocol. You could provide this, but this would require changes to the protocol/packet.

    Blaine: no one was fond of refresh mechanism

    Sandy: promise that we will look at the remaining hard issues

    Russ: John+Russ discussion. In many cases when you hit the wall, it may be be useful to say it is useful and the negative impact may be greater than the usefulness as a security mechanism. And leave as discussion at the point solutions are being discussed. Or give a hint now.

    Wend: You're authenticating routes

    Blaine: As operator, when we had to secure TCP sessions with MD5, it sucked. If I'm already authenticating routing data, then why not sessions?


    None received.