October 2002 - Test - lists.nanog.org

Re: sprint passes uu?
by Paul Vixie 18 Oct '02

18 Oct '02

i wrote: > > transit prices have been in free fall, and worldcom has not been > > following them downward. however, after the cleansing ritual of > > chapter 11, i think they will be in a fine position to reset their > > per-megabit charges in ways that make them a compelling transit > > provider. their network's been great. several people answered me, privately. i'm going to respond publically but preserve anonymity: > But WorldCon billing is a nightmare. We'd really like to stay > connected to UUNet, but WorldCon's inability to bill us in accordance > with our contract and insistance that we pay bills they know are > complete works of fiction make it really difficult. there is a curious mixture of fact and fiction in the general response to a uunet bill. in their version of banded rates, you don't know what rate you will owe until the end of the month, but you pay your commit at the start of the month (or at least that's what MIBH was doing, since the overall costs were lower in that case). i usually found that if i read my uunet bill by candlelight during a new moon, i was able to figure out what it all meant and tie it all back to some kind of reality. i know that there are also just plain errors in some of the bills i've been a third party to. however, these errors are no wierder than the ones on my SBC/PacBell frame relay bills. remember as you read these things that IP providers are resisting commodotization, and that means they have to give out quotes, contracts, and invoices that do not map "apples to apples" against a competitor's quotes, contracts, or invoices. this is creativity for the sake of creativity, and i'd like to see it end, but i don't know how or when that can happen. the real debate is about actual measured cost per bit or per bit-kilometer, and to that end, this next anonymized reply attempts to "go there": > I got Worldcom to quote me $170/meg for a 100Mb commitment about a > month ago. If that's not freefall, I don't know what is. that's not freefall. get yourself a quote from cogent or level(3), for examples. at $170/Mbit for 100Mbit/sec commit you are either paying for "name brand" or you're paying for quality of on-net service to their other customers or you're just plain getting brutalized. note that $170/Mbit is actually below cost for any network smaller than sprint's or uunet's, once you figure in the people, the routes, the rent, and the depreciation, and then fuzz it based on economies of scale. however, the market hasn't bottomed yet, and most people still don't know what their costs are. once we bottom out and start regenerating, $200/Mbit to $300/Mbit for wholesale high-commit transit is going to be just about right, given the single-digit NPM that you get from high capital long term commodity plays. let's talk about network quality, though: > > their network's been great. > modulo a couple of recent multi-hour meltdowns (one nationwide one > regional), yes. i can remember similar meltdowns in sprint, teleglobe, abovenet, mci, c&w, psi, qwest, and at&t (both voice and data for at&t). most of these networks were grown immaturely, without offline simulation of either current or proposed changed topologies. indeed, most of them are too large to simulate offline, so the only system level testing they get is the live kind. equipment vendors and routing protocols have been in continuous flux. periodic meltdowns do not indicate either incompetence or lack of investment, merely that there's been more growth than was sane. (in other words, the dotcom overshoot in networking was technical, not just fiscal.) uunet's network is still as good as they come, and the people who keep it running are still near the top of the field. (though i understand there's been some personnel runoff during the chapter 11.)

2 1

Cisco Catalyst DOS Risk
by Andy Ellifson 18 Oct '02

18 Oct '02

http://www.theregister.co.uk/content/55/27690.html

1 0

RE: www.lucent.com
by Daniel Marquez-Klaka 18 Oct '02

18 Oct '02

Yes, they are back. Strange, even through looking glasses all over the world they were not reachable for at least an hour ?! D. On Fri, 18 Oct 2002, Gibson, Mark wrote: >i can see them > >-----Original Message----- >From: Daniel Marquez-Klaka [mailto:dmk@marquez.de] >Sent: 18 October 2002 10:56 >To: nanog(a)merit.edu >Subject: www.lucent.com > > > >Hello, > >does someone know what happened to http://www.lucent.com ? >Yesterday everything was fine, but now it seams like they >are wiped out of the internet. No DNS resolution (unknown host ?!). > > >Daniel > > >-- >This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. >

3 2

RE: attacking DDOS using BGP communities?
by Frank Scalzo 18 Oct '02

18 Oct '02

