November 2000 - Test - lists.nanog.org

RE: ISP recommedation in Washington DC area
by Jason Jin 13 Nov '00

13 Nov '00

Hello, we are currently using UUNET as our ISP. We're looking for a separate T1 for redundency. can somebody suggest some ISP's in Washington D.C area, what's the issue I should looking to before selecting one ISP over another. Any suggestion or pointer to relevent resources will be much appreciated. TIA, . Jason

2 1

Re: MCI WORLDCOM TO PAY $3.5 MILLION
by Sean Donelan 13 Nov '00

13 Nov '00

There are several, off the top of my head Bay Area DDoS Working Group BORG Commercial Internet Exchange Internet Engineering Task Force IOPS IPEG ISP/Consortium Information Technology Association of America North American Network Operators Group Cross-Industry Working Team (XIWT) Being a member of a consortium is different from contributing to or following any recommendation of a consortium. I don't think yet another consortium is the answer. I believe this has fundamentally become a management issue (and their legal advisors). Unless and until the various provider's senior management believe this will substantially affect their business, nothing will happen. For the last five years, I've been in favor of a technical solution. I've changed my position, and believe the Sprint engineers were correct. It is not a technical problem, and the engineers can't fix it. There are three basic methods to make it in their business interest 1) Public pressure 2) Government pressure 3) Legal pressure If Sprint faced a $1 million fine everytime they blackholed someone else's routes, perhaps they would fix their processes. On Mon, 13 November 2000, J Bacher wrote: > On Sun, 12 Nov 2000, Mark Mentovai wrote: > > Is there a consortium of big-time Internet operators? There should be - > Preferably not to the exclusion of all others.

1 0

Re: MCI WORLDCOM TO PAY $3.5 MILLION
by Sean Donelan 12 Nov '00

12 Nov '00

