February 2003 - Test - lists.nanog.org

Re: ebgp-multihop
by Stewart, William C (Bill), SALES 28 Feb '03

28 Feb '03

I'm assuming that the reason Tim's asking about setting TTLs to numbers like 255 is because he wants to use the BGP TTL Security Hack to protect against BGP DDOS attacks. The hack works by setting TTL to a very high value, and ACL-discarding any BGP packets that don't have TTLs >= ~254, because it's very hard to fake TTLs, especially from far away. http://www.ietf.org/internet-drafts/draft-gill-btsh-01.txt http://www.nanog.org/mtg-0302/hack.html - Dave Meyer's Abstract http://www.nanog.org/mtg-0302/ppt/meyer.pdf - Dave Meyer's Talk. (Hmmm.. Dave's abstract says he's at Sprint and U of Oregon Tim is at Oregon Health Sciences University.) The internet-draft and Dave's talk both say that for multi-hop you need to set the ACL thresholds a hop or two lower (obviously), which expands the set of people who might be able to inject hostile packets, but it's still pretty tightly contained. Bill Stewart bill.stewart(a)pobox.com

1 0

RE: BGP to doom us all
by Jim Deleskie 28 Feb '03

28 Feb '03

Bruce, I agree, while we all need to 'do the right thing' and only announce what we are suppose to, we also need to maintain the right level being paranoid to protect the networks we are responsible for. -Jim -----Original Message----- From: Bruce Pinsky [mailto:bep@whack.org] Sent: Friday, February 28, 2003 5:17 PM To: Jim Deleskie Cc: 'nanog(a)merit.edu' Subject: Re: BGP to doom us all Jim Deleskie wrote: > > http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling What a crock of crap. Knowing who someone is doesn't stop them from causing intentional or unintentional problems. In fact, authentication is more likely to cause people to become complacent wrt their filtering policies. Hey I've authenticated that router so it's going to only send me correct routes. Puleeeaaazzzz... ========== bep

2 1

Re: Cidera shuts down
by David Colon 28 Feb '03

28 Feb '03

I know that some others have made offers and Newsread.com is doing the same. We can provide news feeds to networks that we peer with and those that we do not have direct connectivity to. Contact me offlist for details. David Colon News Admin Newsread.com > Just received this from Cidera: > > "We regret to inform you that Cidera has discontinued its netnews and caching services effective immediately. > > We wished to provide you with more advanced notification of this termination of service, but unfortunately we were not able to do so. > > The current economic situation has been difficult for us and for our customers, and we wish all of you the best of luck and good fortune with your businesses. Everyone at Cidera feels it has been a privilege to serve you." > > > > > I am now in need of obtaining a new source for news that is satellite based. Can anyone offer any suggestions > and or recommendations? All information is appreciated! > > Regards, > Jeff > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com) > Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003

1 0

ebgp-multihop
by Tim Rand 28 Feb '03

28 Feb '03

Hi - I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim Tim Rand Network Engineer OHSU Information Technology Group ph: 503.418.1045 fx: 503.494.7143

7 6

The Cidr Report
by cidr-report＠potaroo.net 28 Feb '03

28 Feb '03

This report has been generated at Fri Feb 28 21:46:34 2003 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 21-02-03 119400 85542 22-02-03 119615 85397 23-02-03 119379 85455 24-02-03 119479 85425 25-02-03 119470 85630 26-02-03 119690 85676 27-02-03 119740 85694 28-02-03 119708 85768 AS Summary 14678 Number of ASes in routing system 5782 Number of ASes announcing only one prefix 1604 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73080832 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'). --- 28Feb03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 119861 85734 34127 28.5% All ASes AS3908 1084 568 516 47.6% SUPERNETASBLK SuperNet, Inc. AS18566 491 8 483 98.4% COVAD Covad Communications AS701 1604 1151 453 28.2% ALTERNET-AS UUNET Technologies, Inc. AS4151 532 105 427 80.3% USDA-1 USDA AS4323 533 169 364 68.3% TW-COMM Time Warner Communications, Inc. AS7018 1385 1025 360 26.0% ATT-INTERNET4 AT&T WorldNet Services AS7843 556 224 332 59.7% ADELPHIA-AS Adelphia Corp. AS6197 485 157 328 67.6% BATI-ATL BellSouth Network Solutions, Inc AS7046 559 244 315 56.4% UUNET-CUSTOMER UUNET Technologies, Inc. AS1221 1121 816 305 27.2% ASN-TELSTRA Telstra Pty Ltd AS1239 969 686 283 29.2% SPRINTLINK Sprint AS4355 402 119 283 70.4% ERMS-EARTHLNK EARTHLINK, INC AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 450 196 254 56.4% ASN-ALTERNET UUNET Technologies, Inc. AS4814 264 15 249 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS6198 439 205 234 53.3% BATI-MIA BellSouth Network Solutions, Inc AS1 662 435 227 34.3% GNTY-1 Genuity AS22291 243 31 212 87.2% CHARTER-LA Charter Communications AS17676 230 26 204 88.7% GIGAINFRA XTAGE CORPORATION AS6347 369 168 201 54.5% DIAMOND SAVVIS Communications Corporation AS2386 478 283 195 40.8% INS-AS AT&T Data Communications Services AS209 528 337 191 36.2% ASN-QWEST Qwest AS4134 304 113 191 62.8% CHINANET-BACKBONE No.31,Jin-rong Street AS690 498 308 190 38.2% MERIT-AS-27 Merit Network Inc. AS2048 258 87 171 66.3% LANET-1 State of Louisiana AS852 599 444 155 25.9% ASN852 Telus Advanced Communications AS7303 240 90 150 62.5% AR-TAST-LACNIC Telecom Argentina Stet-France Telecom S.A. AS22773 182 32 150 82.4% CCINET-2 Cox Communications Inc. Atlanta AS6140 285 136 149 52.3% IMPSAT-USA ImpSat AS6327 187 41 146 78.1% SHAWFIBER Shaw Fiberlink Limited Total 16232 8233 7999 49.3% 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)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Could you check your bogon filter?
by Katsuya Saito 28 Feb '03

