- Test - lists.nanog.org

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

24 Sep '96

Curtis Villamizar <curtis(a)ans.net> wrote: >I guess you missed what I proposed earlier. It was similar though the >Fib was used so it only worked for single homed connections. The >advantage was simplicity. All that needed to be changed was the >forwarding code. Your proposal involves the AdjRibIn which would >require BGP code changing flags on the forwarding entries. A bit more >work for the router developers but covers more cases. We both >proposed turning this on by default with cluefull people who knew >routing would be assymetric turning it off. Good. We finally agreed on something :) Did i hear that you volunteered to write an I-D amending requirements for gateways? :) --vadim

1 0

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

24 Sep '96

>Basing this on the AdjRibIn is a more work than just reversing the >sense of the Fib but it does cover quite a few more cases. Though not >all of them. No, not of course; but more than enough to be practical. A _lot_ more practical than manually (or semi-automatically) maintained access lists which do not provide any "visible" benefit. >The transit providers still need to be able to trace attacks after the >fact since there is no filter that covers these cases... Absolutely. When other things do not help :) >and filters at >the fringes will be spotty deplomyments. That's why i want reverse-route verification to be _default_ behaviour of routers. A person who knows how to use asymmetric routing would know how to turn the feature off. A person who is clueless or simply doesn't care will leave default as is. --vadim

2 1

More press on attacks
by Paul Ferguson 24 Sep '96

24 Sep '96

Pointer: http://www.news.com/News/Item/0,4,3710,00.html Complete with cute little Java applet of attack. ;-) - paul

2 1

Crypto callback (was: New Denial of Service Attack on Panix)
by Leonid Egoshin 24 Sep '96

24 Sep '96

Hi, I can propose yet another decision of SYNs flood attack on the site under attack. Unfortunatly I had no time to verify it in real live, but it is seemed as correct. Also it is not elegant decision, but ... 1). It is need to measure the available TCP control blocks resource and switch on to this strategy then host is under attack (for exam then number of free TCP blocks is less 1/3 of all TCP blocks). And switch back after it is seens that attack ended. The strategy consist of 2). Then host receive SYN, it calculate cryptographic initial TCP sequence depended from IP address [+ probably port] of another TCP side, answer by SYN-ACK with it and forget it. 3). Then host receive ACK which havn't IPs and ports of any already established or closing TCP session, then host verify answer-sequence in it and if it is correct - create TCP block and set it to established state and run as normal. Cryprographic calculation and verification. 4) Take the negative current time in the 4ms units (see RFC793) and add to it some cryptographic constant which is calculated from other part IP [+port] on the base of secret site key. 5) During checking subtract this cryptographic constant and verify time - it must be in range of 2 max segment live time from current time. ( More accurate strategy would be to increment "time" with any established TCP session, record the real time of each such increment and remove old values which is older than 2MSL.) 6) What it is need to do with MSS option ? - take the default (I said that it is non-elegant decision !) Advantages: - Callback allow the only non-falsified host connection. - Cryptographic sum on the base of IP [+port] deny SYNs flood also as another spoofing - the other part must answer with this callback key. (It is already used in many UNIX systems). The probability of success SYN flood attack is 1 for 80000 SYN packets. The same is for ordinary ACKs flood attack. Disadvantages/problems: - What would be after unexpected (!) reboot of server ? It is looks like one of 80000 nonclosed connection which haven't keepalive option and stay passive during reboot and long time before reboot can be accepted as new without notification of client. But if we take in account more accurate strategy of "time" calculation the probability of it can be significantly lower. - Some perfomance degradation due to MSS loss from initial SYN. But some system send MSS during first ACK also and eliminate this problem for it. - It is need to have source code of server system and some programming efforts to implement it :-) - Leonid Yegoshin, LY22

3 2

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

24 Sep '96

Curtis Villamizar <curtis(a)ans.net> wrote: >I guess a picture would help: > > AS X R1 ------ AS Y R3 > | | > | | > AS X R2 ------ AS Y R4 > >If the route learned at AS Y R4 is preferred, AS Y R3 may get packets >although the forwarding entry (Fib) points toward AS Y R4, the LocRib >does not contain the entry (no preferred), only the AdjRibIn contains >the entry. If the filter must be set according to AdjRibIn, That's what i meant. >you now have a filter list **in the forwarding path** considerably longer than >the current routing table. Won't scale at the very least. 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. 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. In fact, you don't even need to keep a separate table. Just add a bitmask field to the FIB entries. (On customer-access routers with many interfaces each allowing only very small portion of routes in it may be more economical to implement explicit per-interface lists than to add fields to FIB). > >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"). >In this case: AS a R1 ------ AS b R2 ------ AS d R4 | | | | | | +----------- AS c R3 -----------+ >In this case AS c prefers AS a. AS d prefers AS c. AS b prefers the >routes it hears from AS b. AS a prefers some route through AS d that >it hears from AS b over the route it hears from AS c. Therefore AS d >has no Fib, LocRib, or even AdjRibIn from AS b R2, but will get >legitimate traffic from R2 that is dstined for places that is >reachable through AS d but for which AS d uses AS c for the return path. ASes a and d are transit. I clearly stated that the reverse-route filtering technique is inapplicable for transit AS-es. Fortunately, the number of transit ASes is very small (two years ago i measured it as 170-something), and they generally form a backbone. On the other hand, practically all customer AS-es or intra-AS tail links are not transit. >The first case is clearly less scalable than the current routing table >(consider putting all AdjRibIn entries at a NAP into your filters on >the forwarding card). Er. That statement is just plain wrong. >The second just plain doesn't work. It is exactly within the restriction i stated beforehand. You don't want to do packet filtering on backbone in any case. --vadim

2 1

Re: Bob Metcalfe: Infoworld Sept 23 page 46 Which young brat?
by Avi Freedman 24 Sep '96

24 Sep '96

> On Mon, 23 Sep 1996, Christopher Sevcik wrote: > > > In his excellent article in the Info world which I received today, he > > referred to a young ISP brat. > > > > Who's he referring to? He appears to be talking about me. I sent him e-mail explaining that I was mis-quoted. What I *said* was "Some say that Metcalfe ...". What was printed was something like "Freedman says that Metcalfe ...". Though, given the gigacollapse predictions which he made - combined with the fact that it's extraordinarily difficult to believe that he actually *believed* them - the quote might have started "Metcalfe has become a journalist, more interested in gaining readership than in using his formidable experience to help with the operational and architectural problems that the Internet community is facing..." if I had been asked for a quote about Metcalfe. Which I wasn't... > Didn't the print version give the URL of thie document containing this: > > Avi sums it up: "Metcalfe has become an elder statesman and > > ... to read the rest go to > http://www.forbes.com/asap/gilder/telecosm18.html > > Michael Dillon - ISP & Internet Consulting Anyway: wow, I can't believe it. I might have surpassed Sean Doran as the official Brat-boy of the ISP/ NSP community. Maybe I'll get Sean to pen my letter to the editor in reply to his brat comments... Avi

1 0

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

24 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 24 Sep '96

24 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 24 Sep '96

24 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