Last Modified: 2003-01-22
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.|
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.