______________________________________________________________________ DRAFT TRANSCRIPT SIG: Routing Date: Wednesday 1 March 2006 Time: 2.00pm Presentation: Routing security - an oversimplification Presenter: Randy Bush ______________________________________________________________________ RANDY BUSH: OK. Credit also to Steve Bellovin, a lot of his work is represented here. What is routing security? It is not router security, it is not defending your router against attack, that are similar to attacks that will happen to your Windows or real computer or whatever. The unique thread is attacking using the routing protocols. It's routing security, not router security. What are they doing it for? To divert traffic and to alter traffic. We have some ability to lessen the danger but not enough. Steve Bellovin published stuff in '89. Work accelerates in 1996. Kent et alia did good stuff in 2000. Why so little progress? The problems are technically difficult. OK. Simple routing, as Geoff just showed you, is not simple. Complex problems in routing are exceedingly complex. When some of the best computer scientists in the world are studying your stuff as a behavioural phenomenon, you should know you're in trouble. So it's not traditional communication security. All the boys and girls in your big stack telcos know that it doesn't apply very well here. So it's new ground. The installed base is big and a transition problem is big. And vendors aren't seeing people with big bucks saying, "Do it." Whether those people don't exist, or the vendor's vision is poor, is not clear. Please go to the tutorials for normal operation security. What do we want to ensure? That an ISP who announces something owns it, origin of prefix. If a router announces a path to X, that it can actually deliver the packets there. And if it tells me it can get me to some place, did some place authorise it to take me there? If I'm told I can get taken to Geoff, did Geoff want his traffic to go there? We won't get into that, Geoff. OK. What's different? The well-studied communication and host security issues are buggy code, are all about buggy code or bad protocol design. In this case, we have, as good protocol designers, we can do and the code is, well, we won't go there. But we're still vulnerable because of a dishonest member of the game. Somebody with whom we are connected or somebody with whom we are connected to be connected is lying. OK. So hop-by-hop authentication is not sufficient because, just because I have a secure connection to Geoff doesn't mean Geoff's a good guy. OK. What does the attacker want? The normal situation is site A sends along this path, a nice financial transaction from A to X to Y to B. Z, the attacker, wants to divert the traffic, strip off and keep the dollars and let the traffic go there, maybe or maybe not, so that everybody thinks everything's fine and they kept the dollars. Of course, it may not be dollars, it could be critical information, it could be - I won't go there. All sorts of stuff. How does Attacker do it? This is going to be a simplified model. I think the original title said it was an oversimplification, so excuse me. On a hop-by-hop basis, the attacker owned some router and lies about the cost and we must assume that random routers on the Internet can be owned. The current price, going price in the black hat market for the enabled password to an ISP router, is five credit card numbers. That's pennies. So, they own some of your routers today, or mine too. OK. How does Z do it? OK, there are some costs, so the path here is 5+5+5 is 15, I'm not going to go to that because it's 30. So Y told Z it was 10 and its cost to B was 5. I told X and Z if you can get it to 5, I can get it to B. X told A and Z that its costs are I can get you to Y in 5 and B in 10. And X is told these are the costs. Z lies and says, "I can get you there cheaper." So the traffic gets handed to Z. And Z just got lucky. Why is it a hard problem? X does not really know what Z's links are. Has to believe what Z's saying. X does not really know what Y's links are either so they all trust each other regarding cost. OK. Validating prefix ownership does not help as nobody lied that B owned the target. OK. Using a routing registry like peering map does not help because nobody lied about who connected to whom. OK. One approach and Steve gets credit for the underlying model, is that B cryptographically signs when it tells Y it says, "Hey, hello, Y, you can get to my cost for B is 5." So it is signing forward when it announces. Y signs messages to X and Z, encapsulating B's message. It is signed by B saying this cost and it adds in front of it, "I can get you to Y for 10. So I can get you to Y for 10, signed by Y." So Y is committing to that and by the way, B, which you can verify, and I'm not making it up, because B created this signature and the only way B could have created it is that B can get you there for 5. Y can get you to B for 5. I can get you to Y for 10 and Y can get you to B for 5. Z can only sign now that it can get to Y for 10 and Y can get to B for 5. It can't tell you the lie that it did before. You can verify this cryptographically. But this costs. So... Use caching and pre or delayed validation. OK. The fact is, for those who had the misfortune to be in the database session and hear about my version of the PKI model a couple of hours ago, you can, or even in Steve's model, you can validate who owns what when you receive the database, you don't have to wait till you receive the routing announcement. And if you can't get it right now, be optimistic, say, "OK, I'll believe it for the moment," and go check it slowly - delayed validation. Hopefully computers will get a little faster and as Geoff has just pointed out, most routing announcements are boring, because you've already heard them recently. So if the router had a cache of what it already had validated, even though that was withdrawn, those people in Hong Kong are going to tell it to you again. GEOFF HUSTON: In the next second? RANDY BUSH: And you won't even have to revalidate it. Just when we need revalidation the most it is done. Geoff pointed out that probably that stuff is boring. OK. Trust issues - how does X know the plight of ISP Y? How does anyone know prefix ownership are the two core questions. Who owns the address space and who is announcing it? OK. Address space ownership and ASN ownership by the way, both of them luckily fall into a natural hierarchy with IANA at the root. So the allocations to RIRs and RIRs can sign allocations to ISPs, LIRs, NIRs and XIRs. Who issues the certificate. Who certifies an RIR or IANA? Who certifies an ISP's identity or an RIR? Is it a web of trust? Issuing the certificate of who owns that address space can be separated from issuing the certificate for the address space prefix. In other words, the ISP's identity is separable from the space that is being allocated to them. I'm going to do something horrible. I'm going to go to another presentation, if I can see here. And I don't have my glasses. OK. This is an allocation by APNIC. It is an allocation to me as the ISP. There's my identity and my public key. And it allocates that address space with that exploration and APNIC signs the delegation. Sorry, Steve, you'll survive the experience. We'll have some opportunities to discuss this. OK. And similarly, for an AS number it gives to me, and when I make the announcement, it's from one of the ASes I own, of address space I own, and you can verify it all. OK, how are the certs distributed? Is it administratively by ftp, etc, if it doesn't do a good job of it, then somebody should come up with that in v4 please. Out of band protocol, new cert distribution protocol. OK. Is there an in-band protocol? There are some on secure BGP suggestions that suggest that as yet another extension to BGP and some will work out how to do it with the DMS. So, that was it. I made it. Steve, by the way, did a lot of this work and helped me and IIJ pays my salary. Go for it, Steve. STEVE KENT: I liked most of it, until we got to the, "We take these blobs and sign them." The way you describe them doesn't correspond a standard way of issuing certificates from a format perspective, because you tied together, if you go back to the slide, which ever presentation that was. There. You either issue an identity cert or you issue an attribute search but that is served on separate ways. Someone can issue an identity cert. RANDY BUSH: They can do it from anywhere. STEPHEN KENT: And someone else as the responsibility of figuring out whether or not that identity search represents the people they're dealing with and then issue the attribute search. The question that comes to mind is why would I add the extra level of that? RANDY BUSH: They already do that. When I contract - where is somebody from an RIR. Sam, you're the victim. When I sign a contract with APNIC, the paper part of the contract binds her identity. Real space, my physical address, my signature - that is, a legally binding contract. I should hand them the certificate when I do that, when I will use to transact this stuff. That is my identity. I assert that in the binding legal contract. I might have gotten that cert. 95% of the cases, no-one wants to do their own cert management and they'll pay APNIC $10 and APNIC will give them their cert. OK. But Telstra - Steve, where are you - I believe paid tens of thousands of dollars to verify it with someone to get a Telstra CA. And I am not going to tell Telstra how to do their internal security management, they are a 500-kilogram gorilla and they'll tell me how they want to do their security management. What's interesting here is that they need the identity search of the ISPs, or endsites need no attestation because they're only used in two ways. Only used either as a business transaction. I sign a financial email that I sent to Sam, or I signed a DNS request that I sent to Sam, or I signed an allocation request I sent to Sam. And Sam, I signed it with the private key that matches the public key in the cert I gave her when I paid her money and give a contract. STEPHEN KENT: If I, as an RIR, go to the trouble of issuing an attribute search to someone, the work is exactly the same as if I issued a public cert? RANDY BUSH: It doesn't have a key, it doesn't have keys on it and therefore I cannot use it to sign requests to them. STEPHEN KENT: But your slides have attribute certs in them, issued to the holder of two identities. You've added this additional thing that a registry in this case had to do and I'm not sure why one would add it given that the work you would have to do to do that is just as much as if you just issued them a cert with a public key in it, binding those resources in the first place. RANDY BUSH: Because what we really do in our operational world - this just is, I like sBGP because it matches the BGP I know and is very congruent with it. I like this because it matches our transactions. For instance, my identity will be the same and the public key I will announce will be the same for my transactions with APNIC and with, where is ARIN? Is there an ARIN. STEPHEN KENT: You always get to choose the public key anyway so you can have the same... RANDY BUSH: Not if it's in the resource cert. STEPHEN KENT: You can. You get to choose what your public key is, if you choose to give the same public key in two resource certs, which are public key certs with extensions to them, you can choose to do that. And that won't break anything. The second concern now is that you said the only way you use the cert, the identity cert, is in local transaction with the registry for instance? RANDY BUSH: Bound in the attestations. STEPHEN KENT: You can only validate a public key cert by walking some chain from an anchor point. Everyone has to be a trust anchor for everyone else, which is a very significant. RANDY BUSH: No, no. I get the BGP announcement from Geoff. With the two of those objects, one being the ASN, and one being the IP space. I go to the IP space and I chase the IP space and I can verify the signatures all the way up to the IANA that encapsulated the attestations of who owned the space. STEPHEN KENT: If the space is only allocated there, you can't chain. RANDY BUSH: I'm going up a chain of the sign attestations. These, and there is a question of what is, in what name space are these. I agree. But we have a natural name space which is the IP identifier and the ASN. Here you go, Geoff. At least Geoff and I are used to storing these madly to run them for research. And I somehow think they make a very natural name space which will be run by other means. I think Geoff wants to speak. STEPHEN KENT: I watched you at the point where you talked about binding two other attribute certificates and identifier certificate which is binded. A resulting thing like that is not something that PKIs deal with from a chain perspective. It can be a digitally signed bit but we only chain certificates and we only chain public key certificates, not something else. So it would be a new thingy of some sort and I'm having a hard time relating to that. PHILIP SMITH: Just a quick comment. GEOFF HUSTON: What Randy is saying is that there is an implicit chaining inside the series of attribute certificates up the food chain by nature of aggregates and more specifics. If I see down at an ISP level a particular prefix, we can search through for an attribute certificate that expresses an aggregate of that. My question to Randy was why I can see that, how precisely does it work in the AS number space? Or are you assuming AS number blob arrangements? RANDY BUSH: AS numbers are allocated - I'm sorry. AS numbers are very like the IP space - they don't have dots in the middle of them. But IANA does hand out blocks of them to the RIRs. So there are ranges of this. GEOFF HUSTON: You would say it's the range search and would use the same thing. OK. RANDY BUSH: I will fess up that I haven't, you're at the edge of, while I've thought this out, and so has Steve. OK. You're at the edge of how far I've thought this out and luckily I think we have a couple more meetings in the next five days to beat on each other further on it. But this maps the business and social relationships that we actually have. It's intuitive to us. But, again, we're harping on this stuff when this presentation was supposed to be about the router security problem. George, bail me out. PHILIP SMITH: Thank you very much, Randy. Next up we have George Michaelson. He will give us an update.