|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
Daniel, Todd, > The most significant problem is hijacking of IP address space for various > purposes. That's it. Solve that in the SIMPLEST way possible, lets implement > it (because everyone sees the problem) than we can either iteratively > improve the solution or start working on the next solution. 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. Regards, Tony
|