April 1999 - Test - lists.nanog.org

Re: address spoofing
by sthaug＠nethelp.no 23 Apr '99

23 Apr '99

> > Furthermore, whether the RFC [1918] says so or not, I'm going to block > > these packets at *my* border routers, because: > > Curious as to the cost (added latency) in doing RFC 1918 source address > filtering on all packets in the context of cost-benfit analysis. Well, we added filtering of spoofed source addresses (ie. our own) at our border routers quite a while ago. Adding filters for the RFC 1918 source addresses was a complete no-brainer - three more lines in a filter that already had around 15 lines. *No* visible (to us) increased processor load or latency. (I'm sure it can be measured - but in our case it's completely lost in the noise.) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

FIBER CUT: Fire in Houston damages fiber
by Sean Donelan 23 Apr '99

23 Apr '99

A fiber reported carrying 3 OC-48 systems was damaged by fire in Houston, TX. The fire was at Pinemont & Rankin. Time-Warner is repairing/patching around the damaged fiber now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

The Cidr Report
by Tony Bates 23 Apr '99

23 Apr '99

This is an auto-generated mail on Fri Apr 23 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 23Apr99 0) General Status Table History ------------- Date Prefixes 160499 58374 170499 58360 180499 58291 190499 58530 200499 58544 210499 58520 220499 58449 230499 58766 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 71.0.2.0/24 from AS1239 *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4930 Number of ASes announcing only one prefix: 2503 (1317 cidr, 1186 classful) Largest number of cidr routes: 375 announced by AS701 Largest number of classful routes: 801 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 360 148 212 58.9% BCnet Backbone AS577 291 181 110 37.8% Bell Canada Backbone AS4293 291 184 107 36.8% IMCI AS174 615 509 106 17.2% Performance Systems International AS4755 167 78 89 53.3% Videsh Sanchar Nigam Ltd. India AS2493 216 129 87 40.3% iSTAR Internet, Inc. AS3749 143 63 80 55.9% TECNET AS4200 175 100 75 42.9% AGIS (Apex Global Information Ser AS721 141 68 73 51.8% DLA-ASNBLOCK-AS AS1267 94 24 70 74.5% IUNET-AS AS7657 191 124 67 35.1% The Internet Group Limited AS7496 97 31 66 68.0% Power Up AS7545 110 46 64 58.2% TPG Internet Pty Ltd AS7046 261 198 63 24.1% UUNET-CUSTOMER AS1785 385 322 63 16.4% NYSERNet Backbone AS1221 449 387 62 13.8% AARNET-AS AS1239 527 467 60 11.4% SprintLink Backbone AS4740 331 274 57 17.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 110 53 57 51.8% UNKNOWN AS3493 238 184 54 22.7% INTERLINK AS719 470 417 53 11.3% LANLINK autonomous system AS72 92 40 52 56.5% Schlumberger Information Network AS803 79 35 44 55.7% SaskNet Backbone AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 110 70 40 36.4% PenTeleData Inc. (ASN-PTD) AS1 508 473 35 6.9% BBNPLANET AS7122 109 77 32 29.4% MTS ADVANCED Network Policy AS9269 52 21 31 59.6% Hong Kong CTI AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Peering Policies
by Sean Donelan 23 Apr '99

23 Apr '99

Why do these things always seem to happen in the spring time? tim(a)clipper.NET (Tim Wolfe) writes: >running over TCP seem to timeout with 2 second delays...) So in order to >maintain connectivity to both of these providers, one would need to buy >transit from each. How does this figure into the future political and >technical growth of the net? Wouldn't this type of apathy tend to push >toward government involvement in this industry? If the largest networks I don't see why. BT/Tymnet and GTE/Sprint/Telenet X.25 networks had miserable interconnectivity, and many people ended up buying connections to both. Or using the Internet instead, which killed both the x.25 network providers. Regulators did step into the telegraph business and require Western Union interconnect with its competitors, just about the time telegraphs ceased as a viable business. ILECs and CLECs are required to interconnect, but that doesn't seem to end problems with lack of inter-office trunks, restrooms, parking lots and other shenanigans. Government involvement doesn't seem to solve the problem. Settlements don't help either, because as we've seen in the ILEC/CLEC cases, one side just simply refuses to pay if it doesn't go the way they wanted. What has worked? Bad press, and customer reaction have stomped most of the peering battles in the past. After a big storm, both sides will issue non-specific press releases saying everything is hunky-dory again. As engineers, we might think there must be a better way. Sometimes the problems aren't technical, and don't have an engineering solution. Master tickets will get escalated to the seventh level senior network gods, and sit indefinitely. Ebbers and Esrey may not know a packet, but when the CEO's get asked about it on CNNfn, it will get fixed darn quick. If it doesn't get fixed? Well, does anyone even care what AGIS's peering policy is anymore? amb(a)gxn.NET (Alex Bligh) writes: >If you order the 5 largest IP networks by traffic profile, you >may get some surprises. Porn and Spam for $500! Traffic profiling will show there is a difference between where people say they go, and where they actually go. And the top 5 networks are not the ones you would expect. Of course, NDA's cover most of that information. >From a traffic engineering standpoint, the Internet is still very much a network of networks. I wouldn't sign any long term contracts with one provider just yet. Just look back 1, 3, 5 years at the changes in who's who. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: address spoofing
by Vern Paxson 22 Apr '99

22 Apr '99

> I actually have never seen a NAT box do this (but would like to hear > about such cases). I have traces of FTP PORT directives with Net 10 addresses in them, and even one in which a public address was included in the first PORT directive but a Net 10 address in a retransmission of the same directive! Vern

2 1

