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 Comment: 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 Seal 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 Hierarchy: 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 Status: This draft is still quite rough. More polish at next IETF Hope to present at NANOG to get more consensus Comments: 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? |