September 1996 - Test - lists.nanog.org

Re: syn attack and source routing
by Vadim Antonov 08 Oct '96

08 Oct '96

Alexis Rosen <alexis(a)panix.com> wrote: > > Or better yet, the ICMP TRACEROUTE message, which would go > > hop by hop and on every hop generates a response message. > > Augmented with PROXY TRACEROUTE which will cause the destination > > box to send out the ICMP TRACEROUTE. >I'm very surprised that noone has mentioned what seems to me to be the >*really* serious drawback to this scheme. Remember how much grief you had >the last time someone did a news sendsys forged to your name? (If it's >never happened to you, be glad...) This sort of attack got so bad that >the default setup these days is to ignore sendsys. Yes, indeed a single traceroute packet with forged address can generate many responses. However, there is at least one technique to eliminate its usefulness as an attack weapon -- namely source address filtering (which is going to be implemented anyway, sooner or later; there are other types of attacks). Another way is to have ICMP TRACEROUTE to return one packet with all information _and_ the IP address of the next hop router (i.e. replace recursive behaviour with iterative) . It is still more useful than UDP kludge; and it will still work in case of load-sharing. Actually, the "multiplication" type of flooding attacks is nothing new, but they are more easily done on application level. For example, connecting to different SNMP speakers and causing them to send a long error reply to the target address. Or subscribing victim to many many mailing lists (including USENET gateways, urgh!). Or using MBONE feeds creatively. --vadim

2 1

Re: New Denial of Service Attack on Panix
by Kent W. England 05 Oct '96

05 Oct '96

At 09:09 AM 9/18/96 -0400, Guy T Almes wrote: >Kent, > I liked the rest of your message more than the first sentence. > >>> >>I wish that it were not so, but after reading the clever and insightful >>approaches to tracking down the denial-of-service perps, I am pessimistic >>about our ability to stay ahead in the escalation of this counter-counter- >>measure warfare. I think that if we were able to trace the Panix attacker >>that a future attacker would hit simultaneously from a half-dozen free >>dial-up connections with a real random number generator and synthetic >>SYNs to fool the router stat collector (or whatever it takes). I think we >>are on the short end of the technology stick here. >> I want to amend my statement a bit. While it sounds like I completely ignored Curtis' summary message from Monday, in fact, I never received any of those nanog messages and if I had, I doubt that I would have posted my original message. I faithfully read all my nanog mail and I don't understand the gaps in my receipts. It seems to me after reading Curtis' summary that servers can be modified to make the SYN flooding attacks much more difficult to accomplish. Perhaps enough so that source address filtering doesn't have the urgency of implementation and coordination that I thought before reading Curtis' note. --Kent

15 47

Re: Peering versus Transit
by Barney Wolff 04 Oct '96

04 Oct '96

> Date: Mon, 30 Sep 1996 09:01:14 +0100 > From: "Alex.Bligh" <amb(a)xara.net> > > > And of course, to be in a position to "dump data" on a router at an > > exchange, one must have one's own router there peering with *somebody*, > > right? > > You needn't peer with anyone > > ip route 0.0.0.0 0.0.0.0 w.x.y.z > > will do the trick nicely if you aren't carrying full routing. Er, why did the exchange operator let you put a router on their switching fabric if you're not peering there with somebody? Are there actual cases of people with routers at NAPs/MAEs/xIXs who don't peer with anyone? Barney Wolff <barney(a)databus.com>

6 8

Peering versus Transit
by William Allen Simpson 02 Oct '96

02 Oct '96

