|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
tony, all, On Thu, May 26, 2005 at 11:12:09PM -0700, Tony Li wrote: > You're not going to like this. on the contrary, i don't find it surprising or unpleasant. :-) > 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 yep. can be solved with something less than full authenticated routes. > - Unauthorized advertisements from authenticatable sources ditto. > - Unauthorized longer prefixes ditto. > - Forged AS paths and AS path segments ditto, provided that you have long enough AS path segments in your list of valid prefixes. if you have a long enough memory of routes and a fast enough system, it's trivial to produce weighted lists of the likelihood of a given prefix-path pair being valid. > - Replay attacks on any of the above unclear on the relevance of this but i'd like to see more. > The solution, no matter how simple, is constrained: > > - No single point of failure/single point of attack yep. a valid list of prefixes calculated from hundreds of peering sessions and weighted according to the prevalence and stability of a given path, distributed out of band, would do this. > - 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. sure. we see this from time to time in our data. and as i mentioned above, there's no reason you can't decomposed your path regexps into several segements so as to constrain the valid paths. there are far fewer paths through the internet than most people think. > - 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. it would be good to do this, but we don't do anything like this now and i disagree that a future solution would be required to do this. > > - Must be reasonably secure, and thus will involve some amount of > crypto sure. signed prefix-filter list distributed from a trusted source. let several organizations calculate and distribute them. an inverse-bogons. > - 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. <snip the rest> see, here's where you've added potentially unnecessary complexity. i think that the sbgp and sobgp proposals are great. they're just like IPv6: full of well-meaning, complicated engineering that doesn't offer great migration paths and doesn't address a burning need among network operators. as such, they're not getting much traction, not surprisingly. if tony is right that only the full solution will work, and that no heuristic that dramatically reduces the problem space will work, then we are probably stuck with no solution for the time being. transit providers *still* don't see value in authenticating prefixes because they don't feel the pain of the hijacks. and the people who do feel that pain *still* haven't decided that preventing hijacking by means of authenticating routes is something they're willing to pay extra for. so, like everything else on the $5/mb/s gige-port internet, we get what we pay for and the lowest common denominator is more or less required to stay in business (for now). cheers, (:-), t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence [email protected] www.renesys.com
|