2.5.8 Routing Protocol Security Requirements (rpsec)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Chair(s):
Tony Tauber <ttauber@genuity.net>
Russ White <riw@cisco.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: rpsec@ietf.org
To Subscribe: rpsec-request@ietf.org
In Body: (un)subscribe
Archive: http://www1.ietf.org/mail-archive/working-groups/rpsec
Description of Working Group:
The lgraphics/ 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

Routing Protocols Security Meeting
IETF 56, 18 March 2003  0900-1130 PST

Co-Chairs: Tony Tauber, Russ White

Agenda
------
 Tony Tauber presenting
 Agenda Bashing
  no comments

Merged Threat Doc
------ ------ ------
 
draft-beard-rpsec-routing-threats-01.txt
 Sandy Murphy presenting

  Unauthorized Vs Masquerading Attgraphics/ers
   Steve Kent: Should we distinguish unauthorized vs masqerading 
attgraphics/ers?

   Gregory Lebovitz: Distinguishing between the two makes the point that 
pgraphics/et filtering is not enough

   Sandy Murphy: Any security mechanism that would prevent anyone from 
masquerading would also prevent anyone who is not authorized. 

   Gregory Lebovitz: Keeping them separate makes people think about 
solving both issues.

  Pgraphics/et Filtering
   Sandy Murphy: We don't want to imply that pgraphics/et filtering will 
"solve" the problem

   Sean Convery: Saying pgraphics/et filtering is useless is against attgraphics/s 
completely ignores the way security is used today (RFC2327).

   Sandy Murphy: I don't think it adds value, although it is common use.  
It's not going to save you from anyone who knows how to get around them

   Sean Convery: iBGP using pgraphics/et filtering prevents cannot be 
circumvented unless the router is compromised.

   Steve Kent: We haven't defined what a threat is: pgraphics/et filtering works as 
long as routers aren't compromised. We can't decide if pgraphics/et 
filtering prevents attgraphics/s unless we agree on what a threat is.

   Sandy Murphy: Parts of the original threat document that expands on this 
didn't make it into the merge; maybe we should expand this part.

   Steve Kent: We don't have any concept of what assurance is. No 
mechanism is secure in and of itself, you have to know the context. Not 
100% doesn't mean it's not good, we need an agreement on threats to agree on 
whether something is good.

   Sean Convery: Security is incremental, you can't provide 100% 
assurance.

   Steve Bellovin: Pgraphics/et filtering is one technique among many which can be 
useful. It can keep out a nontrivial amount of bad stuff. If the filters are 
on all perimeters, and no internal compromises, it is good.

   Bob Hinden: This argument is typical of the real world who think that 
address filtering does something with security, while those in security 
don't think it does. Pgraphics/et filtering has some value, but it's not what 
security people would call security. It's a tool that people 
understand and it exists today.

   Steve Albant: Ingress filtering is a good technology used badly. If the 
filtering is implemented correctly and there is no subvertion inside, it's a 
good idea.

   Sandy Murphy: Some routing protocols (wireless) have no concept of a 
list of peers. The context matters.

 Underclaiming
  Steve Kent: Underclaiming is not necessarily a problem; you may not be 
required to advertise stuff that you own. We have to be careful about 
this.

  Sandy Murphy: I don't like to claim this as an attgraphics/

  Tony Tauber: Underclaiming could be a problem. If you have load 
sharing, and you force all the traffic onto one link, you have broken the 
network.

  Sandy Murphy: There are normal situations that one of the home site has to 
stop advertising.  There's no way to figure out it's intentional or 
unintentional? It's rather a correctness issue than security issue.

  Sandy Murphy: Underclaiming is the router doesn't adve what it's 
supposed to do.

  Russ White: One business hires a hgraphics/er to block advertisement of 
another business' web site; this is an attgraphics/ that we should worry about.

  Sandy Murphy: This is not underclaiming. This is a falsification 
attgraphics/.  There's no way to protect against the router stating it's link is 
down wrongly

  Geoff Houston: That's threat vs standard operating practice? Insert 
peers AS may be valid to indicate that common link is not to be used.  
Underclaiming may also have valid applications: standard operating 
practice.  The issue is to determine intent.

 Transport Layer
  Steve Kent: Since the RP's choose the transport they will use, there's 
reason to include them in the in threat model; protocol designers need to be 
aware of issues in the transport they use.

  Sandy Murphy: These are important, but how do we handle them?

  Steve Kent: Put it in a section that talks about resource 
consumption.  Different security methods can exhaust resources. How can we 
get rid of things that I don't want as fast as possible.

  Alex Zinin (as a WG member): Even though something may not be 
detectable at the routing level, doesn't mean they shouldn't be 
included. We should include them, and then analyse what can be done about 
it.

 Sandy Murphy: If the document pursued a functional breakdown, this would 