28 Feb '03

Hi, Now, we face a serious problem in use following five new APNIC Class B cidr blocks. 1. 221.112.0.0/16 2. 221.114.0.0/14 (actually, we registered 4 class B cidr Blocks to RADB ) I checked "Rob's Bogon list" (http://www.cymru.com/Documents/bogon-list.html) But his lists was already changed in Ver. 1.2. He noted updates as follow. "221/8 allocated to APNIC. Removed from bogon lists" But in actual, I guess some ISP forget updating this. In fact, when http://bgp.potaroo.net/cidr/ checked, there are no bogus routes in Feb, 28, 2003. But 2 days before, according to "http://www.employees.org/~tbates/cidr-report.html", our cidr was in bogus routes lists as follow, Possible Bogus Routes *** Bogus 10.1.1.1/32 from AS(65303) *** Bogus 82.32.0.0/12 from AS5462 *** Bogus 221.6.0.0/17 from AS4134 *** Bogus 221.6.128.0/17 from AS4134 *** Bogus 221.18.0.0/16 from AS17676 *** Bogus 221.23.0.0/16 from AS17676 *** Bogus 221.95.0.0/16 from AS17676 *** Bogus 221.112.0.0/16 from AS17506 *** Bogus 221.113.0.0/18 from AS4685 *** Bogus 221.113.64.0/18 from AS10013 *** Bogus 221.113.128.0/17 from AS4713 *** Bogus 221.114.0.0/16 from AS17506 *** Bogus 221.115.0.0/16 from AS17506 *** Bogus 221.116.0.0/16 from AS17506 *** Bogus 221.117.0.0/16 from AS17506 Still now, ours blocks is not free from some one's router bongon filter. Please check your using bogon lists.......... and Please fixed it if it is possible. Or if you know some another reason of this problem or mistake of my idea, please let me know. Please reply off-list, Thanks, ---Katsuya Saito U's Communications Corp.

1 0

Q: How to avoid retaining "portable" class C?
by scott.davis＠beanfield.com 28 Feb '03

28 Feb '03

I realize this is a little too non-operational for the list, but I stupervise a 750 desktop net with a portable class C when I haven't lost myself in the pub. We use about (approximately) 6 of those 253 useable addr's. I could cut that down to 4, I think. I don't think we're worthy of the cross-ISP portable subnet. The company is nearly 100 years old (in Canada!) but we just use email/user surf. Can anyone share advice about how I might communicate "this is generally bad 'cause of BGP table size" issues to a non-technical manager..? This individual thinks our netblock is a continued reason for his/her employment, as per usual. Off-List replies would be appreciated. (416) 432-4334. Anytime. -- Scott.

1 0

Cidera will be back up
by Ringdahl, Dwight (WebUseNet) 27 Feb '03

27 Feb '03

By midnight, providing the bandwidth challenged UseNet feeds again. WebUseNet will make an announcement of our business deal with Cidera in the near future. We are glad we were able to help save this important resource on the Internet. Dwight Ringdahl WebUseNet

1 0

Re: RIPE Down or DOSed ?
by Dave Israel 27 Feb '03

27 Feb '03

On 2/27/2003 at 10:44:49 -0800, Will Yardley said: > > On Thu, Feb 27, 2003 at 11:09:19AM -0500, kai(a)pac-rim.net wrote: > > > And on a related topic (whois.ripe.net almost unreachable, along with > > the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for > > about 4 days: Level3 was informed, but seems to have some good reasons > > of their own not to fix this.... > > > $ telnet rwhois.level3.net 4321 > > Trying 209.244.1.179... > > telnet: Unable to connect to remote host: Connection refused > > There is no public access to rwhois.level3.net (it worked at one point, > but, accurding to Level3, not intentionally). They say that they don't > have to make this information available to anyone except ARIN. I was > always under the impression that delegations had to be publicly visible, > but looking at ARIN's policy more closely, it seems that the information > only has to be available to ARIN. If the ARIN server recurses properly, you should be able to pull it out that way. So hiding it from everybody but ARIN doesn't make the information unavailable. They're probably sheltering themselves from security concerns in the server. -Dave

1 0

RIPE NCC network affected by the DDoS attack (fwd)
by Daniel Diaz 27 Feb '03

27 Feb '03

------- Forwarded Message Date: Thu, 27 Feb 2003 18:18:25 +0100 From: Andrei Robachevsky <andrei(a)ripe.net> Sender: dns-wg-admin(a)ripe.net To: local-ir(a)ripe.net, db-wg(a)ripe.net, dns-wg(a)ripe.net Subject: RIPE NCC network affected by the DDoS attack Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC ------- End of Forwarded Message

1 0