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
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
Re: soBGP deployment
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 [EMAIL PROTECTED]
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
Re: soBGP deployment
steve, tony, all, just catching up. trying to ignore the TOS fest but the soBGP thread actually is interesting. On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote: And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me. That's what we can say so far. Do you really want to wait until we have a major problem? i want to agree with tony here. i find steve's attitude troubling and unfortunately common. i hear about hijackings that cause *major* problems on a regular basis (several times per month) and i hear a lot of frustration from major *edge* ASes about the inability to do much about it. in the past two years i've presented at least one, very interesting, high-profile hijacking at some public event (NOTA peering forum, SD peering forum, LINX members meeting, nanog, etc) every 3 months or so, and i'm not spending *any* time looking for them. i also hear a lot of nonchalance on the part of transit and SP ASes about the problem. and i can understand that. because the current tools don't give you many options and the current customers want *cheap* and not *good*. depressing but true. i also hear steve's point about not making things work *less* well. if we've learned anything from the md5 debacle it is that it is easy to create a new vulnerability or attack vector while preventing a non-problem. so it's prudent to be cautious. but i would suggest that doing anything that could *delay* a *new* announcement on a *new* path is completely acceptable. it's already happening now for edge ASes. you get new space. you contact your providers and peers and tell them to accept it. they do the same thing. and after a little while (usually more than a day but less than a week) the advertisements reach some plausible imitation of the global table and you call it good enough. so why not seriously consider options that don't impact existing routes on existing paths, but make it more difficult to get a new prefix working on a never-before-seen origination path pattern? like steve, i haven't yet formed an opnion on soBGP or sBGP (other than the fact that they've obviously been around for a while and obviously aren't being implemented by anyone yet). so my comments are more general. t. -- _ todd underwood director of operations security renesys - interdomain intelligence [EMAIL PROTECTED] www.renesys.com
Re: soBGP deployment
On Thu, 26 May 2005, Todd Underwood wrote: the list of all prefixes seen in the global table combined with all origination patterns seen for the past 6 months or so is realively easy to produce. This is something that we, or RIPE/RIS, or RouteViews, could produce and cryptographically sign immediately. Trivial script. We could have it up and available by https and updated once a day, in a matter of a day or two. If anybody feels like it would be solving a problem. -Bill
Re: soBGP deployment
On Thu, 26 May 2005, Todd Underwood wrote: the scalability problem, as i understand it (not at all an expert here) is that routers won't currently handle such a list with regexps very well. apparently, ciscos will not allow filtering advertisements on a combination of prefix + as-path regexp at all and junipers will, but the perception is that they will not scale to a list of 300-500K (which is the union of routes in global tables without any consolidation). if you could consolidate all equally originated prefixes under their covering supernets and still adequately filter, that number would be *much* smaller, obviously. Or if you could do it based on atoms rather than prefixes. But atoms have been looking like a trickier concept than I first thought, as we've started to look at them. -Bill
Re: soBGP deployment
The thing we should keep in mind is that the problem set is really very limited. Although I acknowledge Tony's cockpit door analogy, we live in the world of today. 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. Steve's attitude (and mine) is pretty close to universal amongst operators. We don't need complexity to solve problems that aren't there. There has been a bit of a historic issue with vendors and IETF folks (congruent sets, yes), telling operators what their problems are and how to fix them. I won't enumerate the various problems. Hijacked IP address space is a real problem. Simple solution please :) - Dan On 5/26/05 6:33 AM, Todd Underwood [EMAIL PROTECTED] wrote: steve, tony, all, just catching up. trying to ignore the TOS fest but the soBGP thread actually is interesting. On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote: And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me. That's what we can say so far. Do you really want to wait until we have a major problem? i want to agree with tony here. i find steve's attitude troubling and unfortunately common. i hear about hijackings that cause *major* problems on a regular basis (several times per month) and i hear a lot of frustration from major *edge* ASes about the inability to do much about it. in the past two years i've presented at least one, very interesting, high-profile hijacking at some public event (NOTA peering forum, SD peering forum, LINX members meeting, nanog, etc) every 3 months or so, and i'm not spending *any* time looking for them. i also hear a lot of nonchalance on the part of transit and SP ASes about the problem. and i can understand that. because the current tools don't give you many options and the current customers want *cheap* and not *good*. depressing but true. i also hear steve's point about not making things work *less* well. if we've learned anything from the md5 debacle it is that it is easy to create a new vulnerability or attack vector while preventing a non-problem. so it's prudent to be cautious. but i would suggest that doing anything that could *delay* a *new* announcement on a *new* path is completely acceptable. it's already happening now for edge ASes. you get new space. you contact your providers and peers and tell them to accept it. they do the same thing. and after a little while (usually more than a day but less than a week) the advertisements reach some plausible imitation of the global table and you call it good enough. so why not seriously consider options that don't impact existing routes on existing paths, but make it more difficult to get a new prefix working on a never-before-seen origination path pattern? like steve, i haven't yet formed an opnion on soBGP or sBGP (other than the fact that they've obviously been around for a while and obviously aren't being implemented by anyone yet). so my comments are more general. t. -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: soBGP deployment
The thing we should keep in mind is that the problem set is really very limited. and if we just stick our heads in the sand, it will stay so? have we learned nothing about internet threat models in the last decade? there are very smart and nasty people out there, and there is a very high payoff for them to do bad things to the net. leave a hole, and they will find a way to profit using it. randy
Re: soBGP deployment
On 23.05 22:13, Tony Li wrote: ... We, as responsible operators/architects/vendors/coders need to pick a solution and field it. It may well be an interim solution, but we MUST act, and soon. We are already seeing the stress patterns, without reinforcement it is only a matter of time before we see wholesale fractures. Given that any solution will have an implementation and deployment delay, we dare not wait much longer. From discussions with large operators during NANOG week it is clear to me that at this point most will simply not deploy anything that dynamically interacts with their inter-domain routing (BGP). All are comforatble with deploying something that works via the current mechanism of periodically built configurations. In fact most said to wait for something that would take some of the heuristics out of that process. We will not get any deployment unless either that attitude changes or we engineer taking it into account. I prefer the latter. To me the first stage of any deployment becomes obvious then: Map the fucntionality of s*BGP into tools to build routing configurations from signed information distributed by whatever means. This will make rapid deployment possible with a high comfort level for operators which is key! It would bring immediate benefits and help us build and understand the databases that are necessary. In parallel we can develop more dynamic ways of distributing the information and interacting with BGP. If the design and trust model of s*BGP is indeed well conceived this will be attractive enough for operators to see deployment. Note that I am not advocating routing registries. I agree with those that consider them a failure although I have been a long time supporter. The idea is to start building the (signed) meta-information and using it as additional input to the configuration generation already done by operators. Ideally this would quickly obsolete from routing registries and many heuristics. Can such a first step of an incremental deployment be designed for any of s*BGP? Daniel
Re: soBGP deployment
On Mon, 23 May 2005, Tony Li wrote: Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address. - We have people (admittedly accidentally) advertising prefixes that they do not own and thereby overloading BGP. See the talk at the latest NANOG. - We have people intentionally out there forging /24's as an attack. - We have OTHER people out there flooding the networks with their /24's so that they are less vulnerable to attack by forged /24's, and thereby exacerbating the BGP overload problem. Almost any of the popular proposals (and some of the really old ones) will address all of these issues. But only if they are deployed. We, Speaking as one network operator who is less than excited about these efforts, here's my reasoning: I know all the issues up there are real, since I've occasionally heard about them happening. I understand the devastating consequences of somebody finding a sufficiently well connected unfiltered BGP session and using it to announce some important prefixes. I fully agree that it should be fixed. And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me. What I do see problems with on a fairly regular basis are legitimate routes getting deleted from filters and causing outages. Therefore, when somebody tells me they're going to make the Internet more reliable by adding more things that need to be done right to make a BGP announcement work, I get a bit apprehensive. When they further tell me it's going to get centralized, such that I'd no longer be dealing with multiple peers or upstreams maintaining multiple sets of filters that can be expected to not all break at the same time, I get even more nervous. I hope any solution that finally gets settled on for this is done with the recognition that the goal is to reduce outages overall, rather than trading one outage cause for another. -Steve
Re: soBGP deployment
Steve, I know all the issues up there are real, since I've occasionally heard about them happening. I understand the devastating consequences of somebody finding a sufficiently well connected unfiltered BGP session and using it to announce some important prefixes. I fully agree that it should be fixed. And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me. That's what we can say so far. Do you really want to wait until we have a major problem? The time to replace the cockpit doors was PRIOR to 9/11. Therefore, when somebody tells me they're going to make the Internet more reliable by adding more things that need to be done right to make a BGP announcement work, I get a bit apprehensive. When they further tell me it's going to get centralized, such that I'd no longer be dealing with multiple peers or upstreams maintaining multiple sets of filters that can be expected to not all break at the same time, I get even more nervous. I hope any solution that finally gets settled on for this is done with the recognition that the goal is to reduce outages overall, rather than trading one outage cause for another. Once again, I ask you to look a bit harder at the details before passing judgement. Incremental deployment of any authentication scheme can and must be done so that there are three classes of BGP paths: authenticated paths (highest preference) unauthenticated paths (next, still used) authentication failures (recorded, dropped, alarms triggered) If one does NOTHING, then your prefixes remain unauthenticated and used. Thus, there is no additional work to making a BGP announcement work. The additional work is only to make the announcement _secure_. Further, we will need to use multiple certificate authorities (for redundancy alone), with various certificates flying around from differing places along the AS path. So there's nothing about these schemes that is centralized from an operational sense. If your concern is that address space allocation is hierarchical, rooted in one of the RIR's, then this is not a new issue. Tony
Re: soBGP deployment
Daniel, Well, I wish I could have been part of the discussions that you had, as what you report is at variance with what I've heard. Fundamentally, there is a serious scalability issue with doing everything at configuration generation time. Since one cannot predict with certainty what AS paths will be seen for which prefix, one would have to authenticate each and every possible path and then encode the authenticated paths in the configuration. I am very sensitive to the plight of operators and do understand the need to preserve BGP stability. However, I think that there are alternative approaches that can provide such stability during deployment while remaining dynamic. For example, an operator can begin by enabling authentication on a BGP speaker that is wholly outside of the traffic path. Instability of this one speaker would have no effect on production traffic. Authentication alarms generated by this speaker could be set up to do nothing more than send a syslog message to operations personnel who would need to intervene manually to actually change production BGP path selection. For testing authentication, a host behind this speaker could monitor reachability. I'm hopeful that this type of approach is a reasonable compromise between operational needs of stability and the actual dynamic near-real-time authentication computations that need to occur for these solutions to be effective. I welcome feedback from those concerned, publically or privately. Regards, Tony From discussions with large operators during NANOG week it is clear to me that at this point most will simply not deploy anything that dynamically interacts with their inter-domain routing (BGP). All are comforatble with deploying something that works via the current mechanism of periodically built configurations. In fact most said to wait for something that would take some of the heuristics out of that process. We will not get any deployment unless either that attitude changes or we engineer taking it into account. I prefer the latter. To me the first stage of any deployment becomes obvious then: Map the fucntionality of s*BGP into tools to build routing configurations from signed information distributed by whatever means. This will make rapid deployment possible with a high comfort level for operators which is key! It would bring immediate benefits and help us build and understand the databases that are necessary. In parallel we can develop more dynamic ways of distributing the information and interacting with BGP. If the design and trust model of s*BGP is indeed well conceived this will be attractive enough for operators to see deployment. Note that I am not advocating routing registries. I agree with those that consider them a failure although I have been a long time supporter. The idea is to start building the (signed) meta-information and using it as additional input to the configuration generation already done by operators. Ideally this would quickly obsolete from routing registries and many heuristics. Can such a first step of an incremental deployment be designed for any of s*BGP? Daniel
Re: soBGP deployment
On Wed, 25 May 2005, Tony Li wrote: I know all the issues up there are real, since I've occasionally heard about them happening. I understand the devastating consequences of somebody finding a sufficiently well connected unfiltered BGP session and using it to announce some important prefixes. I fully agree that it should be fixed. And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me. That's what we can say so far. Do you really want to wait until we have a major problem? No. As I said, I understand that the results of somebody doing something malicious here would be bad. My point (covered in the paragraph you didn't quote) is that schemes for requiring the authentication of routing information can also cause problems (which could be major if they happen to the wrong prefixes). If we make the network more able to withstand worst case scenarios without doing damage to its ability to be stable in its every day environment, that's a clear win. If, on the other hand, we were to get the network into a situation where it was harder for terrorists to push it over but it fell over on its own with some regularity, that probably wouldn't be an improvement. I'm not saying don't secure BGP. I'm saying be very careful in doing so, if you want to convince network operators to implement it. I'll note that I'm not talking about soBGP specifically. I have read the RFC, but I'm still not sure I understand it sufficiently to pass judgement. -Steve
Re: soBGP deployment
I agree with Tony. No need to overcomplicate a problem. Today, more and more ISP verify routing, using prefixes or (less reliable) AS--es, taking them from different sources. If you be able to add, in small increments, certified information into this routes, OR create external source of such information, and intimidate people to use it, you will make a step toward the goal. _You must not rely_ is really very strong overcomplicating. There is better to build 90% reliable xxx-BGP extension which will work in 1 year, vs. designing theoretically ideal , 100% reliable solution and never be able to deploy it. (It reminds me SSL certificate problem - yes, you _should_ not rely on self signed certificates and on _in-band_ certificate delivery; anyway, using such certificates and such delivery is 1000 times better vs. using nothing /and danger of such usage is heavily overestimated by Verisign and other _fat certifiers_ sales. The same here - it is better to add any, simple information allowing to certify routes, instead of building the whole new system for this purpose.) - Original Message - From: Tony Li [EMAIL PROTECTED] To: Russ White [EMAIL PROTECTED] Cc: Geoff Huston [EMAIL PROTECTED]; Daniel Golding [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, May 23, 2005 10:25 PM Subject: Re: soBGP deployment -- You must not rely on routing to secure routing. I would like to point out that this goal is unnecesary. First, we need to understand that for ANY solution to be deployable, it must be incrementally deployable. We do not get an Internet-wide flag day for BGP. The Internet must continue to function, regardless of the percentage of NLRI that are actually authenticated. For the forseeable future, we will need to have a path selection policy that rejects any information that clearly fails authentication, continues to use unauthenticated prefixes, and prefers authenticated vs. unauthenticated. Second, validating a certificate must be doable even if the router is using unauthenticated prefixes to do so. Remember that the crypto properties of a certificate must make it unforgeable, and that routers must have at least one reference point in the web of trust. If the route to the root of that web is spoofed, then the crypto will not be able to validate any other certificates in the web, but this is NOT an authentication failure -- the related NLRI are just unauthenticated, not unuseable. Obviously, authenticating the root certificate NLRI are our top priority, but the system MUST continue to operate even without this. This is the only way to truly address the chicken and egg problem. I think that this also highlights the need for multiple, diversely routed certificate authorities. Tony
Re: soBGP deployment
* Steven M. Bellovin: Fundamentally, the answer to this question is this: how accurate do you think the routing registries are? I don't think it's important how accurate they are *now*, but how accurate they will be when some secure BGP version makes them (or, more precisely, the route registration process) the weakest link in the chain. The fact that careful checking on the ISP side protects other ISPs only (and your own business interests just in a very indirect fashion) makes me believe that securing BGP will be *very* hard.
Re: soBGP deployment
Yes, corect - registry is as accurate as it used for the routing decisions. The more it is used, the better is feedback and the faster it will fix unavoidable errors. No one registry can be accurate until it is used for every day operations. - Original Message - From: Florian Weimer [EMAIL PROTECTED] To: Steven M. Bellovin [EMAIL PROTECTED] Cc: Pekka Savola [EMAIL PROTECTED]; Randy Bush [EMAIL PROTECTED]; vijay gill [EMAIL PROTECTED]; nanog@merit.edu Sent: Tuesday, May 24, 2005 1:44 AM Subject: Re: soBGP deployment * Steven M. Bellovin: Fundamentally, the answer to this question is this: how accurate do you think the routing registries are? I don't think it's important how accurate they are *now*, but how accurate they will be when some secure BGP version makes them (or, more precisely, the route registration process) the weakest link in the chain. The fact that careful checking on the ISP side protects other ISPs only (and your own business interests just in a very indirect fashion) makes me believe that securing BGP will be *very* hard.
Re: soBGP deployment
Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it. Who populates the DNS (well, the .arpa domain)? The RIRs do. So, have we established that the RIRs are trustworthy organizations that can act as the root of a distributed database hierarchy? Does anyone really disagree with this? Note that there are mechanisms outside of the IETF to set up and operate a distributed database for validation of route announcements. As Bill Manning pointed out, you can piggyback something on DNS, or you could ask the RIRs to make the route registries work more like DNS or you could ask the RIRs to do something else. Since the RIRs are open and pulic organizations responsive to the network operators who are the members, it is not necessary to go to the IETF and argue with vendors to get something implemented. Not all problems should be solved inside a box with Cisco or Juniper on written on it. --Michael Dillon
Re: soBGP deployment
the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? Since S-BGP overloads signatures into the current packet formats, destroys packing, and destroys peer groups, I'm not certain that you can make the claim that S-BGP has a lower impact on BGP than soBGP does. In fact, to the contrary, you might have noticed that the transport draft is set up all on its own, specifically so any other transport could be substituted. If someone wants to deploy some other transport, and there's community interest in doing so, then soBGP could be done without touching BGP at all. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
- soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path. further, the latter, because it relies on a separate data set for path validity, has serious and very kinky temporal sync problems. *sigh* Once again: This data is updated at the same rate and in the same way as BGP routing data. Randy, if you're going to ignore me, and you _claim_ to have read teh soBGP drafts, you could at least tell the truth about the way soBGP works. I don't lie about S-BGP, I know how it works, and understand its good and bad points. This is an issue of _design tradeoffs_, plain and simple, as all security is. If I had infinite money, I might live in a burglarproof house. I don't, hence, I accept some level of break in risk. This is the way life is. If I had infinite processing power and infinite bandwidth across every link, my tradeoffs are different when considering the options available. i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes. I have this: A---BC || +---D+ A is dual homed to B and D, and is advertising 10.1.1.0/24 through both. A removes its connection to B, but continues its connection through D. D is aggregating to 10.1.0.0/16, just to make things interesting. How long can B continue advertising the _fully signed_ and, to C, fully secure path to 10.1.1.0/24 through a path that no longer exists? No matter how long you make the timestamp, it's too long (and how long _is_ S-BGP's timestamp??). The possible attacks of this nature against signature based systems are limitless. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? Well gee Randy, I think you would have been happy. Here we are carrying related data in the same place. related, but not congruent. so it is just another transport, and one which provides no advantages, e.g. security, over any other transport for the same data. randy
Re: soBGP deployment
Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address. wrong. as deployment will be expensive and long, we will have one chance to deploy. so need a serious solution set for what we have to consider to be a very serious attack model. plan for attacks against the routing system as smart, well-researched, constant, ... as the best we see against ssh, htt, ... today. randy
Re: soBGP deployment
the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? Since S-BGP overloads signatures into the current packet formats, destroys packing, and destroys peer groups, I'm not certain that you can make the claim that S-BGP has a lower impact on BGP than soBGP does. then i guess i am very lucky not to have made such a claim. the point is that sbgp's changes, while more than one might prefer, are made so that congruent data, path attestation, can be carried in-band. i consider the trade-off worthwhile for the seriously improved security, which is the point of the exercise. randy
Re: soBGP deployment
Randy, wrong. as deployment will be expensive and long, we will have one chance to deploy. so need a serious solution set for what we have to consider to be a very serious attack model. plan for attacks against the routing system as smart, well-researched, constant, ... as the best we see against ssh, htt, ... today. Baloney. Deployment need not be expensive or long. And updates and enhancements need not be expensive or long either. Updates can be enabled on a per-BGP peer basis and thru careful use of capability bits can be nearly automatic. We need to decide what we are going to do, we need to code it, test it and field it. I seem to recall that in the good old days we did this in the space of a year. Tony
Re: soBGP deployment
On Sat, 21 May 2005, Pekka Savola wrote: There's nothing to say the functional equivalent of certificate could also not be passed in an option or some other means as well when needed. My assumption would be that being able to use public databases would be a protocol optimization. I think people here are missing fundamental issue. It is not with how in particular signed data is passed (although that is important and certainly SBGP is doing it in more secure way then soBGP ) but with who can vouch for the signed data, i.e. its the distribution of authoritive data. It should be understood that its not only that you need to lookup policy for ASN and see if it can announce ip block but it should be possible to verify that ip block owner gave that ASN permission to announce the block, The way it should work is that ASN gives ip block owner its cert, ip block owner signs it with its private key and the new signed cert is given back to ASN. Now ASN can give this cert to anybody else and they can verify (assuming access to public key of ip block owner is available) that ASN has right to announce the block. For peer relationships it works in similar way, when ASN1 wants ASN2 to announce its routes, it asks ASN2 to give it its public cert, then ASN1 signs the cert and gives it back to ASN2. Now here is worst part, ip block owner can not be trusted just because they gave you certificate that says 192.168.0.0/24. IP block owner's certificate itself should be signed by known trusted party that can vouch for that block owner, i.e. whoever gave the ip block, i.e. RIR or another RIR that allocated the block. So to get this all in place and working we need to develop a complete root-enduser public key distribution infrastructure working all the way from RIR to the LIR to ISP and from one ISP to another and I don't see it happening. Right now RIRs only recently started offering X.509 certs for updating whois (and ARIN, for example specifically said their cert is to be used only when talking to ARIN and is not intended for anything else) so the next step is try to to test if same cert can be used for signing data related to routing policies and if it works then we should begin to be worried on how best to distribute the end-resulting signature. Regarding distribution, I think routing registry is fine for initial deployment (as long as root certificate is signed by known trusted authority, which is one of the RIRs) as that can be done faster and it is less intrusive on BGP infrastructure. Ones we have some success with routing registries and signed data, then we can work further start moving with signed data sent with BGP but that should be done slowly in the way that makes sure those who do not support it do not suffer, so basically a new parameter would be required for peering setup for both sites when they want to talk S-BGP and it would be necessary for all routers in the middle to support it for end-end to work. Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. Note that there's no technical reason AFAICS not to tie the signed origin statements to the origin's AS number, i.e., if someone would want to hijack a prefix, it would need to spoof the AS number as well. Not sure if that helps a lot, of course. As I described that above, it would not help with man in the middle if that middle ASN adds an appropriate origin ASN in its announcement and the path itself is not signed. But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.). Personally I'd certainly hope so -- because the practical deployment issues with the on-the-path signing model seem prohibitive (too much 3rd party deployment required before the solution would be useful). A full solution is of course having each middle-ASN further sign the prefix it is transmitting, but I can only see that happening and working properly if SBGP id deployed slowly for each router and that would take long time. Quick way out that is using certificates that allow to verify peering relationship (but not necessarily actual route announcement). But that does require going through each ASN1 ASN2 pair in routing table and trying to check if its correct - would require specially designated equipment to sort out all these relationships and cache cryptographic or
Re: soBGP deployment
On Sat, 2005-05-21 at 16:03 -0400, Steven M. Bellovin wrote: Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true. There's a very simple reason why registries have not been kept up to date over the past decade -- many operators do not use them for generating their policy configurations. Given this situation, it's difficult to draw any conclusions from the last decade. If you look back to the NSFNet days (prior to a decade ago) and the PRDB (Policy Routing Database), you might very well draw a different conclusion. The PRDB was kept up to date because a database entry was required to transit the NSFNet. This is not to imply that registries should play anything more than an interim role. Nonetheless, there would seem to be opportunities to improve current operational practices until more secure solutions are deployed. -Larry Blunk Merit
Re: soBGP deployment
If you look back to the NSFNet days (prior to a decade ago) and the PRDB (Policy Routing Database), you might very well draw a different conclusion. indeed, one of utter disaster. it would take days or weeks before one could route a prefix. randy
Re: soBGP deployment
On Mon, 2005-05-23 at 10:11 -0400, Randy Bush wrote: If you look back to the NSFNet days (prior to a decade ago) and the PRDB (Policy Routing Database), you might very well draw a different conclusion. indeed, one of utter disaster. it would take days or weeks before one could route a prefix. I suspect this was due to the fact that template submissions were not fully automated at the time and required human review (disclaimer: I worked for the MichNet side of Merit back then and was not intimately familiar with PRDB operations). -Larry
Re: soBGP deployment
my weak memory, it was due to a number of factors, some in the database update workflow, some in the uneven usage workflow, e.g. ans updating once, or was it twice, a week. but this just underscores the difference here o with sbgp, the assertion of the validity of asn A announcing prefix P to asn B is congruent with the bgp signaling itself, A merely signs the assertion in the bgp announcement. o with sobgp, the assertion is in an external database with issues such as - data correctness completeness - data consistency - update frequency - granularity (bgp is per-prefix, and this is used by real folk to do traffic eng etc). consider the mess of keeping this up to date and correct in a super irr. - etc its the old simplicity vs complexity game yet again randy
Re: soBGP deployment
On 23-mei-2005, at 17:39, Randy Bush wrote: o with sbgp, the assertion of the validity of asn A announcing prefix P to asn B is congruent with the bgp signaling itself, A merely signs the assertion in the bgp announcement. o with sobgp, the assertion is in an external database with issues such as This is nonsense. Did you even read the soBGP drafts? In S-BGP the certificates are carried in path attributes, in soBGP in a new BGP message. Other than that, they do not differ in this regard. And unless the implementations are stupid, it should be simple enough to use a web of trust rather than a fixed trust hierarchy, so the RRs don't (necessarily) come into play. its the old simplicity vs complexity game yet again Do I hear you say that S-BGP is less complex than soBGP??
Re: soBGP deployment
but this just underscores the difference here its the old simplicity vs complexity game yet again Why should the IETF be making the tradeoff decision here rather than the operators? It seems to me that a more workable solution in today's Internet, is to decouple the definition of the information exchanged by network operators from the protocol used to exchange the information. It should be possible to design a system in such a way that a network operator can choose whether or not to do this job directly on their BGP-speaking routers or whether to offload it onto some type of route-registry database system. In fact, it should be possible for a single AS to vary which model it follows because in larger networks there is less homogeneity, i.e. some BGP routers are far more mission critical and carry higher traffic levels than others. Rather than looking for something that is 100% overloaded on the BGP-speaking routers, why not give network operators the tools to make their own 80-20 decisions about where this network management function should be handled? --Michael Dillon
Re: soBGP deployment
At 11:27 -0400 5/23/05, Larry J. Blunk wrote: I suspect this was due to the fact that template submissions were not fully automated at the time and required human review (disclaimer: I worked for the MichNet side of Merit back then and was not intimately familiar with PRDB operations). It could have been the tools. (I can't argue, I wasn't there.) Here's another thought. Much like the comparison of SSH and DNSSEC in this reply of mine from last March: http://www.merit.edu/mail.archives/nanog/2005-03/msg00694.html I.e., the mythical core needs work. This time it's the address organizations and routing elements. Yet another thought. Skimming through this thread, and only being slightly aware of sBGP and soBGP in past years, some concepts remind me of work under DARPA's Active Nets research done in the late 90's. (http://www.darpa.mil/ato/programs/activenetworks/actnet.htm) Some things I learned then: 1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood). 2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.) IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)? Dijkstra's shortest path algorithms (an example IGP) work in the plane because it manages to mimic the ubiquitous view. You aren't afraid that someone is not playing my the rules. When you are working with security (algorithms), you don't have that safety belt. And a final thought... Security ought to not make the system being protected brittle. Like the example of routing changes being held up until the paperwork went through - maybe an improvement in tools will enable this. But think of the long term impact - who will be paying to keep the tools and system up to date? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
In message [EMAIL PROTECTED], Iljitsch van Beijn um writes: On 23-mei-2005, at 17:39, Randy Bush wrote: o with sbgp, the assertion of the validity of asn A announcing prefix P to asn B is congruent with the bgp signaling itself, A merely signs the assertion in the bgp announcement. o with sobgp, the assertion is in an external database with issues such as This is nonsense. Did you even read the soBGP drafts? In S-BGP the certificates are carried in path attributes, in soBGP in a new BGP message. Other than that, they do not differ in this regard. Randy isn't talking about certificates, he's talking about how you tell if a path is legitimate. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: soBGP deployment
On Mon, 23 May 2005, Edward Lewis wrote: 1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood). That is why in my view soBGP is something that can only be deployed as an after-filter (i.e. ones full BGP mesh is in for decisions about if the routing data is to be passed along to other peers or to IGP). 2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.) IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)? You do need trusted third party to act as PKI root signer. We're lucky because unlike other places, we do have hierarchy with ip addresses and ASNs and NIR is the root organization. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: soBGP deployment
for the old-timers this is not quite sBGP or soBGP, but does have many of the desirable traits for the new kids on the block, if ISPs want to do this, its something they can do themselves, w/o centralized coordination, on an incremental basis. http://www.isoc.org/inet98/proceedings/6h/6h_3.htm --bill
Re: soBGP deployment
At 10:37 -0700 5/23/05, william(at)elan.net wrote: You do need trusted third party to act as PKI root signer. We're lucky because unlike other places, we do have hierarchy with ip addresses and ASNs and NIR is the root organization. Don't confuse cryptography with security. You need one trusted third party to arrange for the cryptography to scale (work). You need a different third party to help authenticate (secure) the routing data. IMHO, you don't necessarily want these two third parties to be the same. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
I suspect the right thing to do is to ask why soBGP and sBGP have failed? And yes, they've failed. Just like DNSSec, we aren't seeing even limited adoption. Why? Too complex, too many moving parts, too much reliance on iffy third parties and requires mass adoption. I suggest that the community finds something that gives us most of what we want, is simple to understand, and can be implemented in a piece-wise fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy to implement, and IS being implemented. One of the Internetworking community's biggest problems is a fixation on the perfect solution. Its natural - we're engineers, after all. We want an elegant 100% solution to our ills. This often leads to something that never gets implemented in real life. Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it. Ok, please start flaming now :) - Dan On 5/23/05 1:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: for the old-timers this is not quite sBGP or soBGP, but does have many of the desirable traits for the new kids on the block, if ISPs want to do this, its something they can do themselves, w/o centralized coordination, on an incremental basis. http://www.isoc.org/inet98/proceedings/6h/6h_3.htm --bill
Re: soBGP deployment
On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote: I suspect the right thing to do is to ask why soBGP and sBGP have failed? And yes, they've failed. Just like DNSSec, we aren't seeing even limited adoption. Why? Too complex, too many moving parts, too much reliance on iffy third parties and requires mass adoption. I suggest that the community finds something that gives us most of what we want, is simple to understand, and can be implemented in a piece-wise fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy to implement, and IS being implemented. sidetrack SPF gets implemented by a few. I won't implement it simply because it will break my mailsetup because the mechanism format does not allow optional mechanisms to be defined eg, if I would use in DNS: v=spf1 ip6:2001:db8::/48 -all Any host which implements SPF checks but does not know how to do ip6 checks, even though the message went 100% through an IPv6 only path will drop the mail in the trashcan, even though the mail is 100% legit. But this is a non-issue of course as everybody uses IPv6 only... just like nobody uses DNSSec and other cool toys. /sidetrack SNIP Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. sarcastic smiling comment But you are the fool here /sa So your router boots and receives a prefix and then you are going to check using the just received prefix if it is legit to be sent from that ASN, remember that it was just faked :) Or do it before you get it and thus don't have a route... L3 on L3 dependencies don't work unfortunately. I am really glad the IETF has a lot of people who catch above things quite easily because of expertise and experience. Btw pretty accurate is not good enough unfortunately... Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: soBGP deployment
On Mon, May 23, 2005 at 08:15:15PM +0200, Jeroen Massar wrote: On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote: I suspect the right thing to do is to ask why soBGP and sBGP have failed? And yes, they've failed. Just like DNSSec, we aren't seeing even limited adoption. Why? Too complex, too many moving parts, too much reliance on iffy third parties and requires mass adoption. I suggest that the community finds something that gives us most of what we want, is simple to understand, and can be implemented in a piece-wise fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy to implement, and IS being implemented. sidetrack SPF gets implemented by a few. I won't implement it simply because it will break my mailsetup because the mechanism format does not allow optional mechanisms to be defined eg, if I would use in DNS: v=spf1 ip6:2001:db8::/48 -all Any host which implements SPF checks but does not know how to do ip6 checks, even though the message went 100% through an IPv6 only path will drop the mail in the trashcan, even though the mail is 100% legit. But this is a non-issue of course as everybody uses IPv6 only... just like nobody uses DNSSec and other cool toys. /sidetrack SNIP Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. sarcastic smiling comment But you are the fool here /sa So your router boots and receives a prefix and then you are going to check using the just received prefix if it is legit to be sent from that ASN, remember that it was just faked :) Or do it before you get it and thus don't have a route... L3 on L3 dependencies don't work unfortunately. I am really glad the IETF has a lot of people who catch above things quite easily because of expertise and experience. Btw pretty accurate is not good enough unfortunately... Greets, Jeroen ah... but my old hack did -NOT- have the circular dependency you point out (and not for the last time either...) and yes, thanks to the IETF for being on top of this. --bill
Re: soBGP deployment
At 14:00 -0400 5/23/05, Daniel Golding wrote: My reply is mostly tongue-in-cheek. I think it's always healthy to explore alternatives. Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. I'll ignore that you said (or use a TXT record). ;) Without DNSSEC, what does this buy? Secure information on a non-secure channel. If, by stealing addresses you mean that the RIR records are changed, then changing the name servers is trivial - changing to servers that have the hijacker's preferred data (or none!). Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it. Who populates the DNS (well, the .arpa domain)? The RIRs do. Ok, please start flaming now :) Brave to make such a request on a Monday afternoon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
At 04:00 AM 24/05/2005, Daniel Golding wrote: I suspect the right thing to do is to ask why soBGP and sBGP have failed? And yes, they've failed. Just like DNSSec, we aren't seeing even limited adoption. Why? Too complex, too many moving parts, too much reliance on iffy third parties and requires mass adoption. Or maybe, jut maybe, because we've never had the tools to deploy it. Lets face it, larger operators, and probably small operators, are not protocol or code developers by nature. Operational skills are strongly honed on process definition and subsequent adherence to process, as well as skills in box opening ( :-) ). However, I suspect that this circular argument of vendors claiming customers never demanded it and customers saying that vendors never supplied it is largely an irrelevancy, and to infer from it that the entire activity space is moribund is perhaps stretching this particular set of excuses relating to inactivity a bit too far. The issue is that we all really do not appear to appreciate the disturbing nature of the risks here, and consequently we really don't value measures that attempt to address these risks. Generating authentic and trustable routing information to inject into the inter-domain routing system is one of those things that have to fit into an ISP's cost and revenue equation, and its often the case that this is not any easy fit. I'd contend that any robust form of certificate infrastructure that is strongly rooted in a trust anchor is far far better than what we have now (oh, please not the ring of trust stuff - it really is not enough in this case!) http://www.potaroo.net/ispcol/2005-02/index.html is one of many enumerations of the risks involved here. The IETF work in routing protocol security (RPSEC) has been working in this area for some time now and their documents about risks do not make comforting reading. And then theres the mechanisms for inserting the validation elements into the inter-domain routing protocol. Again http://www.potaroo.net/ispcol/2005-03/route-sec-2-ispcol.html is one of a number of commentaries on the topic. Why not do something simple? Probably because you need to cross over a threshold from doing something just to make you feel better about yourself into an industry collectively deploying a technology that can provide all of us with reliable indications as to the validity of the information we are passing about, as well as the authority to allow you and I to pass it around. The essential difference as far as I can see today between soBGP and sBGP in this space is that, as a 2 liner: - sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update. - soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path. In looking at this what I personally saw was a design tradeoff, where soBGP attempted to lighten the update load and the certification load by making one part of the BGP update message unprotected by a certificate set, while sBGP attempts to provide the receiver with sufficient information so as to allow the receiver to validate the entire update. Unfortunately I doubt whether we can ultimately afford the luxury of allowing each operator to select their favourite form of validation of routing information. It would be preferable, or at least useful, to have some guidance provided by a standards body as to what is a useful and reasonable security framework for securing inter-domain routing, together with a protocol specification for doing the same. Indeed I would've thought it was core business for a standards body to assist the industry in this manner. And, hopefully, it will happen soon in this case, rather than way too late. regards, Geoff
Re: soBGP deployment
One correction: I shouldn't have said: The RIRs are iffy. It should have been The IRRs are iffy. A world of difference. I understand the limitations. However, no one is rushing to implement most of the things that folks in this thread are obsessing over: DNSSec, IPV6, sBGP, soBGP. A bizarre assertion was made that only a few are implementing SPF, which is demonstrably untrue. Its getting implemented because its easy, not because its complete. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. - Dan On 5/23/05 2:33 PM, Edward Lewis [EMAIL PROTECTED] wrote: At 14:00 -0400 5/23/05, Daniel Golding wrote: My reply is mostly tongue-in-cheek. I think it's always healthy to explore alternatives. Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. I'll ignore that you said (or use a TXT record). ;) Without DNSSEC, what does this buy? Secure information on a non-secure channel. If, by stealing addresses you mean that the RIR records are changed, then changing the name servers is trivial - changing to servers that have the hijacker's preferred data (or none!). Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it. Who populates the DNS (well, the .arpa domain)? The RIRs do. Ok, please start flaming now :) Brave to make such a request on a Monday afternoon.
Re: soBGP deployment
On Mon, 23 May 2005 15:24:20 EDT, Daniel Golding said: A bizarre assertion was made that only a few are implementing SPF, which is demonstrably untrue. Its getting implemented because its easy, not It's easy to deploy an incomplete solution. Why does my Spidey-sense scream that this is a train wreck about to happen? ;) because its complete. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. There's probably a *large* difference between: a) The number of sites that deployed an SPF DNS entry b) The number of sites that bit the bullet and *didnt* put ~all at the end. c) The number of sites checking other site's SPF records d) The number of sites rejecting mail due to (possibly in part) bad/missing SPF. The number of sites doing (a) is likely high. How many are doing b-d? In addition, I suspect a large percentage of sites who deployed SPF to any extent are thinking it solves 70% of *one* problem, when it's actually a 70% solution for something else pgp8I1o9l3QZc.pgp Description: PGP signature
Re: soBGP deployment
On Mon, May 23, 2005 at 02:00:12PM -0400, Daniel Golding wrote: One of the Internetworking community's biggest problems is a fixation on the perfect solution. Its natural - we're engineers, after all. We want an elegant 100% solution to our ills. This often leads to something that never gets implemented in real life. But it's worth noting here that there's a good reason for that: It's *miserable* to replace a fundamental protocol with insufficiently forward-thinking design decisions, too. Viz: IPv6. So the real question is: where's the happy medium? Cheers, -- jr 'first person who says NBC is fired' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: soBGP deployment
It seems to me that a more workable solution in today's Internet, is to decouple the definition of the information exchanged by network operators from the protocol used to exchange the information. It should be possible to design a system in such a way that a network operator can choose whether or not to do this job directly on their BGP-speaking routers or whether to offload it onto some type of route-registry database system. In fact, it should be possible for a single AS to vary which model it follows because in larger networks there is less homogeneity, i.e. some BGP routers are far more mission critical and carry higher traffic levels than others. This is specifically how soBGP is designed. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
o with sbgp, the assertion of the validity of asn A announcing prefix P to asn B is congruent with the bgp signaling itself, A merely signs the assertion in the bgp announcement. o with sobgp, the assertion is in an external database with issues such as - data correctness completeness The database is built just like BGP routing information databases are built today. Each AS originates their piece, and every other AS puts the pieces together to form the whole. There is no centralized registry. - data consistency - update frequency These two are up to the originating AS'. If you update your certificates in real time, the same way you do your routes (and I can easily argue you don't actually update your routes in real time, actually), then you will get congruent, up to date information. Those AS' who do not update their certificates in real time will not have real time data in the database, just like BGP is today. - granularity (bgp is per-prefix, and this is used by real folk to do traffic eng etc). consider the mess of keeping this up to date and correct in a super irr. There is no super irr. There is no centralized database in soBGP. Period. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood). That is why in my view soBGP is something that can only be deployed as an after-filter (i.e. ones full BGP mesh is in for decisions about if the routing data is to be passed along to other peers or to IGP). I don't understand this assertion. I get the feeling there's not a lot of understanding about how soBGP actually works An AS _does not_ connect to a centralized location of any type with soBGP. You receive certificates through one of several possible sources, including a new message type within BGP itself--so you can receive certificates through set aside BGP sessions, or through normal peering, whichever way makes more sense for your architecture. Once you have these certificates, you build a database of validated certificates that attest to specific information, including origination authentication and paths, and you _can_ (though no-one is forcing anyone to) also hang policy off this database. This operates in exactly the same way as BGP does today. It's distributed, peer to peer. As long as your interface to all your external peers is consistent, it will work, no matter how you implement it internally--just like you can use confeds, route reflectors, full mesh iBGP, route servers, or anything you like within your AS with BGP today. 2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.) AFAIK, you can't strip sig's out of S-BGP because of the way the sigs are built. You can't strip sig's out of soBGP because they simply aren't there. soBGP does not touch, in any way, shape, or form, the current BGP packets. There are additional message types proposed, but these in no way impact any current NLRI information, at all. IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)? This is exactly how link state protocols work, no? They talk to their nearest set of neighbors, but then they build a complete SPF from the information they gain through this discussion. This is, precisely, how soBGP validates paths. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
The essential difference as far as I can see today between soBGP and sBGP in this space is that, as a 2 liner: - sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update. - soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path. I would restate soBGP's in this way: - soBGP allows the receiver to determine that the AS PAth describes a path that actually exists, anchored at the beginning with the originating AS, and anchored at the end with the advertising AS, but cannot validate that the update itself traversed this path. This is a very good summation of the points between the two concepts--using something that signs actual routing information passing through the system (including, but not limited to S-BGP), or describing the routing system dynamically and in real time, and deciding if the routing information you're receiving actually matches the description you've built (soBGP, IRV, and even reverse DNS lookup solutions are all within this camp). There are more tradeoffs than apparent here, so look carefully. :-) For one, it's harder to make a strong case that it matters where the update has been than it appears at first glance--the first and obvious answer is to say that you can gather policy based on the path the update has taken. This isn't true in a routing system, however, because of aggregation and filtering, first, and because packets don't _necessarily_ follow the path of the update, second In looking at this what I personally saw was a design tradeoff, where soBGP attempted to lighten the update load and the certification load by making one part of the BGP update message unprotected by a certificate set, while sBGP attempts to provide the receiver with sufficient information so as to allow the receiver to validate the entire update. Somewhat, yes soBGP's original design goal set was: -- Do not touch BGP as it exists today. Make it run without modifying packet formats, etc. -- Do not require a centralized registry of information. -- You must not rely on routing to secure routing. -- Do not require the crypto to be done on box or off box, just let the crypto be done in the most logical place possible, which varies from AS to AS. -- Do not require each AS to have the same security policy. Internetworks and AS' within internetworks vary, the same size does _not_ fit all. This seemed like a pretty good set of goals, when we started. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
At 3:24 PM -0400 2005-05-23, Daniel Golding wrote: A bizarre assertion was made that only a few are implementing SPF, which is demonstrably untrue. It depends on whether you're talking about few relative to the number of mail systems in the world, or few relative to the number of users served by those mail systems. If you're talking about users, then all you have to do is implement SPF at a few large sites like AOL, where they don't support forwarding and therefore they don't care if they break forwarding, where they want to force everyone to use their outbound mail relay servers anyway, etc Do that, and you've got a majority. If you're talking about mail systems, it's a whole different picture. Setting up TLSSMTP or SMTPAUTH is non-trivial, even for experienced admins. Indeed, many experienced admins may own their own domains, but not run their own machines. Even if the server side is capable of supporting TLSSMTP and/or SMTPAUTH, they may well be using clients which are not capable of doing so, or not capable of doing so interoperably with the server side. Much, much more difficult to get large numbers of installations. Penetration of SPF is pretty low, and it's likely to stay that way for the foreseeable future. The problems with SPF are pretty basic, and I don't see them being eliminated any time soon with a casual wave of your royal hand. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. And if twelve people told you that you'd have to implement twelve different incompatible systems, and each of them would give you a different 70% of the benefit for 10% of the effort (but only if they were the only solution implemented), what would you do? The IETF has taught us that multiple incompatible partial solutions is not a particularly desirable outcome. That way lies madness. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: soBGP deployment
You do need trusted third party to act as PKI root signer. We're lucky because unlike other places, we do have hierarchy with ip addresses and ASNs and NIR is the root organization. Don't confuse cryptography with security. You need one trusted third party to arrange for the cryptography to scale (work). You need a different third party to help authenticate (secure) the routing data. IMHO, you don't necessarily want these two third parties to be the same. One of, perhaps, the most confusing aspects of soBGP is that there are four certificates. Why not just do one certificate? Because of this specific separation 1. We need someone to verify X's key is really X's key. We believe SP's won't, necessarily, want to be in this business. 2. We need someone to verify X is allowed to advertise Y. We believe RR' and SP's will probably be in this business, whether or not they like it. 3. We need some way for a local AS to express various things that don't need to be signed by some third party, connectivity and policy, specifically. We want different chains of trust--one person to say this is X's key, another to say: this is X's address space. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
o with sbgp, the assertion of the validity of asn A announcing prefix P to asn B is congruent with the bgp signaling itself, A merely signs the assertion in the bgp announcement. o with sobgp, the assertion is in an external database with issues such as This is nonsense. Did you even read the soBGP drafts? yes In S-BGP the certificates are carried in path attributes, in soBGP in a new BGP message. Other than that, they do not differ in this regard. you are confusing certificates and the attestation of routing policy. Do I hear you say that S-BGP is less complex than soBGP?? yes randy
Re: soBGP deployment
the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? randy
Re: soBGP deployment
On 5/24/05, Brad Knowles [EMAIL PROTECTED] wrote: If you're talking about users, then all you have to do is implement SPF at a few large sites like AOL, where they don't support forwarding and therefore they don't care if they break forwarding, where they want to force everyone to use their outbound mail relay servers anyway, etc Do that, and you've got a majority. Two levels of SPF - 1. publishing conservative enough spf records to do the least damage but look good (~all or ?all instead of -all) - every man and his dog (eoe people like us who have removed all our spf records) does that these days after AOL announced they'd use published spf records to maintain their whitelist and feedback loop 2. Rewriting return paths using SRS/SES for forwarded mail, and checking + rejecting based on spf failures srs (http://www.circleid.com/article.php?id=1039_0_1_0_C/ for more) If you're talking about mail systems, it's a whole different picture. Setting up TLSSMTP or SMTPAUTH is non-trivial, even for experienced admins. Indeed, many experienced admins may own their own domains, but not run their own machines. Even if the server side is capable of supporting TLSSMTP and/or SMTPAUTH, they may well be using clients which are not capable of doing so, or not capable of doing so interoperably with the server side. Much, much more difficult to get large numbers of installations. Penetration of SPF is pretty low, and it's likely to stay that way for the foreseeable future. The problems with SPF are pretty basic, and I don't see them being eliminated any time soon with a casual wave of your royal hand. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. And if twelve people told you that you'd have to implement twelve different incompatible systems, and each of them would give you a different 70% of the benefit for 10% of the effort (but only if they were the only solution implemented), what would you do? The IETF has taught us that multiple incompatible partial solutions is not a particularly desirable outcome. That way lies madness. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: soBGP deployment
I suspect the right thing to do is to ask why soBGP and sBGP have failed? Or maybe, jut maybe, because we've never had the tools to deploy it. actually, we had a small workshop with sbgp tools at the last eugene nanog. perhaps it's time for another? bill, can you host at he next nanog, as it is on your turf? but, of course, for real deployment, those tools, built for *bsd and linux, would limit initial deployment to those running pc-based routers. to go futher, we would need support from juniper and other vendors. - sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update. - soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path. further, the latter, because it relies on a separate data set for path validity, has serious and very kinky temporal sync problems. i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes. randy
Re: soBGP deployment
On Mon, May 23, 2005 at 11:06:23PM -0400, Randy Bush wrote: I suspect the right thing to do is to ask why soBGP and sBGP have failed? Or maybe, jut maybe, because we've never had the tools to deploy it. actually, we had a small workshop with sbgp tools at the last eugene nanog. perhaps it's time for another? bill, can you host at he next nanog, as it is on your turf? sure... point me in the right direction :) but, of course, for real deployment, those tools, built for *bsd and linux, would limit initial deployment to those running pc-based routers. to go futher, we would need support from juniper and other vendors. yes... but it is possible to get the ISP engineering crews to kick the tyres w/ generic platforms. i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes. surrender! randy
Re: soBGP deployment
i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes. Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address. - We have people (admittedly accidentally) advertising prefixes that they do not own and thereby overloading BGP. See the talk at the latest NANOG. - We have people intentionally out there forging /24's as an attack. - We have OTHER people out there flooding the networks with their /24's so that they are less vulnerable to attack by forged /24's, and thereby exacerbating the BGP overload problem. Almost any of the popular proposals (and some of the really old ones) will address all of these issues. But only if they are deployed. We, as responsible operators/architects/vendors/coders need to pick a solution and field it. It may well be an interim solution, but we MUST act, and soon. We are already seeing the stress patterns, without reinforcement it is only a matter of time before we see wholesale fractures. Given that any solution will have an implementation and deployment delay, we dare not wait much longer. Tony
Re: soBGP deployment
-- You must not rely on routing to secure routing. I would like to point out that this goal is unnecesary. First, we need to understand that for ANY solution to be deployable, it must be incrementally deployable. We do not get an Internet-wide flag day for BGP. The Internet must continue to function, regardless of the percentage of NLRI that are actually authenticated. For the forseeable future, we will need to have a path selection policy that rejects any information that clearly fails authentication, continues to use unauthenticated prefixes, and prefers authenticated vs. unauthenticated. Second, validating a certificate must be doable even if the router is using unauthenticated prefixes to do so. Remember that the crypto properties of a certificate must make it unforgeable, and that routers must have at least one reference point in the web of trust. If the route to the root of that web is spoofed, then the crypto will not be able to validate any other certificates in the web, but this is NOT an authentication failure -- the related NLRI are just unauthenticated, not unuseable. Obviously, authenticating the root certificate NLRI are our top priority, but the system MUST continue to operate even without this. This is the only way to truly address the chicken and egg problem. I think that this also highlights the need for multiple, diversely routed certificate authorities. Tony
Re: soBGP deployment
On 21-mei-2005, at 20:25, Randy Bush wrote: If you are an operator, would you deploy soBGP or something like it? If not, why not. [skip to the bottom for my reaction to Randy's post] I think it would be a very good idea to start experimenting with this as soon as there are decent implementations. The operational problem that soBGP will hopefully solve for me is peering with lots of relatively small peers, some of whom may be clue- challenged with regard to inter-domain routing. (AS number consumption seems to be higher than BGP book consumption...) It's not the really small networks that are the biggest problem, BTW. It's the ones that have a few BGP customers but not enough to really know how to filter them properly that are the most dangerous. The trouble is that today, I basically have three choices: 1. Generate filters from a routing registry. Here in RIPE country, we have a pretty good routing registry, because it's also the RIR database. Still, many people don't register their stuff, or don't register it correctly. And the tools necessary to generate configurations are _very_ hard to use. Also, if something goes wrong, my filters are zapped with unpredictable results. So basically I'd have to work very hard to get something that doesn't work properly and will kill my network if it fails. 2. Maintain filters manually. That won't scale, so the fact that peers usually don't inform you when they have new announcements etc doesn't even matter. 3. Use max-prefix and push a virgin into the volcano once in a while. The nice thing about something like soBGP is that it makes it possible to work together to solve this problem rather than everyone having to do it on their own. For instance, if I know that networks X and Y have very high standards and when they say something is ok, it is, I could accept certificates signed by X or Y. This only requires the bare minimum of clue from the origin AS: they need to include the signed certificate, not much more. When something goes wrong, the worst thing that can happen when (for instance) Y screws up, is that I lose some peering routes, or I potentially allow some routes that shouldn't be allowed. The former case isn't all that bad: I still have all the routes for which I don't depend on Y. The latter case could be problematic, but it would be hard for an attacker to abuse this situation as she still has to corrupt the source or neighbor ASes in question. I'm not saying this will solve all our problems, but I think there is a lot of potential here, and we need some operational experience to guide further development. something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality, S-BGP signs every update. This is problematic in several ways. A receiver needs to check all AS hops in each AS path (that would be ~500k for a full BGP table), which means you are pretty much forced to have a crypto accelerator on board. Also, no more peer group update optimization, so when you have a lot of peers you're going to burn much more CPU time for every update. Last but not least: because S-BGP signs updates, a secret key must be present inside the router, making physical security much more important. and does not rely on a published policy database, which we have seen fail for over a decade, etc. soBGP and S-BGP aren't different in this regard, AFAIK. I don't think either needs a published policy database but obviously they need some trust anchors and access to policy information in some way. we should learn from the decade-long problems with the deployment issues in dnssec, and map routing security as closely as possible to operational protocol and reality. If you give people an incentive to use a technology, you'll see the use of that technology increase over the situation prior to the incentive. :-) (See MD5 last year.)
Re: soBGP deployment
If you are an operator, would you deploy soBGP or something like it? If not, why not. as smb has said for years, routing and dns are the two largest vulnerabilities. something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality, and does not rely on a published policy database, which we have seen fail for over a decade, etc. we should learn from the decade-long problems with the deployment issues in dnssec, and map routing security as closely as possible to operational protocol and reality. randy
Re: soBGP deployment
On Sat, 21 May 2005, Randy Bush wrote: something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality, and does not rely on a published policy database, which we have seen fail for over a decade, etc. So, can someone point out the important operational differences between the two? From 10K feet view, the only major difference seems to be that sBGP also wants to protect the BGP sessions w/ IPsec all in one solution. (Personally, I don't care about that all that much, and I have some doubts whether this is a good approach for deployability in mind.) Maybe the important operational differences are only observable from 1K feet view ? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: soBGP deployment
In message [EMAIL PROTECTED], Pekka Savola writes: On Sat, 21 May 2005, Randy Bush wrote: something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality, and does not rely on a published policy database, which we have seen fail for over a decade, etc. So, can someone point out the important operational differences between the two? From 10K feet view, the only major difference seems to be that sBGP also wants to protect the BGP sessions w/ IPsec all in one solution. (Personally, I don't care about that all that much, and I have some doubts whether this is a good approach for deployability in mind.) The IPsec piece is actually the least important part of the difference. Maybe the important operational differences are only observable from 1K feet view ? Fundamentally, the answer to this question is this: how accurate do you think the routing registries are? Both do a good job preventing fraud at the putative point of origination of the route announcement. This is obviously the most common form of attack. With SBGP, each node signs the BGP statements it's about to send out. The accuracy of the security statement is thus linked to the transmission process. With SO-BGP, the security against in-path attacks (or cut-and-paste attacks; see below) relies on a secure version of the routing registry. If an AS forgets to update its routing registry to reflect new BGP adjacencies, paths containing them will be dropped by SO-BGP listeners. If old adjacencies aren't deleted, routes that shouldn't be accepted will be. In other words, there's a lot less coupling between the transmission process and its security properties. Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true. Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: soBGP deployment
On Sat, 21 May 2005, Steven M. Bellovin wrote: With SBGP, each node signs the BGP statements it's about to send out. The accuracy of the security statement is thus linked to the transmission process. With SO-BGP, the security against in-path attacks (or cut-and-paste attacks; see below) relies on a secure version of the routing registry. If an AS forgets to update its routing registry to reflect new BGP adjacencies, paths containing them will be dropped by SO-BGP listeners. If old adjacencies aren't deleted, routes that shouldn't be accepted will be. In other words, there's a lot less coupling between the transmission process and its security properties. Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true. Yet, what is the (SBGP) alternative? I don't think we have much success distributing this kind of certificates in similar scenario either. At least we _do_ have some (limited) experience and even success in recording the prefixes in routing databases, and adding a signature there would be easy. There's nothing to say the functional equivalent of certificate could also not be passed in an option or some other means as well when needed. My assumption would be that being able to use public databases would be a protocol optimization. Compare this to the situation when BGP filtering is done by automatically generating the prefix lists. How would enhancing that to include a signature (and/or certificate) make matters worse or inefficient? Is there any reason to believe using a different approach would fare any better? Note that the original soBGP didn't require any updates when the peering relationships changed; based on a quick look, a later extension has probably changed this. Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. Note that there's no technical reason AFAICS not to tie the signed origin statements to the origin's AS number, i.e., if someone would want to hijack a prefix, it would need to spoof the AS number as well. Not sure if that helps a lot, of course. But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.). Personally I'd certainly hope so -- because the practical deployment issues with the on-the-path signing model seem prohibitive (too much 3rd party deployment required before the solution would be useful). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: soBGP deployment
On Sat, 2005-05-21 at 16:03 -0400, Steven M. Bellovin wrote: SNIP Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. At least in that case you can quite easily identify the culprit when one find out who it is, as the AS the path is going over is really the culprit announcing it. And as one can identify the culprit one can easily exclude this culprit from ever doing any business with you again, which is also a great thing for protection against spamruns, announcing some prefix for a few moments, spamming and removing it again as they will have to get a new ASN to do it from. ASNBL anyone? :) Of course one can also nicely blacklist the ASN's who allow those hostile ASN's to be connected and so on. IMHO s(o)BGP is a good step forward and I hope that it will get deployed, the sooner the better. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: soBGP deployment
With SBGP, each node signs the BGP statements it's about to send out. The accuracy of the security statement is thus linked to the transmission process. With SO-BGP, the security against in-path attacks (or cut-and-paste attacks; see below) relies on a secure version of the routing registry. If an AS forgets to update its routing registry to reflect new BGP adjacencies, paths containing them will be dropped by SO-BGP listeners. If old adjacencies aren't deleted, routes that shouldn't be accepted will be. In other words, there's a lot less coupling between the transmission process and its security properties. Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true. There is no registry. Each AS distributes set of certificates carrying a list of who they're connected to. You can, as an option, list who you allow to transit, and who you don't allow to transit, and other policies (nothing longer than prefix length x within this address block, etc). But, there's nothing saying you _must_ send any sort of _policy_ out. It's even possible to build the certificates so you can hide peering relationships you don't want to be known about by anyone other than the specific peers involved (by building multiple certificates of specific types, and filtering who you send them to). As for updating the information--each AS originates it's own piece, just like they do routes today. If they keep their routes up to date, there's no reason not to update your peering information in a certificate you're originating. It's not as if you have to make a phone call to the local RR, and have them update their database, etc Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. Huh? :-) Since soBGP doesn't put anything in the existing BGP packets at all, there's nothing to cut and paste from one packet to another (?). You can make up paths, I suppose, but you'd have to make one up that: -- already exists -- has one end anchored at the receiving AS -- has the other end anchored at the originating AS That's a pretty narrow range of made up paths. When you start factoring in aggregation of routing information, you quickly realize there are much larger holes in aggregation than the hole of replacing one path that exists with another path that exists. As for deploying this on a 2500--well, that's never been envisioned. The entire architecture has always been envisioned as running either on _or_ off box, where you could do the crypto part once on an soBGP server, and then let the routers on the edges ask this server about the routes they receive. This is explicitely called out as the most likely deployment possibility in the current architecture draft, and also in evvery presentation we've ever given on it. Of course, you can always do it on box, as well, given the box in question has the resources available. It's also possible, with the current architecture, to spread the certificate processing (the crypto part) across all the edges of an autonomous system. I don't know how well thought that part is, at this point, but we've always intended to allow that sort of thing to be done, as long as we can figure out how to do it and not break anything. :-) :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
Note that the original soBGP didn't require any updates when the peering relationships changed; based on a quick look, a later extension has probably changed this. one of the 29 hacks to sobgp to try to fix this and that (kinda like w's social security program). this one was to address the attested as-path problem, which s-bgp solves so elegantly. *sigh* There were no hacks to solve this problem. The certificates can be issued as the originating AS wants to. If they believe losing all connectivity to a peering AS (all possible peering points) is worth issuing a certificate for, they can. There's no requirement to do, since it depends on local policy (this might be a short outage, and the security risk of leaving the connection in place in the certificates might be very low--it's a situation by situation thing). There is no concept of a peering point within soBGP, just the whether or not two AS' are actually connected. There's no way to tell, from soBGP, how many times, or in how many places, two AS' are connected (unlike S-BGP). IMHO, there aren't going to be many cases where Sprint, for instance, loses every possible peering point with UUNET. I could be wrong, but it seems just beyond this side of improbable, to me. :-) Russ __ [EMAIL PROTECTED] CCIE Grace Alone
Re: soBGP deployment
On Fri, 20 May 2005, Christopher Woodfield wrote: implemented realistically at the single-peer level the paper mentions. Just don't ask me to run it on a GRP-B. I think it'd be running on even your customer's 2500... and your 7500 and your 7200. :) hurray! :)