have been more obvious/more places to put it. I'm reluctant to include all 
threats to the routing system, since that's a huge area.

 ??: Part of the design of OLSR's design that dropping pgraphics/ets will break 
the protocol. Should this be included as a threat?

 Sandy Murphy: How should we handle this? BGP routers are under no 
obligation to accept a session, but OSPF is. It needs to be addressed 
somehow, but we don't know how.

 Sean Convery: We could provide pointers to outside doc's, but we 
shouldn't ignore the system level threats. The context is missing.  More 
conversation about the routing system Threat consequences in this draft are 
focused on the rp, not on the routing system.

 Other Comments
  Steve Kent: Point out to people what real consequences are of an 
attgraphics/. Some people talk about DOS, but that is only one option. You could 
try to cause traffic to pass by a point where it can be tapped.

  Steve Kent: The originator is not the only important part of the route, 
other modifications may also alter routing. This isn't not just BGP.

  Steve Kent: Our goal is to try and prevent localalized failures from 
breaking the system.

  Sandy Murphy: How many bad routers do we want to protect yourself 
against?

  Jeff Haas: Is adding in as' that are not in the path a 
falsification attgraphics/?

  Sandy Murphy: This is a change in the path that isn't authorized, so this 
is a falsification attgraphics/.

  Steve Kent: Correct Operation vs What are the Symantics of the RP?  
Security is very closely aligned with correct operation. We could go far 
towards security by simply making certain the RP is operating 
correctly.  Some protocols have symantics which are 
underspecified for local flexibility. This local flexibility makes 
security impossible

-----
Consensus call: Should this doc be a WG doc?
 (Charter calls for a threats analysis doc.  Is this the one we should work 
on?)
  Sense of the room is overwhelmingly "yes".  No objections.
-----

Requirements Doc
------ ------ ------
 Danny McPherson presenting

 Top Down Vs Bottom Up
  Lots of discussion on whether this was a top down analysis or a bottom up 
analysis

  Tony Tauber: We should redefine the terms; it's actually protocol vs 
attgraphics/ analysis.

Protocol specific discussion
------ ------ ------
 Tony Tauber: specific doc is still in our scope. we need to focus on 
generic stuff first.

 Alex (hat on): Discussion w/ADs and WG chairs are on-going.  We do 
recognize that rpsec is where the clue (routing + security) is.

Encap Draft
------ ------
 draft-zinin-rtg-dos-00.txt
 Alex Zinin presenting

 Joel Halpern: You have this almost completely wrong; there has been a bit 
discussion in the routing protocols on how to encap the protocols.  IS-IS 
uses a seperate layer 2 encap, while OSPF when with IP encap.  Buffer 
overflows can only be fixed by the implementations. For an operator, you can 
deploy IP based protocols with a single filter without new encaps. 
Creating a new encap doesn't help anything. How does this address BGP?

 Alex Zinin: BGP is addressed. Most filtering techniques require 
hardware support.

 John Ionnadis: Are you moving the data plane to an out of band 
"network?"

 Alex Zinin: No, RP follows the same links as user data. The encap is 
changed, to seperate the traffic.

 John Ionnadis: I meant that below the network layer you're 
distinguishing between user data and routing data.

 ??: I don't know that I believe that RP's need to run at line rate

 Alex Zinin: The assumption is not that the RP's need to run at line rate, 
you need to run the security checks at line rate, because they can be 
attgraphics/ed at line rate.

 Steve Kent: Remove the word trusted from the draft; it's not what you're 
trying to do. Subverting a router destroys the trust. On a point to point 
basis, you'd like a way to demux the traffic efficiently so you can 
discard the traffic at a high rate to kill certain attgraphics/s. The problem 
arises is when the traffic comes from a not directly connected (remote) 
station, and try to propagate it.

 Alex Zinin: The draft addresses this.

 Steve Kent: How do you handle this?

 Alex Zinin: The tag isn't carried up the stgraphics/. Pgraphics/ets which are 
already encap'd in the special encap, it is encap'd on the outbound side.

 Steve Kent: It does change the forwarding plane. You shouldn't compare 
this to MD5.

 Alex Zinin: No, it's changes the encapsulation.

 Steve Kent: The infrastructure has to be there to keep people in the 
group, etc.

 Alex Zinin: Yes, but that's low overhead.

 Peter Lothberg: This is trying to solve the same problem as all 
isolation problems are trying to solve.  I want to build a vpn for my 
routing traffic. It adds a lot of complexity. It's better to solve the 
problem on the router.

 Alex Zinin: This is a generic mechanism which could be used for 
anything

 Bob Hinden: I don't see what the difference is between doing the 