701 has a blackhole community, 701:9999, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. -----Original Message----- From: Saku Ytti [mailto:saku+nanog@ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: nanog(a)merit.edu Subject: attacking DDOS using BGP communities? How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps :> -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti

4 4

The Cidr Report
by cidr-report＠potaroo.net 18 Oct '02

18 Oct '02

This report has been generated at Fri Oct 18 21:45:11 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 11-10-02 114611 82522 12-10-02 114687 82431 13-10-02 114551 82294 14-10-02 114344 82657 15-10-02 114786 82675 16-10-02 114805 82681 17-10-02 114726 82664 18-10-02 114704 82837 Possible Bogus Routes 192.0.0.0/24 AS3215 AS3215 France Telecom Transpac AS Summary 13878 Number of ASes in routing system 5410 Number of ASes announcing only one prefix 1759 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73212160 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 18Oct02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 115049 82849 32200 28.0% All ASes AS7132 591 68 523 88.5% SBIS-AS Southwestern Bell Internet Services AS3908 1059 554 505 47.7% SUPERNETASBLK SuperNet, Inc. AS701 1759 1284 475 27.0% ALTERNET-AS UUNET Technologies, Inc. AS7843 756 324 432 57.1% ADELPHIA-AS Adelphia Corp. AS7018 1352 996 356 26.3% ATT-INTERNET4 AT&T WorldNet Services AS4323 518 181 337 65.1% TW-COMM Time Warner Communications, Inc. AS1221 1201 878 323 26.9% ASN-TELSTRA Telstra Pty Ltd AS18566 313 4 309 98.7% COVAD Covad Communications AS852 737 458 279 37.9% ASN852 Telus Advanced Communications AS6347 346 77 269 77.7% DIAMOND SAVVIS Communications Corporation AS4355 385 128 257 66.8% ERMS-EARTHLNK EARTHLINK, INC AS7046 578 342 236 40.8% UUNET-CUSTOMER UUNET Technologies, Inc. AS209 569 337 232 40.8% ASN-QWEST Qwest AS1239 879 661 218 24.8% SPRINTLINK Sprint AS1 651 434 217 33.3% GNTY-1 Genuity AS705 443 226 217 49.0% ASN-ALTERNET UUNET Technologies, Inc. AS4814 229 15 214 93.4% CHINANET-BEIJING-AP China Telecom (Group) AS4151 292 88 204 69.9% USDA-1 USDA AS22927 215 20 195 90.7% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS6595 249 56 193 77.5% DODDSEUR DoD Education Activity Network Assistance Center AS17676 224 34 190 84.8% GIGAINFRA APNIC ASN block AS4134 297 113 184 62.0% ERX-CHINALINK Data Communications Bureau AS17557 301 121 180 59.8% PKTELECOM-AS-AP APNIC ASN block AS6140 256 77 179 69.9% IMPSAT-USA ImpSat USA, Inc. AS2048 262 88 174 66.4% LANET-1 State of Louisiana AS6197 395 226 169 42.8% BATI-ATL BellSouth Network Solutions, Inc AS690 517 350 167 32.3% MERIT-AS-27 Merit Network Inc. AS6198 395 229 166 42.0% BATI-MIA BellSouth Network Solutions, Inc AS1791 185 21 164 88.6% SPRINTLINK3 Sprint Government Systems Division AS2548 426 266 160 37.6% ICIX-MD-AS Business Internet, Inc. Total 16380 8656 7724 47.2% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

www.lucent.com
by Daniel Marquez-Klaka 18 Oct '02

18 Oct '02

Hello, does someone know what happened to http://www.lucent.com ? Yesterday everything was fine, but now it seams like they are wiped out of the internet. No DNS resolution (unknown host ?!). Daniel

2 1

Re: attacking DDOS using BGP communities?
by Saku Ytti 18 Oct '02

18 Oct '02

On (2002-10-18 04:13 -0400), John Fraizer wrote: > You receive a prefix with the communities 1111:1 2222:2 3333:3 and > TTL-COMM:2. You need to decrement the TTL-COMM value while leaving the > other 3 communities unchanged. Yes this would need change in IOS/JunOS but it wouldn't actually be hard to code this feature. But I still think it would be beneficial if green elves would configure it as non-additive change to all routers globally. Yes, you couldn't use it as offering partial visibility since it would most propably break few things here and there but it would increase your possibility in finding out which AS# is/are originating the attack. I'm just waiting for the green elves. But in the mean time, would anyone configure decrement of TTL-COMM if JunOS and IOS would magically start to support such feature in hopes of reaching some time large enough cover to actually do anything good. > Unless *ALL* vendors change their code to compare AS-PATH length for > prefixes against the TTL-COMM value, decrementing the value as the route > is passed from peer to peer is the only way to make this work that I can > think of. Doing that without nixing the other communities that may need > to be passed as well becomes a serious challenge. Yes, it's quite optimistic and naive to think such concensus could be achieved when much more modest changes which would require global co-operation never happen. > Heck, the route-map to do this without regard for other communities would > still be pretty hairy. > > Am I missing something here? No, thanks for the comments. -- ++ytti

1 0

Re: attacking DDOS using BGP communities?
by Saku Ytti 18 Oct '02

18 Oct '02

On (2002-10-18 00:15 -0400), John Fraizer wrote: > > 2) 'TTL' community. > > > > -just think about the amount of route-maps :> > > Whoa. Decrementing a single community integer value while leaving others > unchanged would seem to be a bit tricky. This would require much more > work on the part of others than the first suggestion and I think it would > attract far fewer participants for that matter. Actually would it matter if it wouldn't be additive change? Since it would be diagnostic/special case. But of course it would be trivial for the vendors to add support for changing the communities this way, if this could be performed as a additive change you could offer your customers automaticly partial visiblity under DOS attack until it's resolved rather than 0 visibility. Not to mention how much it would ease pinpointing faulty/aggressive parties thus in long run it could have very positive effect for things like proper anti-spoofing configurations. -- ++ytti

1 0

vrf resources?
by Scott Call 17 Oct '02

17 Oct '02

Hello all. I was recently handed a piece of a network that used VRF to implement vlans. I'm by no means a vrf expert, but the config looks right to me. The problem I'm having is that traffic destined for IP addresses within the VRF Vlan from interfaces not within the VRF vlan (they don't have "ip vrf forwarding" statements in their interface configurations) which of course breaks the whole concept of a private routing table. I've done extensive searching of Cisco's website and have found no mention of this problem, or it's avoidance when setting up a vrf vlan. Lacking a valid service contract, I cannot open a ticket, so any insight is greatly apreciated. Thanks -Scott

1 1

RE: question concerning traceroute?
by Kris Foster 17 Oct '02

17 Oct '02

> a traceroute shows the outbound route. it's possible for the the probe > packets to follow one path and the returning icmp packets to take another > path. a looking glass in the AS your tracing to is a good way to see what > the return path is... The returning ICMP packets may take many different paths back to the sender of the UDPs, since each hop will make it's own decision on how to return to the source (not just the single asymmetric path from the destination of the UDPs). Kris

1 0