- NANOG - lists.nanog.org

BellSouth: please stop advertising 209.152.54.0/23
by Jon Snyder 10 Aug '04

10 Aug '04

BellSouth is advertising 209.152.54.0/23, which is part of 209.152.32.0/19 owned by someone else who isn't a BellSouth customer. If anyone from BellSouth is listening, can you please make this stop? Or if you have a working contact at BellSouth please let me know. The number for their NOC listed at http://puck.nether.net/netops/ is not working and emails and phone calls to all of the contacts listed in their ARIN entries have gone unanswered. Here's some relevant routeviews data: route-views.oregon-ix.net>sh ip bgp 209.152.54.0 BGP routing table entry for 209.152.54.0/23, version 30041418 Paths: (14 available, best #7, table Default-IP-Routing-Table) Not advertised to any peer 3292 6939 6389 6198 195.249.0.135 from 195.249.0.135 (195.249.0.135) Origin IGP, localpref 100, valid, external Community: 3292:1107 3292:1905 7500 2516 7911 6389 6198 202.249.2.86 from 202.249.2.86 (202.12.27.99) Origin IGP, localpref 100, valid, external 3277 13062 25462 6320 8001 6389 6198 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, valid, external Community: 3277:13062 3277:65301 3277:65307 6461 6389 6198 209.249.254.19 from 209.249.254.19 (209.249.254.19) Origin IGP, metric 3203, localpref 100, valid, external Community: 6461:5997 16150 13237 174 6389 6198 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 13237:44088 13237:46881 16150:65320 16150:65324 12956 6389 6198 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 12956:20024 12956:28310 12956:28311 8001 6389 6198 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external, best Community: 6389:20103 6389:30132 6389:46198 8001:2000 8001:2006 3333 6320 8001 6389 6198 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 7660 2516 7911 6389 6198 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, valid, external 6939 6389 6198 216.218.252.152 from 216.218.252.152 (216.218.252.152) Origin IGP, localpref 100, valid, external 7911 6389 6198 64.200.151.12 from 64.200.151.12 (64.200.151.12) Origin IGP, localpref 100, valid, external Community: 6389:20103 6389:30132 6389:46198 7911:999 7911:7206 11608 3491 6389 6198 207.246.129.14 from 207.246.129.14 (207.246.129.14) Origin IGP, localpref 100, valid, external Community: 11608:1006 11608:5504 7911 6389 6198 64.200.95.239 from 64.200.95.239 (64.200.95.239) Origin IGP, localpref 100, valid, external Community: 6389:20103 6389:30132 6389:46198 7911:999 7911:7206 6939 6389 6198 216.218.252.145 from 216.218.252.145 (216.218.252.145) Origin IGP, localpref 100, valid, external Thanks, ---------- Jon Snyder

4 3

BGP Redistribution question
by D Train 10 Aug '04

10 Aug '04

While looking into a routing issue, I found that one of my routers wasn't passing one of my static routes, being redist into ospf into bgp, and not sure as to why. It has been a while since I have worked with BGP, so I am a little rusty. The solution was for me to add the following BGP network statement... network 10.86.8.0 mask 255.255.248.0. If statics are being redist info ospf, and ospf is basically being redist into bgp, why did I have to have the network statement. Why didn't it put it into BGP and pass it along? Here is the scenario: Router A: ip route 10.86.8.0 255.255.248.0 10.86.138.14 ATL--CR6513A#ping 10.86.138.14 success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms ATL -CR6513A#sh ip route 10.86.8.0 Routing entry for 10.86.8.0/21 Known via "static", distance 1, metric 0 Redistributing via ospf 1 Advertised by ospf 1 subnets bgp 2 Routing Descriptor Blocks: * 10.86.138.14 Route metric is 0, traffic share count is 1 ATL-CR6513A#sh ip ospf data ext 10.86.8.0 OSPF Router with ID (10.86.194.5) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 898 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.2 LS Seq Number: 80000D87 Checksum: 0x3D49 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 LS age: 554 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.86.8.0 (External Network Number ) Advertising Router: 10.86.194.5 LS Seq Number: 80000D87 Checksum: 0x2B58 Length: 36 Network Mask: /21 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 ATL-CR6513A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.0.0/16, version 1078065 Paths: (2 available, best #2, table Default-IP-Routing-Table) Multipath: eBGP Advertised to non peer-group peers: 10.1.2.9 1, (aggregated by 1 10.1.254.253) 10.1.2.9 from 10.1.2.9 (10.1.254.253) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath 1, (aggregated by 1 10.1.254.252) 10.1.2.1 from 10.1.2.1 (10.1.254.252) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, multipath, best router ospf 1 redistribute static subnets router bgp 2 no synchronization network x.x.x.x network y.y.y.y network 10.86.8.0 mask 255.255.248.0 ***had to be added for this to work, but wasn't present before hand*** redistribute connected route-map OSPF-Links redistribute ospf 1 route-map WW-OSPF-Routes neighbor 10.1.2.1 remote-as 1 neighbor 10.1.2.1 advertisement-interval 1 neighbor 10.1.2.9 remote-as 1 neighbor 10.1.2.9 advertisement-interval 1 maximum-paths 2 no auto-summary route-map WW-OSPF-Routes permit 10 set metric-type internal This is I was seeing on my Upstream Core router: ATL -CR12406A#sh ip route 10.86.8.0 Routing entry for 10.86.0.0/16 Known via "bgp 1", distance 200, metric 0, type locally generated Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 AS Hops 0, BGP network version This is what I was seeing after I add the network statement: GAATL-WW1-CR12406A#sh ip bgp 10.86.8.0 BGP routing table entry for 10.86.8.0/21, version 2210556 Paths: (2 available, best #2, Advertisements suppressed by an aggregate.) Multipath: eBGP iBGP Not advertised to any peer 2 10.1.2.2 from 10.1.2.2 (10.86.194.5) Origin IGP, metric 0, localpref 100, valid, external, multipath 2 10.1.2.6 from 10.1.2.6 (10.86.194.2) Origin IGP, metric 0, localpref 100, valid, external, multipath, best __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

2 1

Re: that MIT paper again
by Paul Vixie 10 Aug '04

10 Aug '04

i wrote: > wrt the mit paper on why small ttl's are harmless, i recommend that > y'all actually read it, the whole thing, plus some of the references, > rather than assuming that the abstract is well supported by the body. > > http://nms.lcs.mit.edu/papers/dns-imw2001.html here's what i've learned by watching nanog's reaction to this paper, and by re-reading the paper itself. 1. almost nobody has time to invest in reading this kind of paper. 2. almost everybody is willing to form a strong opinion regardless of that. 3. people from #2 use the paper they didn't read in #1 to justify an opinion. 4. folks who need academic credit will write strong self-consistent papers. 5. those papers do not have to be inclusive or objective to get published. 6. on the internet, many folks by nature "think locally and act globally". 7. #6 includes manufacturers, operators, endusers, spammers, and researchers. 8. the confluence of bad science and disinterested operators is disheartening. 9. good "actual policy" must often fly in the face of "accepted mantra". we now return control of your television set to you.

2 1

OpenSRS outage
by John Rumpelein 08 Aug '04

08 Aug '04

Folks, I apologize if this isn't the best forum for the question, but does anyone know what is going on with OpenSRS? I have multiple customers on their spam-filtering service (quite handy until about 8 hours ago) whose MX records have been dropped. Then I noticed two of the their three DNS servers are not responding. The third seems to have developed amnesia. Their website appears to be affected as well. -J

1 0

Research - Valid Data Gathering vs. Annoying Other
by Robert Bonomi 07 Aug '04

07 Aug '04

To: nanog(a)merid.edu Subject: Re: Research - Valid Data Gathering vs Annoying Others > Date: Fri, 6 Aug 2004 14:09:01 -0400 (EDT) > From: John K Lerchey <lerchey(a)andrew.cmu.edu> > To: nanog(a)merit.edu > Subject: Research - Valid Data Gathering vs Annoying Others > > > Hi NANOG folks, > > We have a situation (which has come up in the past) that I'd like some > opinions on. [[.. $ mount /dev/soapbox # you have been warned. ..]] > Periodically, we have researchers who develop projects which will do > things like randomly port probe off-campus addresses. The most recent > instance of this is a group studying "bottlenecks" on the internet. Thus, > they hit hosts (again, semi-randomly) on both the commodity internet and > on I2 (abeline) to look for places where there is "traffic congestion". > > The problem is that many of their "random targets" consider the probes to > be either malicious in nature, or outright attacks. Why not? "Their network, *THEIR* rules." *HOW* is one supposed to tell a 'benign' probe from a 'hostile' one, when it is addressed to a machine that doesn't exist, or to a 'service' that doesn't exist on an existant machine? With all the 'overtly hostile' traffic out there, why on earth would anyone consider that, with regard to 'unexpected'/'abnormal' traffic, there should be _any_ 'expectation of innocence'? Surely you don't think that the 'recipient' needs to do a _complete_analysis_ of "what was being attempted, and why" -- including making a determination of the 'intentions' of the perpetrator -- for -every- 'unauthorized' attempt to use their network, before complaining about the fact of an attempt at 'unauthorized use'? I have a very _simple_ rule -- if it isn't intended for a service I make available, on a machine I let the world have access to, then it is, _by_ definition_, an attempt to access that machine 'without authorization, or in excess of the authorization granted'. Because the -only- 'authorized use is those things whiich I expressly let past my firewall. Ergo, if the firewall blocks it, it _IS_ an 'unauthorized access' attempt. Whereupon, 18 USC 1030 (b), becomes *very* relevant, given the language of 18 USC (a) (2) (C). The minimum penalty is 'up to a year imprisonment'. given any 'extenuating circumstances' and it could be up to 20 years. On my _personal_ network, at home (a /29 -- big wow:), I currently see well over FIFTEEN THOUSAND unauthorized probes per day. Of those, a *maximum* of 1-in-four-thousand *might* "possibly" be legitimate. I give people the 'benefit of the doubt', and assume that these probes are coming from virus-infected (unbeknownst to the owner) machines, rather than 'deliberate, with malice aforethought' hacking attempts by the machine's owner. HOWEVER, that notwithstanding, *EVERY*ONE* gets reported to the responsible _network_operator_ -- as an 'apparent virus-infected machine on your network', With the relevant supporting documentation, and a simple request that the machine be disabled from external network access until it has been sterilized and secured against further infection. The reporting is mostly to help the other operators keep _their_ networks clean. And to get those machines off-line -- so that they cannot infect other 'unprotected' machines. I'm confident _my_ network is adequately protected. <grin> Note: I "don't care" _what_ the 'name' of the machine is -- I don't even check for rDNS, I look up the registered netblock _owner_ of the IP address, at the RIR. And THAT is where the complaint reports go. > As a result of this, > we, of course, get complaints. Deservedly so. > One suggestion that I received fro a co-worker to help to mitigate this is > to have the researchers run the experiments off of a www host, and to have > the default page explain the experiment and also provide contact info. People are supposed to 'take it on faith' that what the website _says_ about what is going on _is_ what is *actually* happening? I hope you don't mind if I laugh -- Computerized 'social engineering', in an attempt to deflect complaints, _is_ a humorous concept. Do you *really* think that anybody is going to bother to go look to see _what_ the source system 'claims' is the reason it is doing what it is doing? If the traffic isn't a webserver _response_, then the fact that it comes from a machine named 'www.{something}' just means that something *unrelated* to the webserver is also running on that machine. And, therefore, no reason to believe that the webserver at that (coincidentally same) address would have any information whatsoever about the 'offensive' behavior observed.) I wouldn't even know *IF* an 'offending' machine had such a name. I don't do rDNS look-ups on any of the addresses I send complaints off about. > We also discussed having the researchers contact ISPs and other large > providers to see if they can get permission to use addresses in their > space as targets, and then providing the ISPs with info from the testing. This is one of two _good_ approaches. "Get Permission. *FIRST*" > How do you view the issue of experiments that probe random sites? Should > this be accepted as "reasonable", or should it be disallowed? Something > in between? "Private property is *private* property." The Internet consists *exclusively* of private property. those who own the property get to make the rules for -their- property. What 'everybody else' thinks are 'appropriate' rules is immaterial to how they run -their- property. (Well, except that if 'everybody else' doesnt like the way you run your property, they *are* free to choose to not let you visit _their_ property. :) If _I_ say that thus-and-such is an 'objectionable use' of *my* property, nobody, but *nobody*, has any standing to contradict me. Virtually _every_ AUP says that 'your' use of 'foreign' networks is subject to what _they_ (the foreign netowrk operator) deems to be 'acceptable' use of *their* network. The fact that complaints _are_ being generated is *proof* that they do not think that such is 'acceptable use'. And that, therefore, the perpetrators (despite 'good intentions') *ARE*, in all liklihood, in violation of _their_ _own_ TOS/AUP. > What other suggestions might you have about how such experiments could be > run without triggering alarms? That is *easy*. TRIVIALLY EASY. _rent_ a node on those foreign networks. run probes _to_ the hosts *you* control. (This is the second good approach: "Buy access.") Voila! "No problem." >From a pure philosophical standpoint, 'random testing' is no different than "spamming". Both rely on the use of "other people's resources", *WITHOUT* the consent/permission of those other people, and covering the costs of the resources involved. Since the 'testee' is paying for fully half of the costs of the testing, they must be consulted _in_advance_. If you want to claim that the testing "isn't wrong" because it only costs any testee an 'insignificant' amount, You better be prepared to accept all the traffic from the spammers who use exactly the same 'defense'. Executive summary: Method of choice: "Get Permission. *FIRST*." If that fails, try: "Buy Access." If =that= fails, then "Don't Do it!"

13 13

Research - Valid Data Gathering vs Annoying Others
by John K Lerchey 07 Aug '04

07 Aug '04

Hi NANOG folks, We have a situation (which has come up in the past) that I'd like some opinions on. Periodically, we have researchers who develop projects which will do things like randomly port probe off-campus addresses. The most recent instance of this is a group studying "bottlenecks" on the internet. Thus, they hit hosts (again, semi-randomly) on both the commodity internet and on I2 (abeline) to look for places where there is "traffic congestion". The problem is that many of their "random targets" consider the probes to be either malicious in nature, or outright attacks. As a result of this, we, of course, get complaints. One suggestion that I received fro a co-worker to help to mitigate this is to have the researchers run the experiments off of a www host, and to have the default page explain the experiment and also provide contact info. We also discussed having the researchers contact ISPs and other large providers to see if they can get permission to use addresses in their space as targets, and then providing the ISPs with info from the testing. How do you view the issue of experiments that probe random sites? Should this be accepted as "reasonable", or should it be disallowed? Something in between? What other suggestions might you have about how such experiments could be run without triggering alarms? Please send any suggestions directly to me and once I have some answers, I'll post a compilation to the list. Thanks! John John K. Lerchey Computer and Network Security Coordinator Computing Services Carnegie Mellon University

2 1

RE: Research - Valid Data Gathering vs. Annoying Other
by Michel Py 07 Aug '04

07 Aug '04

> John K. Lerchey wrote: > The problem is that many of their "random targets" consider > the probes to be either malicious in nature, or outright > attacks. As a result of this, we, of course, get complaints. [me puts the politician/opportunist suit on. It's election year, after all]. The one thing I would suggest, if you get complaints, talk to the dude that wrote the "testing" thing to make it look like an attack than it currently appears. Vote for me. [/suit off] That being said, you might want to read again an excellent post from Steve Atkins earlier :-) OMG, someone from China just tried to telnet to my router. I'm calling the FBI, the CIA and the NSA right away. The vty password is "san-fran" not "cisco", bozo. > One suggestion that I received fro a co-worker to help to > mitigate this is to have the researchers run the experiments > off of a www host, and to have the default page explain the > experiment and also provide contact info. Good idea, but largely useless as described, IMHO. I would suggest a better way, have the reverse lookup (PTR) of the testing IP address resolve to something like "see-www-dot-cmu-dot-edu-slash-testing" and have the explaining web page there; this might help with GWF[1] > We also discussed having the researchers contact ISPs and other > large providers to see if they can get permission to use addresses > in their space as targets, and then providing the ISPs with info > from the testing. The answer is no. > How do you view the issue of experiments that probe random > sites? Should this be accepted as "reasonable", or should > it be disallowed? Something in between? Irrelevant. Each operator and network admin will have a different opinion about it, and we all filter traffic the way we see fit. You will not get anything remotely close to a consensus here. [1] GWF > Steve Atkins wrote: > [GWF] Goober With Firewall. Originally from internal jargon > at abuse(a)above.net - a complaint, for example, that > "ns1.above.net is hackoring my port 53!" would be, and > should still be, closed with the sole annotation being "GWF". Alternate acronym meaning: Goon With Firewall. GWFes are mostly a by-product of IDS sales droids: first, they find one of these goober execs to attend a demo, then they crank up their gizmo that will find "high risk" alarms out of the ordinary network noise, then the exec hires a cheaper banana^H^H^H^H^H peanut eater aka GWS that does not know jack and has nothing to do but investigate the IDS alarms. The only thing that worries me about the recommendation I am about to make is that it is the same that we collectively used to think was the appropriate answer to spam (a long time ago): the delete key is your friend. Michel.

1 0

Reporting the state of an apparatus to a remote computer patented
by Scott Whyte 07 Aug '04

07 Aug '04

Thought this was relevent to nanog readership.. Abstract The state of an apparatus is reported to a remote computer using an embedded device in the apparatus. The embedded device detects the state, generates an electronic mail message that reports the state using a self-describing computer language, and sends the electronic mail message to the remote computer. The remote computer receives the electronic mail message and extracts the state of the embedded device from the message. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… Further, "Axeda has 11 additional patents pending in the United States and 10 international patents pending covering other aspects of the remote management of intelligent devices." http://www.axeda.com/products/drm-technology/patented-technology.html

4 4

low-latency bandwidth for cheap?
by Jeff Wheeler 06 Aug '04

06 Aug '04

This may be the wrong forum to ask this, and if so I apologize, please just point me in the right direction! I'm getting somewhat frustrated with the instability and high latency of residential cable and DSL offerings, but I love the T1 or greater bandwidth they offer. I'd like reasonable bandwidth with low latency without spending hundreds of dollars per month! Anybody know a good source for near-T1 low-latency bandwidth at around $100/month? I'm in the northern VA area btw. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace

11 14

Regional transit pricing differences?
by Steve Gibbard 06 Aug '04

06 Aug '04

I'm attempting to do some research on how having a local exchange point affects transit pricing. Common sense and anecdotal evidence suggests that transit should be and is cheaper when the data can be handed off through local peering, but I don't have any hard data to back that up. I'm hoping I can get answers to the following questions from a large number of US ISPs in a wide variety of locations: - What city or area are you in? - What city do you buy your transit in? - How far do you have to haul the data from where you buy the transit to where you use it? - How much are you paying for your transit connections -- dollars per megabit per second and how many megabits per second? - How much are you paying for circuits to connect you to the transit provider, if the circuits aren't included? - Do you peer at an exchange point? If so: - Which one? - How close is it to you? - How much are you paying for the port, and for how much traffic? - How much are you paying for circuits to get to the exchange? I'm looking for actual negotiated prices, not opening offers from sales people. I'm only really looking for US data at this point. I'll probably ask this question again about other countries at some point in the future, but at this point involving multiple countries would introduce too many other variables. I recognize that a lot of this information is covered under non-disclosure agreements, and may also be seen as sensitive internal company information. Therefore, I don't want to know who the transit providers are, and I don't particularly need to know who you are. I'm planning to aggregate the data together by region, and publish only the aggregates, not the data from any individual networks. I probably won't post an immediate summary to the list, but I should have a paper on the subject written by Mid-October. Thanks, Steve Gibbard Packet Clearing House

1 0