- Test - lists.nanog.org

Re: SYN flood messages flooding my mailbox
by Vadim Antonov 23 Sep '96

23 Sep '96

rwoundy(a)VNET.IBM.COM wrote: >where bitmask has a bit per every interfaces, so the bit if set if >packet matching the prefix is allowed from that interface. >How do you handle the case of an inter-exchange point, with multiple >BGP neighbors per interface? The MAE-East NAP is the worst case >(and not everyone at a NAP is a "transit AS"). I don't propose using that at exchange points or anywhere within backbones, for that matter. This is for filering on edges _only_. >What do you do with a prefix announced through two providers, where >the prefix is taken from one provider's supernet? Wouldn't you need >to check the RIB entries of all matching prefixes (including default)? See before. You just don't do that where you have interesting routing. Fortunately, routing on customer tail links (and in IGP-only networks) is not "interesting" in 99.99% of cases. --vadim

1 0

Re: SYN flood messages flooding my mailbox
by rwoundy＠VNET.IBM.COM 23 Sep '96

23 Sep '96

*** Resending note of 09/23/96 18:38 Subject: Re: SYN flood messages flooding my mailbox >Not. Every entry in the filter contains the following data: > [Prefix] [Prefix Length] [Bitmask] >where bitmask has a bit per every interfaces, so the bit if set if >packet matching the prefix is allowed from that interface. How do you handle the case of an inter-exchange point, with multiple BGP neighbors per interface? The MAE-East NAP is the worst case (and not everyone at a NAP is a "transit AS"). If you tried to handle the case of an IXP, wouldn't you have to filter based on both interface and MAC address? >Since in practically all cases all prefixes (NOT routes!) found in >all RIBs are also found in FIB (exceptions are proxy aggregation >and/or restricted end-to-end reacheability) the size of the list >is the same as size of FIB. What do you do with a prefix announced through two providers, where the prefix is taken from one provider's supernet? Wouldn't you need to check the RIB entries of all matching prefixes (including default)? -- Richard Woundy, IBM

2 1

Re: FDDI concentrator w/DC power
by feldman＠MFSDatanet.COM 23 Sep '96

23 Sep '96

> I cannot find a FDDI concentrator that runs on -48 VDC. Is there a > product I've missed? This shortage of DC-powered concentrators might > explain some of the transient outages during power problems at MAE-East, > perhaps? The FDDI concentrators at MAE East (along with all the other AC-powered infrastructure equipment) are powered by a UPS with at least 5 hours of battery power. In addition, all customer equipment co-located at the 1919 Gallows P-1 MAE facility is powered by the UPS. Here's a note from the facilities manager for MAE East on the subject of power: --------------------- MAE East at 1919 Gallows Road P-1 level is configured as follows: - four (4) two hundred amp Lorain rectifiers. - three (3) 1600 amp battery stacks. - one (1) 30 KVA UPS system. - generator umbilical is installed for use with MFS owned 150 KW mobile generator when required. Generator can be on site within one hour and has sufficient fuel to run for 24 hours. All racks installed at MAE East are equipped with a multi outlet power strip with a dedicated 20 amp AC circuit to the UPS system. Therefore all customer electronics and all MFS equipment requiring AC power are provided with filtered AC power via the UPS and have a five hour battery reserve. In addition, all racks have a minimum of 15 amps DC power to a Hendry fuse panel. This panel is served via the DC power plant which provides a minimum of eight hours of battery reserve. The standard MFS offering does not include UPS power in the MAE facilities. At MAE East we have gone one better and provided all customers with UPS. This is a premium service provided at no additional cost. As a final note, we are about to begin construction to upgrade facilities at both 8100 Boone Blvd. and MAE East. This work will include the installation of a permanent 900 KW generator. --------------------- Steve

2 1

Re: New Denial of Service Attack on Panix
by Tim Bass 23 Sep '96

23 Sep '96