It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined. I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic! But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world. I firmly believe that this is where the current model has gone awry. Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit? Instead of negotiating with other providers for inter-exchange transit, I advocate that each attachment to an exchange negotiate with the exchange _operator_ for transit to other exchanges, and the exchange negotiate with inter-exchange providers for the aggregate. Separating the peering from transit provides greater clarity in agreements, with opportunity for better quality monitoring and control, while promoting greater redundancy in the Internet mesh, and greater competition in the inter-exchange transit market. ---- Until this happens, in the case in point, I would recommend that Wonderland (an org, not a net?) has no _transit_ peering to offer Sprint "in kind", as Sprint likely already has enough transit agreements to reach those same exchanges. Wonderland might have better spent its $5M+ per annum obtaining service from an existing trans-atlantic provider, or cooperating with another provider to join multiple links under existing transit agreements with Sprint and others, thereby reducing the trans-atlantic congestion. > From: Peter Galbavy <peter(a)wonderland.org> > > Besides, most of the major providers previously based the bulk of > > their peering 'requirements' on how many DS3s you had. Now most > > 'major' providers seem to have gone cold turkey. MCI, Sprint, and > > UUNET told me they won't peer with *anyone* new. > > But seriously, lets face it, DS3's are "cheap" and these people > want more customes no freeloaders. Like us, who are paying $5M+ a > year for a trans-atlantic DS3 and Sprint are very insistant that > we build a US network based on DS3s to peer with them, even with > the obvious fact that we have no US customers and have already paid > for a connection which in reality should be matched by the large > US carriers, rather than taking the piss once you have this > investment. I only mention Sprint, since the others you mention > are a tad more sensible, but still slow, while Sprint are in a > glacier. > WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

15 29

Re: Advice on dealing with Sprint
by Darrel Lewis/TEIR/Thomson 01 Oct '96

01 Oct '96

Wait a sec, I was under the impression that multihoming with sprint was only a problem if you used PA addresses from Sprint. If you have PI addressing, or your addressing is from (for example) MCI, you shouldn't see a problem. Was I missing something? -D Darrel Lewis Network Engineer Thomson Electronic Information Resources dlewis(a)teir.com wsimpson @ greendragon.com ("William Allen Simpson") 09/30/96 04:57 PM To: jon @ worf.netins.net (Jon Green) @ Internet cc: nanog @ merit.edu @ Internet Subject: Re: Advice on dealing with Sprint Coming back to an old topic from whence we diverged, my advice would be _not_ to connect or multihome with Sprint unless they accept you as a peer and share the cost. Earlier, we have learned that Sprint doesn't multihome properly, as it deliberately ignores paths to its own "customers" seen from other ISPs even when its own lines are down. You learned that they have restrictive policies on routers. And more recently, we learned that Sprint has extremely restrictive policies on peering (exchanging routes). There really isn't much point to multihome with Sprint except to load share directly to Sprint's customers. You don't get any of the other benefits of redundancy. Why bother paying for the link and Sprint for the privilege? I can tell you, since my upstream provider switched a few weeks ago from multihome with Sprint and MCI, to nap.net and MCI, we've had _much_ better service! When nap.net has had problems, multihoming has actually worked correctly.... And multihoming with MCI and AlterNet seems to work well together, too. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Best way to deal with bad advertisements?
by Matthew Petach 01 Oct '96

01 Oct '96

