Last Modifield: 07/02/2002
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)
|JUL 02||Submit initial I-D (or set of I-Ds) which details the threats to routing systems.|
|OCT 02||Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems.|
|DEC 02||Submit I-Ds documenting threats to routing systems for publication as Informational RFC.|
|MAR 03||Submit the I-D documenting security requirements to routing systems for publication as Informational RFC.|
|MAR 03||Evaluate progress, recharter with new goals (see possible future work above) or shutdown.|
Wednesday, November 20 at 1530-1730 =================================== CHAIRS: Russ White <firstname.lastname@example.org> Tony Tauber <email@example.com> Minutes: Gerry Redwine, Russ White, Tony Tauber Agenda Bashing (5 minutes) S-BGP Workshop - Operator's Impressions (10 minutes) (Cancelled) * Randy Bush not in attendance Order changed on-the-fly to have Dave Ward come just before soBGP. Added John Ionnidis based on request earlier in the week. Threat Analysis Drafts draft-beard-rpsec-routing-threats-00.txt (15 minutes) Is there additional content needed? What is the best format to present the information? Q: Would it have to be a malicious attack ? A: No. Could have been a mis-configuration. Q: Who and how do we define high risk ? A: Need to build a definition and model for this. Q: How does this compare with the Murphy draft ? A: Do we consider it to be consolidated in this work Tony Tauber: What about disclosure of routing information ? Is there a presumption that routing information is kept secret? Doesn't seem that this goal was part of any protocol design. A: Need to define it as a role or risk to include routing information. Joel Halpern: Some things seem out of scope of what is expected of routers and routing protocols. For instance what about underclaiming? Seems confusing. Third or fourth parties could percieve your service as degraded w/o your knowing. On the other hand, it's an operator's perogative to degrade their service sometimes (Ed: eg. DiffServ?) Yi Yang: The attacks are similar for compromised, masquerading but not the same. Radia Perlman: Insider vs. outsider. Imagine giving a key but he's been compromised (that's insider). Outsider is another router from another domain. draft-murphy-threat-00.txt (15 minutes) Sandy: What type of structure document is useful? What content should be included? What is needed? Iljitsch van Beijnum: Local software bugs are part of routing ? The defect/bug is considered and insider attack? Sandy: Yes, in a sense. Q: Are bugs/defects considered a security issue? A: Not a security issue to other routers. Does not have to be accounted for by how the RP works Bob from ATT Comcast: How about IGP attacks that affect BGP decisions based on IGP cost? Where does this fit? Sandy: Good point. Yi. Spoofing router, inside or outside attacher? Sandy: If not the legitimate neighbor then it is an outsider. Radia. Clearification of insider vs outsider Insider- someone we should be trusting Outsider - should not be trusted, outside of domain Q: Are you saying that when there is local consequece (to the router) that is okay? A: One thing to focus on is how Routing Protocol reacts to faults within the center. draft-convery-bgpattack-00.txt (15 minutes) Sean stepped through a small example of an attack tree Martin: Incorporate risk analysisk. Do you intend to do so? Sean: Maybe, that work is not in the draft currently and not likely due to the amount of variables/information. Alex Zinin: Is it more a method of documenting research or is it a method to do research? Sean: Both. Some ideas need to be validated through testing. Alex: How good of a coverage can we get using this method vs. using vulnerability drafts and then going to potential attacks and threats. Seems to depend on the "evil" creativity of the person doing the analysis. Do people approach from both directions? What do security people do? Steve Bellovin: Both. Sean: Sandy's BGP analysis helped with evil thoughts. Alex Zinin: There's some urgency w/r/t BGP in IDR now. Comment. Alex. What to do with doc. Useful if Sean and Sandy can get together to collaborate to include something in the BGP security section Sandy: What about syntax? Why put in impossible attacks? Sean: Probably not binary values but degree of ease. HARD TO write an attack sceanario for people who just want to cause harm Sandy: Perhaps a different way of writing scenarios. Sean: Catch up with you later. Sandy: Some goals are just "Cause harm". Hard to consider those. John Ionnidis: Who are the consumers? Sean: Designers, implementors, deployers. John: So, can tree be expressed differently depending on protocol vs. operational or implementor failure? Sean: Have some ideas about XML tool to approach this info. John: I have some ideas also which I could share. Chandra: Parts which talk about routing system attacks are most useful are parts which assign values which help know how to address problems. Sean: Yes. Felix Wu: Customer building global intrusion system. It is hard to assign a priority but the tree is good. What is definition of complete? Sean: Need WG to come to a consensuss as to the methods of attack and the most common ways. Concern tree will grow, will never really be complete. Discussion of next steps for threat drafts (10 minutes) Produce a generic draft as a milestone for WG. How to proceed? Consensus test: Hum says merge and authors are agreeable. Iljitsch van Beijnum: What about tree getting too big if all protos need representations? Discussion on whether there needs to be documents for each Routing Protocol or one doc for all. There seems to be room for both. John Scudder: What's a generic routing protocol? Mike Patton: Doing every protocol would have to be progressed simultaneously. Alex: Do generic work first. Tom Petch: Variety of protos, but much commonality in their function. Sean: Disagree that general work should come before BGP. Do both in parallel. Comment from Mic: Support generic work. Also consider things outside protocols. Michel Py: If you do generic tree, where do you put TCP? Alex Zinin: Transport mechanism is a generic component of routing protocols. Will figure out what to do with BGP analysis work. Won't be blocked. This work should not impede the BGP analysis work being done in other groups. It's for protocol designers to check their work. Keep in mind higher level Need goals to keep grounded in reality. John I: Maybe beef-up protos so that a certain ancillary problems can't break things. Also detailed analysis of the attack on transport can be mounted different ways. so-BGP (Dave Cook) (15 minutes) draft-ng-sobgp-bgp-extensions-00.txt draft-white-sobgp-extensions-00.txt ftp://ftp-eng.cisco.com/sobgp/index.html Routing Protocols over IPSec (Dave Ward) (20 minutes) What do we do with the doc? Make it informational ? Does it belong in RPSec or IPSec group ? Make it more generalized for Routing Protocols ? Point from Dave Ward on what is unciear? Need decision from Area Directors to be able to use IPSec for Routing Protocols. Dave comments that the draft is not ready for primetime. IGPs already have other mechanism such as MD5 and IPv6 Q: Alex does not think we need Area Directors decision Steve Bellovin clarifies his draft that it is not how to use IPSec with BGP but how to do IPSec with any arbitrary RP. BGP was chosen since it had the right characteristics to work with. IRV: Internet Route Verification (John Ionnidis) (10 minutes) Source AS is validated as well as the paths. Complementary approach to deploying soBGP. BGP hides information. When something goes wrong, can't tell whether the problem was malicious or accidental. Having a richer channel to communicate what is wrong that BGP is useful. IRV - Internet Route Verification: Each AS maintains a distributed, replicated database Alex Zinin: What about circular dependency between routing and database Look-ups? JI: Haven't solved it. Session ended: 17:45.