Ladies&Gentlemen, IMO, just 'getting the word out' in mailing lists, newsgroups and WWW sites is not an effective way to mitigate the denial-of-service attacks under consideration. Here is why..... When a security hole is found, for example a buffer problem in a networking daemon, 'getting the word out' is effective, because the end user is highly motivated to correct the problem because the problem effects whomever directly (and those who do not fix the problem only effect their sphere of influence, not the entire Internet community). However, in the instance of these DoS attacks, the lower tier ISP is not significantly motivated to take corrective actions because the results have little direct or immediate effects on business ops. Furthermore, if the provider fails to maintain the filter list or even configure the lists in the first place, little or nothing will effect day to day operations (because more pressing matters are in most businesses radar screen, i.e. surviving !) It is for this one reason; the security problem effects users *outside* the providers influence and not inside, merely providing information is a good, but not an effective, way of mitigating the situation, especially in the short term. Continuing with a suggestion..... Overly simplifed, the net is loosely organized along a routing hierarchy with level 0 transit providers at the top. The level 0 providers might agree not to provide services to lower tier providers or customers that do not provide a means of verifying that source route filters are in place (repeat this for lower tiers ...... ) { what is the international organization to do this?, or should there even be one ?) Also, to make matters easier, a WG might be formed, chaired by level 0 provider(s) perhaps, working on both the admin policy and a set of software verification tools to do verification 'magic' on the filters as envisioned by the WG. Furthermore, because the success of this venture is important to, not only providers, but commerce as a whole, ISI, MERIT, or some other org with hooks into the Internetworking Money Flow (IMF :) from NSF or DARPA, etc. might consider putting together a white paper to request additional funding to develop the software tools and manage the releases. Hopefully.... this idea is not falling on 'blind eyes' (as opposed to 'deaf ears' :-) IMO, just 'getting the word out' is not enough to take a significant bite out of this problem. The first step to significantly mitigate DoS attacks has been taken (getting the word out), but, IMO, a greater, second step should be in our radar now. Thanks for your patience, Tim

1 0

Re: looking for real-time CPU utilization graph
by Paul Ferguson 23 Sep '96

23 Sep '96

I didn't see CPU stats among the links, but try: http://www.ra.net/statistics/ - paul At 11:39 AM 9/23/96, Edward Xiao/ACSI wrote: >Hi, All: > >I once saw a internet network CPU real-time utilization graph somewhere, >probably within Merit Homepage. Is anyone know where to find it. > >Ed Xiao >American Communications Services, Inc. > >

1 0

Re: SYN flood messages flooding my mailbox
by Vadim Antonov 23 Sep '96

23 Sep '96

Curtis Villamizar <curtis(a)ans.net> wrote: >> If you relax criteria for reverse-route filtering to "known route" instead >> of "best route" then any customer (non-transit) AS can be filtered safely >> at border routers. >And if the "known route" is know by another router but suppressed from >IBGP advertisement because there is a better route .. But you still have the exterior route in the RIB. So you know it. I'm talking about filtering on borders, not within backbones utilizing the BGP hack. >Or if the "known route" goes through an AS that uses YOU as their best >route but the reverse traffic goes a different way.. So what? The assumption is that multi-homed AS announces all its routes to all exits (maybe with different "metrics"). Is there any practical example of _properly configured_ multihomed non-transit AS which advertises more routes at one exit than another? >Both of these cases and other cause a blackhole. Not at all. >Of course, if by "known route" you mean known because it is in the >IRR, and the IRR is known to be reliable, then I accept your argument >but caution that the IRR is not always reliable, but this is yet >another reason to make it more reliable. IRR. I always held an opinion that the kludge got to die as soon as somebody comes with real way to authenticate routing information. It is silly to build centralized databases for anything. They by definition cannot be reliable. (Note that address allocation does not have to be centralized -- in fact, TWD is the direct result of such centralization). >We've had providers shut down sites because they were slow to address >hacking launched from their site... Do you enjoy playing a cop? I don't. To me, the real solution is to make sure attacks are not feasible in the first place. Or at least make sure that the victim can easily obtain the identity of perpetrator and pursue the legal action on his own. ISPs are not in business of catching criminals. Their business is to deliver bits. >In one case an NSFNET regional shut >down a large university because their CS department just said >"security is a hard problem" and refused to do anything. After 4 days >of no Internet access they had things quite thoroughly cleaned up. The times of the Big Bro^H^H^HNSFNET are long gone. Good riddance, i certainly have no nostalgia. If people want to have no locks on their doors it is certainly completely within their rights, ok? >Shutting down the source is a lot easier if you know the source. I do not want to shut down anyone, if possible. Internet made a very good device to support right of speach. Now the question is how to equip it to provide the right not to listen. The authentication is very instrumental to enforce the right not to listen. At least, then you can explicitly say: "I don't want to listen to anything from such and such". Essentially, source address filtering is the non-cryptographic form of authentication. In reality approach like that works surprisingly well. --vadim

