- NANOG - lists.nanog.org

Re: Anyone from BT...
by michael.dillon＠bt.com 23 Jan '07

23 Jan '07

> ...on the list who might be able to comment on how they/you/BT is > detecting downstream clients that are bot-infected, and how exactly > you are dealing with them? Unfortunately, the way you phrased that question is rather "journalistic" and in BT, as in most large companies, employees are forbidden from answering such questions without having the answers vetted by various Public Relations and Legal departments. Fortunately, published material is exempt from this rule so Googling for an article I found this: http://www.theregister.co.uk/2006/10/12/bt_spam_buster/ which contains the following: Using data from the system, BT's abuse team can cancel rogue accounts linked to spammers or add offending IP addresses to blacklists. The system also allows BT's admins to contact consumers whose compromised (zombie) PCs have unwittingly been made the part of the junk mail problem and provide advice on cleaning up their systems. Seems pretty clear to me. We take the issue of botnets very seriously and we have invested money into tools which automate some part of the process of identifying and removing bots. Just what was the point of your query? Do you have some issue with traffic emanating from BT's network? I admit that we are a rather large company with several rather widespread IP networks, nevertheless, a simple RIPE database query of "BT" does lead to more than one abuse contact and also lists several real people who you could contact directly if you need to coordinate activity. --Michael Dillon

3 3

Re: Anyone from BT...
by Fergie 22 Jan '07

22 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Peter Corlett <abuse(a)cabal.org.uk> wrote: >On Mon, Jan 22, 2007 at 04:09:48AM +0000, Fergie wrote: >> ...on the list who might be able to comment on how they/you/BT is >> detecting downstream clients that are bot-infected, and how exactly you >> are dealing with them? > >Which bit of BT? They've got their fingers in quite a lot of pies, and the >Clue level varies wildly. > >Although given you've asked that question, I suspect that you're enquiring >about their retail Internet offerings, and my impression is that they >don't bother to check for or deal with infected hosts. > Well, thanks for the response :-) but I am looking for anyone who could shed some light on this statement: "BT has launched an automated system to identify professional spammers and 'botnet'-infected customers on the BT broadband network." ref: http://www.networkworld.com/news/2006/101306-bt-fires-back-at.html I am curious as to what they're actually doing. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFtPjSq1pz9mNUZTMRAnziAJ0dur37zDjC5ji7r+LKz8GwP7w8UgCg8dqH omyWrRvl4I1WffMdZegUEEY= =3jjq -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Anyone from BT...
by Fergie 22 Jan '07

22 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ...on the list who might be able to comment on how they/you/BT is detecting downstream clients that are bot-infected, and how exactly you are dealing with them? Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFtDkGq1pz9mNUZTMRApHfAKCkuZPgTDTIx0/6BErLhWffFa0xRwCeOhdO b3A6O789/hBy0CiXmNiyHn0= =4X/Z -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

3 2

Dubai
by Jim Mercer 22 Jan '07

22 Jan '07

yeah, i know, its the _north american_ network operators, but judging by the posts here, and attendance at the NANOG meetings, there is quite the international audience. looking to hook up with operations and systems administrations people in dubai. if you are out there, drop me a note. -- [ Jim Mercer jim(a)reptiles.org +971 50 436-3874 ] [ I want to live forever, or die trying. ]

1 0

Re: Network end users to pull down 2 gigabytes a day, continuously?
by Brandon Butterworth 22 Jan '07

22 Jan '07

> Increased bandwidth consumption does > not necessarily cost money on most ISP infrastructure. > At my home I have a fairly typical ISP service using > BT's DSL. If I use a P2P network to download files from > other BT DSL users, then it doesn't cost me a penny > more than the basic DSL service. It also doesn't cost > BT any more It does cost BT, as I said someone pays even if it's not obvious to the user > The only time that costs increase is when I download > data from outside of BT's network because the increased > traffic reaquires larger circuits or more circuits, etc. Incorrect, DSLAM backhaul costs regardless of where the traffic comes from. ISPs pay for that, it costs more than transit > The real problem with P2P networks is that they don't > generally make download decisions based on network > architecture. Indeed, that's what I said. Until then ISPs can only fix it with P2P aware caches, if the protocols did it then they wouldn't need the caches though P2P efficiency may go down It'll be interesting to see how Akamai & co. counter this trend. At the moment they can say it's better to use a local Akamai cluster than have P2P taking content from anywhere on the planet. Once it's mostly local traffic then it's pretty much equivalent to Akamai. It's still moving routing/TE up the stack though so will affect the ISPs network ops. > I have to admit that I have no idea how BT charges > ISPs for wholesale ADSL. Hence your first assertion is unfounded > If there is indeed some kind > of metered charging then Internet video will be a big > problem for the business model. It is, BT Wholesale don't give it away (usage or capacity based ISPs still have to pay) > The difference with P2P is that caching is built-in to > the model, therefore 100% of users participate in > caching. But those caches are in the wrong place, they'd be better at the ISP end of the ADSL > With HTTP, caches are far from universal, > especially to non-business users. Doesn't matter if they're buying P2P caches they could buy HTTP if they don't have one already. The point is they're buying something brandon

34 92

RE: Undersea fiber cut after Taiwan earthquake - PCCW / Singtel / KT e tc connectivity disrupted
by Fergie 22 Jan '07

