Last Modified: 2003-09-10
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)
|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.|
Routing Protocol Security Requirements WG (rpsec) Wednesday, November 12 at 1300-1500 CHAIRS: Russ White <email@example.com> Tony Tauber <firstname.lastname@example.org> Agenda Bashing - Tony Tauber no comments Threats document status - Tony Tauber draft-ietf-rpsec-routing-threats-03.txt 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 draft-puig-rpsec-generic-requirements-01.txt 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 draft-convery-bgpattack-01.txt 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 draft-jones-OSPF-vuln-01.txt 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 specs. 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 stuff. Felix Wu: Is it a protocol design issue really or implementation? 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 draft-white-path-considerations-00.txt 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 planned