2 1

looking for real-time CPU utilization graph
by Edward Xiao/ACSI 23 Sep '96

23 Sep '96

Hi, All: I once saw a internet network CPU real-time utilization graph somewhere, probably within Merit Homepage. Is anyone know where to find it. Ed Xiao American Communications Services, Inc.

1 0

Re: New Denial of Service Attack on Panix
by Hans-Werner Braun 23 Sep '96

23 Sep '96

I am actually fairly serious. The tremendous amount of email this generated amazes me. With the amount of effort going into that, I suspect may be 40% or more of the problem could already be alleviated if people would just go out and coordinate and do it. Yes, it will not resolve things at the 100th percentile, but what are we optimizing for? A solution for generations to come? Or something that helps, and that can perhaps be augmented by some other means, such as spot measurements (especially for events that last hours). All reminds me actually a little of the movie Star Trek Generations, when Picard an Soran were on this planet, about minutes away from the whole star system being blown to kingdom come, Picard helplessly throwing little rocks at the shield, and Soran asking him something like "don't you have anything better to do."

6 7

Re: New Denial of Service Attack on Panix
by Paul Ferguson 22 Sep '96

22 Sep '96

The coordination aspect is in regards to tracing an attack back to the perpetrator. The source prefix-based filtering only disallows an attacker to use bogus source addresses. - paul At 11:10 AM 9/22/96 GMT, Peter Dawe wrote: >ISP implementing filters for packets with false source addresses. > >Why does there need to be co-ordination? Surely most ISPs would implement >this now they know there is a problem and they can fix it. > >We just need to put out a request to ISPs > >I would suggest this is done directly rather than through 'bodies' such as >IEPG > >Peter Dawe >

1 0

Re: New Denial of Service Attack on Panix
by Vadim Antonov 22 Sep '96

22 Sep '96

I want to make it crystal clear that source address filtering does not fix the SYN flooding or other spoofed-source address security problems. It only makes it easier to track down the perpetrator. If the goal of an attacker is to damage the business for one or two hours such an attack can be launched from a throw-away staging point; after the hacker cleaned up after himself. Tell VISA or any other serious commercial customer that their operations can be stopped for an hour by any newbie who can retype a page from 2600. I think you'll be laughed at. Per-se reducing the number of clueless newbies trying to play hakerz is good and worthwhile; and as such source address filtering is a valuable tool and should be deployed ASAP. However, source address filtering is particularly hard to implement for large ISPs (it'll require quite extensive modifications to configurations). Having only 100 filter lists per cisco box doesn't help too much, too (there are boxes with more than 100 "logical" interfaces on MIP cards). For a large ISP, implementing source filtering is going to be a monumental task. Given the "tragedy of commons" nature of the problem (you work hard to implement filters, which do not benefit _you_) i'm quite sceptical that it will get us anywhere. Note that the significant progress in CIDR was achieved only after years of screaming, threats and all-out hand twisting (can you say Sean's filter?) That's why i tried to communicate the idea of creating such filters automagically, by using the reverse-route approach. That would allow to make it the default behaviour, at least for T-1s or less. Again, source filtering is only a part of solution. It does not eliminate the attack mechanism per se. That's why the statistical traffic monitoring for the traffic patterns showing on-going flooding attacks with consequent automatic shut-off is a valuable deterrent. It reduces the attack detection and prevention time to half-minute or less. For all practical purposes that will make attaks like that rather harmless, and will shift the burden of responsibility from targets of attacks to those who unwittingly or (worse) knowingly provide assistance to hackers by being lazy or simply clueless. The goal is to have the network to be able to contain anti-social behaviour on its own. The technology can do muhc better than an army of cops, so a technological solution should be preferred to any solution involving human (or, worse, lawyer) intervention. The network is great as a right to speak tool. Now we should think hard on how to support right to not listen. Deniability of communicaton is not a new concept, after all. --vadim

6 5