Last Modified: 2004-06-24
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)
|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.|
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.
Originator AS signs originated prefixes
May be delegated
Should be signed per hop
Paths should be verifiable (not plausible)
Aggregation under discussion
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
(MD5 was painful)
Implemented badly today
Keys must be easy to rotate
Must also exist
May allow verification of the authenticity of prefixes
Degrees of assurance
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?