Re: The future of NAPs & IXPs
by Vadim Antonov 22 Apr '99

22 Apr '99

Eric Gentzler <gentzler(a)sprint.net> wrote: >You have missed the news on what current IXP's/NAP's are doing with their >networks. All three of the big boys and up and comer Qwest and dumping >millions into network build-out and DWDM plus DPT technologies which >address scaling up network bandwidth. Current OC192 SONET rings combined >with DWDM and DPT technologies will result in the eventual plumit in >bandwidth cost. Thank you, Eric, for reminding me why i started the Tb router business in the first place. Btw, did you get any routers which can do OC-192 _today_, not in the brave new world? Dragging a lot of fiber never was a problem (except for the Sprint's capacity planners, but that is another story). Routing them is (and, no, you cannot replace it with L2 switching of TDM or WDM kind). Even tag switching breaks down at IXPs (where flows are de-aggregated). The explanation why it is so is provided in a paper i wrote few years ago: http://www.kotovnik.com/~avg/pluris/ip_vs_atm/ ). >If you do not have a T1 to your home I do. --vadim

3 2

Re: address spoofing
by Sean Donelan 22 Apr '99

22 Apr '99

randy(a)psg.COM (Randy Bush) writes: >first, apologies for bringing up an operational issue. Don't worry, I'm sure we'll spin off topic within five messages. >a long while back, i noticed my border filters were showing incoming >packets from 1918 addresses and my own address blocks. i wrote this off >to anomalies and did not have the time to pursue. Steven Bellovin wrote a paper a while back about the mystery packets found on the Bell Labs/AT&T Labs/What-ever-its-called-this-week network. ftp://coast.cs.purdue.edu/pub/doc/network/Packets.ps.Z -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Peering Policies
by Steve Meuse 22 Apr '99

22 Apr '99

At 01:40 PM 04/22/1999 -0700, Tim Wolfe wrote: <snip> >Neither of >these ISPs seems particularly concerned by the fact that they can access the >other's network minimally, if at all. (For some reason some applications >running over TCP seem to timeout with 2 second delays...) So in order to Remember, what you perceive to be an ignorant attitude could be directly related to a couple of factors: 1. Uninformed 1st level support 2. NDAs. Negotiations could be in progress, but are not for public record. I doubt that either of the network providers are completely ignoring the case, they just may not be able to communicate the time frame or actual fix for the problem. Of course, I could be mistaken. -Steve

1 0

Re: address spoofing
by Danny McPherson 22 Apr '99

22 Apr '99

Perhaps ICMP Fragmentation Needed, and more frequently, ICMP Unreachables and Time-Exceeded or the like coming from private addressed devices. I'd wager that if you modified your filters to differentiate ICMP and IP, it'd heavily lean towards ICMP error type stuff... -danny > first, apologies for bringing up an operational issue. > > a long while back, i noticed my border filters were showing incoming > packets from 1918 addresses and my own address blocks. i wrote this off > to anomalies and did not have the time to pursue. > > yesterday, i happened to notice it again. i described it on an internal > mailing list. other folk looked at their filters, and lo and behold, it > is a widespread problem. > > fyi, my filter looks like the following: > > ! what we allow to come in the serials from the world > no access-list 105 > ! PSGnet > access-list 105 deny ip 147.28.0.0 0.0.255.255 any > access-list 105 deny ip 192.83.230.0 0.0.0.255 any > access-list 105 deny ip 198.133.206.0 0.0.0.255 any > ! rfc1918 > access-list 105 deny ip 127.0.0.1 0.255.255.255 any > access-list 105 deny ip 10.0.0.0 0.255.255.255 any > access-list 105 deny ip 172.16.0.0 0.15.255.255 any > access-list 105 deny ip 192.168.0.0 0.0.255.255 any > ! block portmapper and nfsd attacks > access-list 105 deny udp any any eq sunrpc > access-list 105 deny tcp any any eq 2049 > ! block samba > access-list 105 deny tcp any any eq 137 > access-list 105 deny tcp any any eq 138 > access-list 105 deny tcp any any eq 139 > ! > ! some other stuff > ! allow all others > access-list 105 permit ip any any > > the results of 30 hours of running are > > deny ip 147.28.0.0 0.0.255.255 any (6 matches) > deny ip 192.83.230.0 0.0.0.255 any > deny ip 198.133.206.0 0.0.0.255 any > deny ip 127.0.0.0 0.255.255.255 any (375 matches) > deny ip 10.0.0.0 0.255.255.255 any (593 matches) > deny ip 172.16.0.0 0.15.255.255 any (201 matches) > deny ip 192.168.0.0 0.0.255.255 any (769 matches) > deny udp any any eq sunrpc (9 matches) > deny tcp any any eq 2049 (494 matches) > deny tcp any any eq 137 > deny tcp any any eq 138 > deny tcp any any eq 139 > permit ip any any (9467763 matches) > > when we tried it on routers in different parts of the network, it seemed > to show similar patterns. > > anyone have clues other than net slime and misconfigured nats? > > randy >

1 0

Re: Peering Policies
by Paul Ferguson 22 Apr '99

22 Apr '99

At 01:40 PM 4/22/99 -0700, Tim Wolfe wrote: > How does this figure into the future political and >technical growth of the net? Wouldn't this type of apathy tend to push >toward government involvement in this industry? Are you insane? I ask that semi-jokingly, but on the serious side, "government" involvement in a capitalist environment has traditionally stifled technical growth, and subsequently revenue. I can only suggest that true capitalism can solve this problem in the long run. If one provider can't live up to their SLA, change providers. $.02, - paul ps. Standard disclaimers apply.

2 1