|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
On Thu, 26 May 2005, Tony Li wrote: A big +1 from me for EVERYTHING Tony just said.You're not going to like this. The simplest way to stop the hijacking is going to end up looking a LOT like one of the s*BGP proposals. Here's why: The threat model includes: - Forged origin ASs - Unauthorized advertisements from authenticatable sources - Unauthorized longer prefixes - Forged AS paths and AS path segments - Replay attacks on any of the above The solution, no matter how simple, is constrained: - No single point of failure/single point of attack - Must demonstrate that the AS path is authentic (i.e., not forged) If you cannot authenticate the entire AS path, then all you know is that someone out there wants you to send traffic to them. Any unauthenticated portions of the AS path could easily be forgeries and cover up AS path hackery. - Must demonstrate that the origin is authorized to advertise a prefix Even if the AS path is authenticated, it doesn't mean that I have a right to advertise that space. - Must be reasonably secure, and thus will involve some amount of crypto Thus, from what I can see, the SIMPLEST solution will have: - A distributed means of getting authorization information. Since address space can be delegated in a hierarchical fashion, this mechanism must be able represent that hierarchy, down to the origin AS level. - A distributed means of getting certificate information to authenticate each step on the AS path. The biggest simplification that I can see is to remove any expectation for real-time or near-real-time authentication and authorization, as well as the need for real-time access to the above two distributed databases. If, for example, the several gigabytes (?) of information could be stored locally on all systems before authentication began, that could eliminate some of the requirements for distribution. However, this would require a different mechanism to distribute the information, effectively turning the solution from a secure "pull" model to a secure "push" model. In my (alleged) mind, the hard part about the secure "pull" model was the word 'secure', not the word 'pull', so that doesn't sound too promising. Thus, I'm not seeing anything that seems like it is an order of magnitude less complex than s*BGP. If you want security that can prevent hijacking (and not just act after the fact), then you need to authenticate AS path from the the origin to destination and including authorization of right to announce the ip block itself. And I also don't see any way to avoid hierarchy certificate distribution with root at RIRs. What is possible is that RIRs would only be involved in providing certificate and actual distribution of this information would be done by routing registries (to avoid having RIR directly involved in maintaining routing infrastructure and keep separation of policy & allocations from operations). As far as downloading entire data for authorization - you can cache it, but ultimately you can not rely on it being distributed by protocol which itself depends on routing infrastructure, so it must be possible to pass information as part of BGP from peer-peer. -- William Leibzon Elan Networks [email protected]
|