- NANOG - lists.nanog.org

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

Re: The net's reaction to the election day, week, month....
by Sean Donelan 11 Nov '00

11 Nov '00

On Fri, 10 November 2000, Randy Bush wrote: > > > PSI, Verio and Abovenet appear involved in some routing dispute. > > dunno how things appear to you, but i am not aware of any reality of a > dispute to justify what appears to you. I should choose my words more carefully. PSI and Abovenet are in a dispute, and Verio has congested traffic between them because PSI and Abovenet aren't passing the traffic directly.

1 0

The net's reaction to the election day, week, month....
by Sean Donelan 11 Nov '00

11 Nov '00

With a few notable exceptions, the Internet's reaction to this week's events has been boring. At the macro-level, the total Internet traffic barely budged. Wednesday traffic was slightly higher, but you had to squint to see the difference from the previous Wednesday's traffic levels. Even the types and number of network problems didn't change. PSI, Verio and Abovenet appear involved in some routing dispute. A couple of providers had other incidents, but only one seemed to have a major impact on service. Last Thursday, the state of Alaska lost its long distance due to a fiber cut. I don't track or report on malicious activity, but even those sorts of incidents seemed normal with most of the uptick in activity related to the middle east, not the US election. Pretty much business as usual. Some traffic patterns did change. The State of Florida's connection and Secretary of State's web site got walloped hard. Several news web sites continued running in "breaking news" mode for days. CNN, Washington Post, and the MSNBC web sites have started adding features back to their home pages. The Yahoo! News site seemed to be the winner as far as web site performance for the week, as far as the quality of their journalism, I'm not qualified. In general I didn't see much spill over to other web sites that may have been hosted by the same provider, but were not breaking news sites. So it appears most providers had sufficient head room on their networks.

2 1

10.x.x.x networks
by Michael Long 11 Nov '00

11 Nov '00

I've been having a friendly arguement with some friends at work about wheather it's right or wrong to use 10.255.255.0/24 for a network. Technically it should work, but during our conversations we keep coming back to best practiced IP schemes. I'm wondering what others think about this. Is using 10.255.255.0/24 and possibly the reverse 10.0.0.0/24 bad practice? Mike

3 2

SLA monitoring software package
by Yu Ning 10 Nov '00

10 Nov '00

Hi All, As we know SLA is frequently referred by some major NSPs, I wonder if there is any vendor specific, or third party software package that can help an NSP to monitor its backbone network and to see if its network conform their SLA agreement with customers? If there is any well-known SLA monitoring software ? How about IPM (Internet Performance Monitor) by Cisco? Anyone has any comment on using IPM ? thanks any input! best -------------------------------------- (Mr.) Yu Ning, Chief Eng. Internet Network Product Dep. Data Com. Bureau, China Telecom Beijing, P.R.C. +86-10-62072357/54 --------------------------------------

3 3

RE: SLA monitoring software package
by lance_tatman＠agilent.com 10 Nov '00

10 Nov '00

Have a look at Firehunter. www.firehunter.com It can monitor SLAs and has some nice looking reports. -Lance- > -----Original Message----- > From: Yu Ning [mailto:yuning@ns.chinanet.cn.net] > Sent: Thursday, November 09, 2000 12:58 AM > To: nanog-post > Subject: SLA monitoring software package > > > Hi All, > > As we know SLA is frequently referred by some major NSPs, I > wonder if there is any > vendor specific, or third party software package that can > help an NSP to monitor its > backbone network and to see if its network conform their SLA > agreement with customers? > > If there is any well-known SLA monitoring software ? How > about IPM (Internet Performance > Monitor) by Cisco? Anyone has any comment on using IPM ? > > thanks any input! > > best > > -------------------------------------- > (Mr.) Yu Ning, Chief Eng. > Internet Network Product Dep. > Data Com. Bureau, China Telecom > Beijing, P.R.C. +86-10-62072357/54 > -------------------------------------- >

2 1

Election 2000 - Network performance status quo
by Sean Donelan 09 Nov '00

09 Nov '00

Large scale measurements of the Internet showed no measurable difference in overall packet loss or reachability during the 2000 US national elections. Aggregate traffic measurements at NAPs and some providers' MRTG graphs didn't show much difference from last Tuesday's. Unscientific measurements of specific web sites (i.e. news and political sites) did show increased latency and timeouts, which tends to indicate the bottleneck was at the web site. CNN and MSNBC went to a stripped down front page; which helped their performance. ABCnews and CBSnews appeared to keep their full frontpage, and were very sluggish. Yahoo News, with the most stripped down, almost all text news page, was speedy all night long. Although some people throwup their hands, and say you can't control the Internet; it does seem like many of the issues are at the point under the control of the individual organization. Smaller websites such as political candidate sites did have problems loading, but they are probably going away tomorrow anyway.

2 1

RE: GLBX Outtage
by Karyn Ulriksen 09 Nov '00

09 Nov '00

Glad to see that I'm not the only one in this boat... sort of. Thanx for the info. K > -----Original Message----- > From: John Gonzalez/netMDC admin [mailto:ekool@ns1.netmdc.com] > Sent: Thursday, November 09, 2000 10:14 AM > To: Karyn Ulriksen > Cc: 'nanog(a)merit.edu' > Subject: Re: GLBX Outtage > > > > I'm in the southwest region.. i noticed that our BGP session > with them was > only taking some 750 odd routes or so. I reset the session and it came > back with only one route. I've since turned down the circuit, but our > "GC" assigned space no longer functions to any "GC" hosted > site. Needless > to say, it is effecting some of our customers. > > I have had a ticket open, no ETA. > > On Thu, 9 Nov 2000, Karyn Ulriksen wrote: > > | Does anybody have any additional info on FroGlo's net > outtage this morning. > | Their first level customer service reps don't seem to know > which is the hole > | in the ground (which is somewhat expected), but I'm having > a terrible time > | getting to their techs. > | > | The customer service line simply states that they are aware > of the outtage > | in the southern part of the US and have no ETA on repair. > As far as I can > | tell, it started at about 4am. > | > | Thanx in advance for any add'l info you might have. > > -- > _ __ _____ __ _________ > ______________ /_______ ___ ____ /______ John Gonzalez/Net.Tech > __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! > _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)439-0200/fax-437-3052 > /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com > [---------------------------------------------[system > info]-----------] > 11:10am up 63 days, 17:39, 3 users, load average: 0.36, 0.21, 0.18 >

1 0