|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
Todd, >>- 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. What you're suggesting here is simply a pre-computation of a portion of the acceptable paths. It has a significant disadvantage in that it is not capable of authenticating all of the possible authenticatable paths. We certainly see some bizarre (but valid!) paths in the core at various times, especially during flappage. How do you propose to deal with them with your system? Do you propose to reject them? If so, you are now violating the earlier mandate of not damaging current connectivity. If you do not reject them, then how do you reject the Bad Guy's routes? >>- Replay attacks on any of the above > > > unclear on the relevance of this but i'd like to see more. Very simply, any BGP advertisement (or portion of an advertisement) can always be re-injected into BGP sometime later by the Bad Guy, anywhere they have access into the BGP mesh. The Bad Guy can even replay certificates and such. >>- 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. Through the Tier 1 core, yes, to be sure. However, the paths that the core sees through the remainder of the net can get VERY interesting. >>- 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. Great. What is your prefix please? I'd like to steal your address space. Without this, anyone who is a legit member of the BGP mesh can steal ANYONE's space. And what's worst about this is that this is the failure mode that most of the accidents fall into. AS 7007 anyone? >>- Must be reasonably secure, and thus will involve some amount of >>crypto > > > sure. signed prefix-filter list distributed from a trusted source. That would violate the earlier requirement that we not have a single point of failure. Any single trusted source can be DoS'ed off of the net effectively forever. BTW, if we go down this path, how do we expect to get people to participate. As noted before, the IRR's have not been an overwhelming success. How do we get everyone to register their topology with the trusted source? If UUnet decides not to register, is everyone going to start dropping paths through them? > let several organizations calculate and distribute them. an > inverse-bogons. That gives only a list of the currently routable prefixes. It does nothing to tie those prefixes to their correct origins or real paths to get to those origins. >>- 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. Tell me what requirements we can relax. So far, I don't see it. As you may or may not know, I'm usually the first in line when it comes to pragmatic solutions. > 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. Well, if most folks feel like you do, yes, I guess we WILL have to wait for our version of 9/11 too. ;-( > 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). In fact, I know for certain that this is not true. Some transit providers are actually concentious folks who (between caring for their infant son ;-) actually help out their customers by backtracking hijacks. I submit, rather, that the transit providers have not yet seen the right alignment of a unified, effective solution that comes at a sane cost, that is implementable and deployable in a rational way. This suggests that our work item is really: - reach consensus on the technical solution - implement - provide clear understanding of operational requirements and deployment plans If I'm missing something, I'd dearly love a clue. Tony
|