soBGP deployment

Fri May 27 06:27:20 UTC 2005

On Thu, 26 May 2005, Tony Li wrote:

> 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.

A big +1 from me for EVERYTHING Tony just said.

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
william at elan.net