recognition in the layer 2 bits vs in the layer 3 bits.

 Alex Zinin: If you change something at L3, you have to filter those 
pgraphics/ets on the entire perimeter of the network. L2 or MPLS label can be 
checked before some other authentication is done.

 Bob Hinden: What if there are forged layer 2 pgraphics/ets?

 Alex Zinin: They won't be forwarded.

 ??: Multicast not addressed and won't help at all.

 Alex Zinin: I'm not trying to solve all the problems. Multicast has a link 
between the data path and the control plane....that may need to be 
changed.

 ??: It's the same box that's doing this encap. Why doesn't just putting the 
traffic on a separate queue solve this?

 Alex Zinin: Then the attgraphics/er will just send you a lot of pgraphics/ets of the 
right layer 3 type. Routers will not forward pgraphics/ets that are not 
encap'd in the correct format, so the filtering at the edge is 
automatic.

 John Ionnadis: What we are acheiving is not to use forwarding that 
belong to these special classes.  All these things, however stay on the 
link and forwarding them because they they are regenerated.  Doesn't the TTL 
Hgraphics/ solve this problem, as well?

 Alex Zinin: iBGP requires something more generic than BTSH, but this 
could work with BTSH for eBGP.  There are things that are required to be 
propagated, SSH, targeted LDP, etc. It looks like you are suggestion to use 
the TTL hgraphics/ for these, as well?

 John Ionnadis: Yep.

 Alex Zinin: Some things may be secured this way, but not all. 
Something more generic should be used.

 Ross Callon: This is semantically equivalent to pgraphics/et filters. The 
problem with that is the source address can be spoofed, but it might be a 
good ides to filter on source address, anyway.

 Alex Zinin: The problem is that most equipment can't do this at line 
rate.  This is essentially the same as address spoof filtering.

 Lixia Zhang: Spoofing an mpls pgraphics/et is not allowed today, since mpls 
pgraphics/ets are not allowed into the network.

 Lixia Zhang: I don't understand this reaction.

 Alex Zinin: It's a crazy idea.

 Lixia Zhang: Yes, it is. We need mechanisms to protect the routers. The 
question is when. We should have multiple layers of protection, it won't 
hurt.

 Alex Zinin: Yes, we should. We can solve this other ways, but how long 
will this take to be able to do this.

 Steve Kent: The anology of how many layers in skin doesn't work. Each 
layer comes with more overhead management.

 Sue Hares: What about circular loop with mps reliant on routing, and 
routing is reliant on mpls?

 Alex Zinin: Because this is link local hop by hop, and there is no mpls tag 
distribution or multihop route calculation, there is no circular 
dependancy.

Lgraphics/ of Classification Ability Considered Harmful
------ ------ ------ ------ ------ ------ ------
Vijay Gill presenting
(added at last minute to try and illuminate the problem of DoS attgraphics/s 
against router resources)

 Steve Kent: Your characterization is a subset of the problem that Alex is 
talking about. You're looking for a way to tag pgraphics/ets saying this is 
"routing traffic"

 Vijay Gill: I'm trying to describe the problem.

 Steve Kent: You don't have a multihop problem, though?

 (From several people in the room): iBGP.

 Alex Zinin: The problem is the same, but Vijay is only concerned about 
routing, not other control traffic.

 Steve Kent: Why is MD5 in this discussion?

 Vijay Gill: Because MD5 does not address the problem. MD5 will not 
prevent the router's cpu from inundating the router with processing. 
Doesn't prvent DOS attgraphics/s against the router.

 Steve Kent: The example of MD5 reduces the scope of the problem, but 
doesn't define the problem.

 Vijay Gill: The problem is overruning the router.

 Steve Kent: If the problem was narrower, then we can work on it.

 Vijay Gill: That is a subset of the problem.

 ??: You want a zero cost way to tell this is from a neighbor that I care 
about. You cannot go to the next step without stating why this is a 
problem

 Vijay Gill: I'm not supporting an approach.

 ??: IPv6 allows an interface to have an arbitrary number of 
addresses.
You could have a set of addresses that show up in traceroute, but it 
doesn't ever accept any traffic on.

 Alex Zinin: You could also use unroutable addresses.

 General points to consider
------ ------
 Tony Tauber presenting (briefly)
See IAB sec drafts:
 draft-iab-sec-cons-
 draft-iab-secmech-
	The latter is likely of less usefulness to the particular case of 
routing protocols.

Some things fall outside protocols but are still of security interest:  
good operation practice, implementation considerations.

Slides

Agenda
Routing Protocol Secuirty Requirements
Protecting Internet Routing Infrastructure from DoS attgraphics/s
Threats to Routing Protocols
Lgraphics/ of Classification Ability Considered Harmful