Hi! I'm going to ask the rest of the NANOG community for their thoughts/opinions on a problem that's been plaguing us periodically that we haven't been able to find a satisfactory solution for yet. There's an ISP back on the East Coast that has been periodically advertising more specific routes for /24's out of our CIDR blocks and black-holing the traffic within their network. We've called all the listed numbers for their technical, admin, billing, and any other contacts we can find, and haven't been able to reach a human; we've left messages of various levels of nastyness, from very sugary on up to vaguely threatening. In every case, including the current one, it's been more than 24 hours, and they still haven't made any response to the problem; in fact, I just got paged by our NOC early this morning informing me they've stolen another one of our /24's. As you can well imagine, all the customers on those blocks are _very_ unhappy. Each time this happens, we end up with dissatisfied customers, many of whom leave, deciding that we're too unstable, and can't provide quality network connectivity, even though to the best of my knowledge, there's nothing we can do to prevent these people from stealing our blocks. My question to the NANOG community is twofold and simple: Am I overlooking some solution that would allow us to 'negate' their advertisement of our blocks (205.159.193.0/24 and 207.88.102.0/24 in this case) and secondly, is there a formal process within the community to seek recompense, or formal action against a clueless and net-unfriendly ISP, perhaps one as simple as the net equivalent of Mennonite 'shunning'? Or are we simply out of luck, and have to simply tell our customers "Sorry, everyone is at the mercy of the morons who can steal IP blocks simply by advertising more specific routes with higher weights?" It's getting really tempting to advertise the networks they have their nameservers on from *our* network with a weight of 65535, just to get them to call us back. :-( :-( Anyhow, enough frustrated venting, I *am* very interested in what the community feels is the best policy to follow in situations like this. Thanks again! Matt Petach Network Engineer (writing from home)

7 17

Re: Peering versus Transit
by Vadim Antonov 01 Oct '96

01 Oct '96

Bill Woodcock <woody(a)zocalo.net> wrote: > WRT the former, I simply cannot fathom, and no one other than Sean has > yet presented an argument explaining why it's malicious to deliver a > packet to its addressee's ISP. You should always add "without consent of the said ISP". It is no different from dumping a pile of bricks at somebody's property. Are bricks useful? You bet. Will it get you dragged in court on charges trespassing and defacing the property? Sure as hell. It is not a "theft", it is more like trespassing. It is illegal and covered by codes related to unauthorized use of equipment. > Why should I, as an ISP, not prefer > that all other ISPs deliver packets to my customers as quickly, > efficiently, directly, and inexpensively as possible? Efficiently, directly and inexpesively from whose point of view? Refer to the example of ISP in Mukhosransk. > Why should I > prefer a more expensive or less reliable route, or expect any other > ISP to do so? There is a million reasons to do that -- economical, legal, technical. One technical reason is pretty obvious -- it is called "traffic engineering". Large ISPs often use nudged routing advertisements as means to balance load between peering points. That assumes that nobody is sending unsolicited traffic. --vadim

2 1

Re: Peering versus Transit
by Bill Woodcock 30 Sep '96

30 Sep '96

Matt Zimmerman <mdz(a)netrail.net> writes: > because you're using THEIR resources to do so, without > explicit permission from them. That's a repetition of the same position that's been stated over and over, without justification. If A sends to B directly in the absence of an advertised route, A is "stealing" resources from B. If B sends to A indirectly through A's transit provider, then B is "stealing" resources from A. What makes the former case worse in your mind than the latter, when it results in higher reliability, lower cost, and a sounder architecture? Reiterating the same position over and over without any basis or logical foundation does nothing to convince anyone that your position is of any merit. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

3 2

Re: Peering versus Transit
by Vadim Antonov 30 Sep '96

30 Sep '96

> You should always add "without consent of the said ISP". > > It is no different from dumping a pile of bricks at somebody's property. >Why is it any different than the big ISP's customers dumping >packets on small ISP's web server? The Web page owners pay for that, ok? If they do not want other people accessing their data they wouldn't put it there for open and pay for it, too. If the small ISP does not want customers of other ISPs accessing its server(s) it can simply not advertise its routes. It is their decision. A Web conternt providers will then go and seek a place which would take their business. >Sanjay. I'm sick of net.socialists who think that universal connectivity is an Unalienable Right Of Every Living Person and that All ISPs Are Born Equal. I've had a chance to learn very intimately what all that Free-For-All crap really means -- when related to pushing bits and when not. --vadim

1 0

Re: Best way to deal with bad advertisements?
by salo＠msc.edu 30 Sep '96

30 Sep '96

> Subject: Re: Best way to deal with bad advertisements? > To: SEAN(a)SDG.DRA.COM (Sean Donelan) > Date: Mon, 30 Sep 1996 12:53:18 -0500 (CDT) > Cc: nanog(a)merit.edu > > > This was to keep the old NSF mid-level networks from losing connectivity > > with each other if they happened to choose different NSPs. I'm guessing > > the NSF connection program has wound down by now, so this isn't that much > > of a factor any more. > > Erm, rather a large number of entities still receive NSF connection funding. > > It's rather amusing what some of them do with it. :-) Obviously, someone at the NSF is better qualified than I to comment on this, but the NSF New Connections program is _not_ being "wound down." If fact, it is being expanded. The current New Connections solicitation adds K-12 institutions and vBNS connections. What is being phased out is direct grants to regional networks. Many regional networks were started with direct NSF grants. Often, the regionals rather liked these funds, and pleaded with the NSF to keep them flowing for just a little while longer. NSF Solicitation 93-52 was the NSF's (successful, I believe) effort to end direct subsidies to regional networks. NSF 93-52 offered funds for regional connectivity, (connectivity out of the region, for example, via an NSP), decreasing to zero over four years. -tjs

1 0