22 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sean Donelan <sean(a)donelan.com> wrote: >The FAA, Federal Reserve, SFTI and SMART are probably at the top as >far as trying to engineer their networks and maintain diversity >assurances. But even the Federal Reserve found the cost more than >it could afford. What commercial banks are doing is impressive, >but only in a "commercially reasonable" way. Some residual risk and >outages are always going to exist. > >No matter what the salesman tells you, Murphy still lives. > This really has more to do with analogies regarding organizations such as DeBeers, and less with Murphy's Law. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFs/0Iq1pz9mNUZTMRAnhwAJ43Idwddu7LUfDyvIRqdal0tB6wKwCfZpgF KRslz7vAmtiHEZQ+CioIgIw= =cC3f -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

New GRH feature: Missing IPv6 prefixes => Many ISP's need IPv6 filter updates!
by Jeroen Massar 21 Jan '07

21 Jan '07

Hi, It seems that there are quite a few ISP's with IPv6 capabilities that are nicely filtering. Of course they also forget to actually update those filters. Blocks that are filtered by quite a number of ISP's that should not be filtered are: 2001:500::/30, 2001:678::/29, 2400::/16, 2600::/12, 2620::/23, 2a00::/16, and 2a01::/16 Note that some of these also have blocks upto /48's because of IPv6 PI space and micro allocations. Pay also special attention to 2001:678::/29 as that contains RIPE's Anycast TLD prefixes sized /48. It seems that these are nicely filtered out (then again RIPE stuck it in the middle of a block where only /32's come from normally) The recommended filters can be found here: http://www.space.net/~gert/RIPE/ipv6-filters.html Please check your filters, to be able to easily able to do what you are missing, you can use the following new GRH features: Want to know what ISP's are missing your prefix? See: http://www.sixxs.net/tools/grh/lg/ enter your prefix and look at the bottom. Want to know which ISP's filter what exactly? For ASN's peering with GRH, those can be looked up at: http://www.sixxs.net/tools/grh/dfp/ see under the heading for Missing prefixes, select and go. There are cross references between the tools so that you can look it easily from both references. Not peering with GRH yet? Check http://www.sixxs.net/tools/grh/peering/ and show the world that your IPv6 routing tables are okay. Which benefits you, but also other folks as they can check without having to find where to debug it ;) Of course, for comments, questions, suggestions, bug reports, don't hesitate to yell to info(a)sixxs.net! Enjoy the week ;) Greets, Jeroen

1 0

ISIS SNMP monitoring help
by Robert Boyle 20 Jan '07

20 Jan '07

Hello, I am posting here because I haven't been able to find what I need despite much searching and a previous unanswered post to cisco-nsp and I'm hoping someone here will have the answer. I need to find the SNMP OID for monitoring ISIS / CLNS neighbors: I tried walking: 1.3.6.1.3.37. and 1.3.6.1.3.37.1.5. and 1.3.6.1.3.37.1.5.1.1.2. and 1.3.6.1.3.37 which is the only OID I have found for ISIS seem to be invalid. I tried on a 7206 running 12.3(19) and a 6506 Sup720-3BXL running 12.2(18)SXF7 both of which are running ISIS and have many neighbors. I am looking for the ISIS roughly equivalent command to the BGP OID which we use to monitor BGP peers, but instead to monitor ISIS neighbor adjacencies: For BGP: 1.3.6.1.2.1.15.3.1.2.a.b.c.d For ISIS: ???? Thanks, Robert btw- For those who helped with my Foundry questions and those who wanted a summary, I am working on the summary now and we are also wrapping up our testing of the MLX/XMR boxes. Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

1 0

what happens when you put a typo in a DNSBL server?
by Wes Hardaker 20 Jan '07

20 Jan '07

A number of ISPs use njabl.org as a DNS BL server. However, starting jan 2 a new domain exists "njalb.org" which is serving A records for anything queried against it's DNS server. (note the difference: njaBL vs njaLB). Previous to this date a misconfigured ISP was just not being protected by the BL. Now, it's potentially dropping all mail from anyone because of the typo. # dig +short mail.merit.edu a 198.108.1.11 # dig +short 11.1.108.198.combined.njabl.org # dig +short 11.1.108.198.combined.njalb.org 64.20.43.107 66.45.232.66 66.45.232.75 66.45.237.187 I know of at least one ISP that is likely dropping mail from everyone... -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett

8 8

Meeting Reminders
by Betty Burke 19 Jan '07

19 Jan '07

All: We are counting down the days to Toronto! I hope you have taken the time to register for NANOG-39. However, if you have forgotten to do so, a few reminders follow. 1. The hotel room rate increases on Saturday, the 20th. <http://www.nanog.org/mtg-0702/hotel.html> 2. The full agenda will be posted on Monday the 22nd. The PC has been working hard to bring a strong program to Toronto. <http://www.nanog.org/mtg-0702/topics.html> 3. Confirm passport issues have been resolved. <http://www.nanog.org/mtg-0702/passport.html> 4. REGISTER!!! <https://www.nanog.org/registration/> As always, send any all suggestions, questions or concerns to us, nanog-support(a)nanog.org. We look forward to a great meeting and in visiting with all soon. All best. Betty NANOG Project Manager

1 0