Current Meeting Report
Jabber Logs

2.5.7 Routing Protocol Security Requirements (rpsec)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/02/2002

Bill Fenner <>
Russ White <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Alex Zinin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
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

- 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:
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.
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Wednesday, November 20 at 1530-1730
CHAIRS: Russ White <>
        Tony Tauber <>

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 

 Joel Halpern: Some things seem out of scope of what is expected of 
routers and routing protocols.  For instance what about 
 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 

 Radia Perlman: Insider vs. outsider.  Imagine giving a key but he's been 
compromised (that's insider).  Outsider is another router from another 

draft-murphy-threat-00.txt (15 minutes)

  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 
 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 

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 

 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 
 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 
 Comment from Mic: Support generic work. Also consider things outside 
 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)


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 

 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 
  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.


Known Threats to Routing Protocols
RPSEC General
BGP Attack Tree
Securing Routing/Signaling Protocols w/ IPSec
Secure Origin BGP
Internet Routing Verification