On Sun, 12 November 2000, "Mark Mentovai" wrote: > But these problems were corrected, no? The point I'm trying to make is that > these operators don't make any additional profits by doing the wrong thing > and then fixing it (as they did, unless someone can point to instances in > which brokenness wasn't fixed after it was brought to their attention) than > by doing the right thing from the start (verifying announcements, etc.) > The way I see it, aside from the extra time and "hassle" involved in doing > it right, doing it wrong and doing it right are the same in the bookkeeper's > eyes. After blackholing one of my customer routes for 72 hours, Sprint finally fixed it. The customer believing it was my problem, and the Sprint sales person who mysteriously showed up on the customer's doorsteep following the incident selling how much more reliable buying directly from Sprint would be, decided it would be in their interest to buy from a bigger network such as Sprint. So, yes, they do make more money by disrupting the operations of small ISPs. Do they do it on purpose? I don't believe they are organized enough to do it on purpose. Is it in their interest to fix it? No.

2 1

Re: MCI WORLDCOM TO PAY $3.5 MILLION
by Sean Donelan 12 Nov '00

12 Nov '00

On Sun, 12 November 2000, "Mark Mentovai" wrote: > The drive to "slam" is pushed by dollars. I can't think of any situation in > which someone might profit from announcing address space without > authorization. The problems facing the Internet are mostly due to laziness > and lack of clue, enabled by an experimental infrastructure designed to > support neither of these things. IP assumes non-hostile, non-lazy, and > non-clueless nodes. Sure it is. When I asked why did providers announced addresses improperly, I've been told by both Sprint and UUNET engineers "because they paid us and you don't."

2 1

Re: MCI WORLDCOM TO PAY $3.5 MILLION
by Sean Donelan 12 Nov '00

12 Nov '00

On Sun, 12 November 2000, "Mark Mentovai" wrote: > Failing that - a push from within the community to clean things up - I fear > that governmental intervention is the only solution. I only hope that when > it comes down to regulating the Internet, it will be handled by a new > authority responsible only for inter-network communications. I think that > it would be a mistake to try to tack this responsibility onto the FCC or > FBI. They're not international enough to handle issues fairly, for > starters. I also haven't been impressed with any government agency's > technological prowess. How many folks remember when the FCC's ip address block was blackholed by an customer of Sprint and UUNET for an entire weekend? Even FCC staffer's couldn't get into their own network for 48 hours. I still wonder if the FCC was ever told by Sprint and UUNET the reason why their network was down for the weekend was due to a routing error in their networks, or if they just wrote it off as one of those weird Internet things.

1 0

Re: Defeating DoS Attacks Through Accountability
by Sean Donelan 12 Nov '00

12 Nov '00

On Sun, 12 November 2000, Daniel Senie wrote: > I'm not sure you're being clear. If someone has portable /24 or /16, and > does NOT do their own BGP, but contracts with ONE ISP to do that > advertisement. How do other ISPs know that ISP has permission? We could > point to the RADB, but it's chock full of bogus data. We could point to > ARIN, but their database just says the owner of the net in question is > whomever it is. Those who own that space have a legitimate right to use > that space, so telling them to get ISP-provided space is a non-starter. > > I agree it's a problem in need of a proper solution. The solution has to > account for portable address space not owned by providers. There are several steps involved. I am talking about the very first step. If someone has portable /24 or /16 space, there is a coordinator of record listed in ARIN's, RIPE's or APNIC's database. The first ISP to inject the address into BGP must have proper authorization from the coordinator of record. If we start out with garbage, the rest is irrelevant. We need to get the starting point fixed. The argument "they are paying us, so we do whatever they tell us" is bogus. After we have a good starting point, what do we do about the transitive validation, i.e. how do you know the entire AS path is valid? It should come as no surprise, I think ARIN is messed up. In addition to the coordinator of record and list of in-addr.arpa name servers, I think it should include a routing delegation. Either listing the ASN's directly with the delegation, such as RIPE, or providing a pointer to a third-party routing database of record for the IP address block. But the transitive steps are garbage if the starting point is garbage. As we've seen with the RADB, when anyone can put junk into the database, it gets full of junk. Sean Doran's 0/0 routes are the perfect example. If a complete answer is "hard," can we at least work on getting the first step correct?

1 0

Re: Defeating DoS Attacks Through Accountability
by Mauro Lollo 12 Nov '00

12 Nov '00

If possible, ARIN, or another "authority" should retain more information about the profile of address space, including delegations. As you noted, announcing first and fixing later is like a hit and run, then returning a while later to scrape up the fellow off the road. We just repatriated a portable /24 from a rouge who was using it, supposedly telling his upstream that we had "given them permission"......NOT. I suppose the question is, could a governing body (outside of government), ever keep reasonable control over things without the complete obedience of providers? M. >From: Mark Prior <mrp(a)connect.com.au> >To: Sean Donelan <sean(a)donelan.com> >CC: nanog(a)merit.edu >Subject: Re: Defeating DoS Attacks Through Accountability >Date: Sun, 12 Nov 2000 16:53:27 +1030 > > > But the current practice of announcing first, and only after you kill >some > innocent bystander's network, then fixing it; needs to stop. > > Every IP address should be traceable to an original recorded >delegation. > If the "paperwork" isn't complete or is inaccurate, we should work on >fixing > it. Sticking our heads in the sand, and announcing the network until > someone complains is not good. > >How would you propose to handle the case where an organisation has >their own IP space which isn't currently advertised and then you >receive a request from a third party to route it to them? > >Mark. > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

2 1

Re: Defeating DoS Attacks Through Accountability
by Sean Donelan 12 Nov '00

12 Nov '00

On Sat, 11 November 2000, Mark Prior wrote: > How would you propose to handle the case where an organisation has > their own IP space which isn't currently advertised and then you > receive a request from a third party to route it to them? First I would suggest they register their claim to use the IP address with the appropriate registration agencies. As I understand it, every register has a method for recording further delegations. It is providers who choose to create the problem by not recording the delegation. If for some reason they can't change the organization of record for the IP address, there is a concept called a "Letter of Agency" which is used when someone wants to authorize a third-party to take actions on their behalf. If the third-party does not have a LOA from the coordinator of record for the IP address, I wouldn't view it as a valid request. If they can't change the coordinator of record, nor can they get the coordinator of record to give them a LOA; you should have known there is not clear authorization for the third-party to use the IP address. How would you propose to handle the case where a person has a credit card number, and then you receive a request from a third party with no evidence of any authorization from the registered card owner to charge stuff on that card number?

5 4

Re: Defeating DoS Attacks Through Accountability
by Sean Donelan 12 Nov '00

12 Nov '00

On Sat, 11 November 2000, Mark Prior wrote: > As there is no real way to determine who is authorized to announce a > prefix we must rely on some measure of "reasonableness", ie does it > look likely that a customer should announce that prefix, and in the > case of BGP announced routes we would look in the routing table to see > if the route is already being announced. Just like credit card numbers, telephone numbers and so forth; every valid IP address used on the Internet does have a delegation of authority. Do we need IP escrow and title insurance companies whose business includes verifying the lineage of an IP address assignment. If you can't show you have clear authority to use an IP address, should you have liability for any and all damages caused by your improper announcement of that address? Perhaps after a few major providers faced huge lawsuits and liability they would clean things up. Would you build a store on property you weren't sure if you had clear title, but it looked empty so you moved in. Its an analogy, so it doesn't match exactly. So everyone doesn't know the exact method of verifying a credit card number or verifying a telephone number or verifying an ip address. If you don't know how to do it, perhaps you should hire a third-party to do it for you. If you can't properly delegate the IN-ADDR.ARPA reverse mapping, more than likely you shouldn't be announcing the IP address. If you can't properly register your contact information for the address, perhaps you shouldn't be announcing the IP address. Perhaps a lot of things. I know people haven't been very carefully in dotting all the i's and crossing all the t's in the past; so some of the records aren't in the best shape. But the current practice of announcing first, and only after you kill some innocent bystander's network, then fixing it; needs to stop. Every IP address should be traceable to an original recorded delegation. If the "paperwork" isn't complete or is inaccurate, we should work on fixing it. Sticking our heads in the sand, and announcing the network until someone complains is not good. I've seen too many networks knocked complete of the net for days. I thought after major networks like Sprint and AT&T had their services disrupted for hours something would get fixed. How can you run something, which some people have called vital to our national security, were virtually anyone half-a-world away can black-hole your routes. But after a couple of weeks everyone forgot why those networks went off-line. Yeah, I know they didn't have an "outage" you just couldn't use their networks for the day because of the problem. AT&T did publicly say what happened to their network, I've never seen a public statement from Sprint. Its easy to blame backhoes for Internet problems, because it is a third-party. But these routing errors are created by us. Yes we have met the enemy, and its us.

3 2

Defeating DoS Attacks Through Accountability
by Mark Mentovai 12 Nov '00

12 Nov '00

I'm very pleased to see how much enthusiasm there is for cooperating. Since we have identified the problem, and the reasonable technical solution (filtering) is apparent, we should now focus on discussing complications and a strategy for widespread implementation. For the purposes of this discussion, I'd like to remain as focused as possible: while I'd love to spread the clue about things such as turning off directed broadcasts, I feel that bringing accountability to IP is by far the most important issue. If we had accountability, all of the other DoS-related problems would be so much easier to respond to. The very first step, if you haven't done so already, is to push your own organization to implement ingress and egress filtering. This is NANOG, and there are enough clueful NANOs reading with the resources needed to accomplish this on a number of small- and medium-sized networks in the short term. With RFC 2827 in hand, use egress filters to make sure that your networks don't permit packets with spoofed source addresses from entering the Internet. If you have customers, as many (most? all?) of us do, use ingress filters to make sure that spoofed packets don't even enter your network. The key to solving this problem, though, is to push the large-sized networks - the Tier 1s and 2s of the world - into aggressively implementing ingress filtering on customer links. Most of these providers already have the necessary information to do so: BGP announcements from a customer are already restricted to customer address blocks, and known static routes are used for singly-homed customers not running BGP. If ingress filtering were to be implemented to the same degree that route advertisement filtering has been, this problem would be, for the most part, solved. The beauty of this is that filtering packets to eliminate spoofed source addresses comes down to the same exact restrictions as filtering routing advertisements. If a provider is able to filter BGP announcements for the greater good of the Internet, then that same provider is also able to filter packets by source address for the same reason. Not only do we get to use the same list of blocks for filtering, but we get to justify filtering with the same arguments that are already being used for other forms of filtering. This is not, as one poster suggested, ones and zeros without discretion. This is true within the network core, but at the customer edge, there are definite policy restrictions that are in force today, and that can be put in to force tomorrow. For the record, I haven't seen any evidence indicating that filtering at the edges would impact performance. All of the NSPs do have employees with enough technical know-how to get this done, and to get it done properly. Assuming that widespread ingress filtering could be implemented by these people at the NSP level, it wouldn't matter that the networks without clueful NANOG-reading operators (or without operators at all, for that matter) never bothered modifying a single router configuration. If an uncared-for network lacks ingress filtering but is connected to an NSP that filters all inbound customer traffic, individuals on the uncared-for network would only be able to spoof using addresses that are supposed to be on that network. If such a DoS attack were to be launched, then the source network would be known, even if the source party's identity would still be a mystery. This is of little consequence, though, because the pool of suspect source networks has been reduced from hundreds of thousands to one, and that's enough for law enforcement to launch a successful investigation. If the Internet were built around one central NSP, we'd be able to stop here, but since that's not the case, there are additional complications to deal with. Specifically, ingress filtering at the customer edges of a network implies that the network core is safe. As we all know, though, the network core is not safe, because it's not controlled by any single organization. It is impossible to implement filtering at peering points between NSPs, for example. The only solution is to get all of the NSPs to agree to implement filtering. If even one big-time operator refuses, then we cannot be sufficiently assured of accountability. One way I see to handle this issue requires a decree from one or two of the big NSPs requiring that all unfilterable connections (peering links and any other link so large as to make filtering infeasible or impossible) aggressively implement ingress filtering. (Come on, you big NSP types, I know you're reading, what do you think?) Customer links with more than a certain chunk of associated address space should also be held to the same standard of filtering. The only effective way of enforcing such a policy would be to unplug noncompliant networks. For those of you out there who followed me right up to this point, yes, I am suggesting forcing networks to behave. Others have pointed out, and I agree, there are too many networks which will not comply unless there's no alternative. This is a topic which can be expanded on; the enforcement issue especially is more related to policy. I also foresee complications due to the global nature of the Internet. Hopefully, these same principles could be extended beyond North America into other regions of the world. Thoughts? Mark

10 15