- Test - lists.nanog.org

Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 01 Mar '05

01 Mar '05

Hi, as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654. We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them. The proposed timetable of the test announcements is as follows. 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal and, if there are no problems: 2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively. For questions/comments, please contact compunet(a)dia.uniroma3.it or lorenzo(a)ripe.net. Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group [1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html

1 0

Multihoming for the small ISP ( search engine) ala 2005
by Geoff White 01 Mar '05

01 Mar '05

Greetings folks, (It's been a long time :) I have some questions about multihoming that I can't seem to find by Google-ing for answers 1.) What ever happened to (Avi Freedman's?) Multihoming strategy using DNS(?), there are links to archives circa 1997 but nothing recent. 2) What is the "preferred or correct" way for a relatively small outfit (a small search engine) to implement Multihoming? Especially when most of the machines are a VLS cluster so we are not talking about a large address space here. It seems the outfit is having difficulty getting blocks that they can even run BGP with, (I know I'm missing a lot here) They can't even fill a /24, let alone anything greater :) I am willing to take my answers off line. I'm sure there is a way to do this that is so trivial to folks on this list that it's not talked about, but since I haven't done this type of thing in about 5 years I am really out of the loop. Thanks in advance and for all the great work over the years! Cheers Geoff White

4 3

RE: High volume WHOIS queries
by Hannigan, Martin 01 Mar '05

01 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Paul G > Sent: Tuesday, March 01, 2005 5:03 AM > To: nanog(a)merit.edu > Subject: Re: High volume WHOIS queries > > > > > ----- Original Message ----- > From: "Stephen J. Wilcox" <steve(a)telecomplete.co.uk> > To: "joe mcguckin" <joe(a)via.net> > Cc: "Dan Lockwood" <dlockwood(a)shastacoe.org>; "NANOG" > <nanog(a)merit.edu> > Sent: Tuesday, March 01, 2005 4:53 AM > Subject: Re: High volume WHOIS queries > > > > > > altho arguably its not up to arin to provide processing > power for all > these > > deployments. > > > > if you can get a local copy why not have your clients > resolve back to > that? > > that is the point of his post actually - arin told him that > he can't do that > without pointing out where this is prohibited in the aup. i > can see their > point - they're trying to restrict the practicality of > attempting to harvest > the data and an open to the public whois server with no > access restrictions > would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. -M<

4 3

RE: High volume WHOIS queries
by Hannigan, Martin 01 Mar '05

01 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Paul G > Sent: Tuesday, March 01, 2005 9:22 AM > To: nanog(a)merit.edu > Subject: Re: High volume WHOIS queries > > > > > ----- Original Message ----- > From: "Hannigan, Martin" <hannigan(a)verisign.com> > To: "Paul G" <paul(a)rusko.us>; <nanog(a)merit.edu> > Sent: Tuesday, March 01, 2005 9:17 AM > Subject: RE: High volume WHOIS queries > > > > > >> -----Original Message----- > >> From: owner-nanog(a)merit.edu > [mailto:owner-nanog@merit.edu]On Behalf Of > >> Paul G > >> Sent: Tuesday, March 01, 2005 5:03 AM > >> To: nanog(a)merit.edu > >> Subject: Re: High volume WHOIS queries > > --- snip --- > > >> point - they're trying to restrict the practicality of > >> attempting to harvest > >> the data and an open to the public whois server with no > >> access restrictions > >> would defeat that. > > > I don't know that this is the case, I suspect it's > > resource management. If the database is getting > > slaughtered by applications on uncontrolled auto pilot, > > it's unusable for the rest of us. > > well, the OP quoted a portion of the aup that requires bulk > whois data recipients to take measures to prevent harvesting, > so i presume that arin does care about that and, in fact, that > consideration is likely the reason they declined to permit the > OP to run *his own* whoisd off of his *local* copy of the data. The AUP also says for "internet operational or research purposes only." Maybe they don't consider the use to fit in the defintion? There's an easier fix, IMO. Run a two stage query, 50 and 50, and then append the second 50 to the bottom of the first. -M< -M<

1 0

Send-Safe spam tool gang evicted by MCI...
by Fergie (Paul Ferguson) 01 Mar '05

01 Mar '05

The Register is reporting that: "US telco MCI Worldcom has caved in to mounting pressure and booted a site that sells spamming software off its network." http://www.theregister.co.uk/2005/03/01/send-safe_evicted/ - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

SMTP Port Blocking: Success or Failure?
by Claydon, Tom 28 Feb '05

28 Feb '05

We are considering filtering outbound SMTP traffic from our ISP customers, except from our own mail servers, to help reduce the amount of spam originating from our network. How successful/unsucessful has implementing outbound SMTP filtering done in stopping or slowing down spam from your network? Also, if outbound SMTP filtering has not worked for you, are there any other things that you have implemented that have helped with spam traffic? Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company http://www.dobsonteleco.com

8 7

SNMP-ALG
by Tomas Daniska 28 Feb '05

28 Feb '05

Hi, can anyone recommend me anything that supports SNMP-ALG as per RFC2692? So far I only managed to find netfilter/iptables should support it, via a long-time no-progress plugin. However, the plugin simply does not seem to work (I've done loads of debugging, and as well I only managed to find other people complaining about the same symptoms, with no hints on how to resolve the issue). I'll post a summary to the list so direct reply is preferable. Thanks! -- Tomas Daniska systems engineer Tronet, a.s. Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 Nobody ever got rich by telling the American public that what they had was good enough and that they really didn't need anything better! -- Bob Atkins

1 0

Re: AOL scomp
by Robert Bonomi 26 Feb '05

26 Feb '05

> From owner-nanog(a)merit.edu Sat Feb 26 13:42:19 2005 > Date: Sat, 26 Feb 2005 10:27:40 -0500 > From: Rich Kulawiec <rsk(a)gsp.org> > To: nanog(a)merit.org > Subject: Re: AOL scomp > > > On Fri, Feb 25, 2005 at 01:34:21AM -0600, Robert Bonomi wrote: > > Because the recipient *expressly* requested that "all mail which would reach > > my inbox on your system be sent to me at AOL (or any other "somewhere else"). > > I have three somewhat-overlapping responses to that -- and I'll try to > stay focused on operational issues, since this is NANOG, not Spam-L. > (But if you to delve further into this, I would suggest shifting the > discussion there, as it's probably more appropriate.) > > 1. SMTP spam is not mail. "Spam -- it's about _consent_, not *content*." If I, the forwarding system operator have the _consent_ of the mailbox owner on the destination system to forward messages to him, they are *not* spam on _that_ system. This *is* a separaate issue as to whether or not they are spam _on_the_forwarding_system_. Yes, the forwarding system should do everything "reasonable" to suppress spam from (a) reaching the local inbox *or* (b) being forwarded, if the customer has requested mail forwarding. If the recipient has a problem with receiving the forwarded message, he should complain _to_the_FORWARDING_system_ about it. *NOT* to the destinaiton system. > So while the end user on some remote system may have in fact said > "send me everything, including the spam" (although this seems very > unlikely) How about various 'spamtrap' mailboxes, auto-forwarded to a central location for "further processing"? <evil grin> > > This means that every such message from the 'forwarding' system to the > > destination system is, BY DEFINITON, "solicited". The mailbox owner has > > expressly and explicictly requested those messages be sent to him at the > > receiving system. > > This is a definition of "solicited" which is wholly at odds with that > in common practice for the last few decades. By your definition, > the victim of a mailbombing attack would have somehow "solicited" that > abuse merely because they have a forwarding alias on your system. NOT AT ALL. It *IS* 'unsolicited' on _my_ system. It is *not* unsolicited at the final destination system. Questions/complaints/help-requests should be sent *TO*ME*, not to the destination system. He's *MY* customer, too. I've got an incentive to 'make things right'. > I'm not having any. UBE (the proper definition of SMTP spam) doesn't > magically become not-UBE just because it gets forwarded by somebody. Suppose my user "manually" forwards a 'spam' message to an account of his on another system. And then _forgets_ that *he* did it. And reports it to *that* provider as spam coming from my system. Is this _my_ fault? IS spam originating from my system? Should I terminate this user for 'spamming'? > It's still spam, and anyone sending/forwarding it is personally > responsible for their choice to do so. "It's about *consent*, not _content_." Want to try to deny that the recipient _consented_ to the forwarding from his other account? It is _not_ 'unsolicited' (the first word of UBE / UCE) on the destination system. It *may*well* be 'unsolicited' at the system where the customer has the forwarding mailbox. Complaints should be directed to *THAT* system operator, *not* the operator of the destination system. Note: I *agree* that "anyone sending/forwarding it is personally responsible fortheri choice to do so." The person that *made* that choice -- to forward that message -- however, is _the_customer_; the 'owner' of mailbox on the 'forwarding' system, *and* the 'owner' of the mailbox on the destination system. If "my customer" (in his identity on the receiving system) reports "my customer" (in his identity on _my_ system) as sending spam, should I terminate him from my system? After all, he's identified _himself_ as the spammer. > (Yes, I realize that it's not possible to achieve perfection, but that > isn't an excuse for failure to keep trying, continuously. It's not > difficult to block 90% of spam using simple, free measures that rely > entirely on open-source software and freely-accessible data. There's > thus no valid excuse for not doing at least that much -- today.) Yup. Keep it from getting to the point it 'would' get to his inbox, and it won't get forwarded, either. But, if it _does_ get through, the recipient should be complaining about it _to_me_, not to the operator of the destination system.

1 0

Re: AOL scomp
by Robert Bonomi 26 Feb '05

26 Feb '05

> From owner-nanog(a)merit.edu Thu Feb 24 23:19:15 2005 > Date: Thu, 24 Feb 2005 22:46:13 -0500 > From: Rich Kulawiec <rsk(a)gsp.org> > To: nanog(a)merit.org > Subject: Re: AOL scomp > > > On Thu, Feb 24, 2005 at 02:53:14PM -0500, Mark Radabaugh wrote: > > Now here I would disagree. These are specific requests by > > individuals to forward mail to from one of their own accounts to > > another one of their own accounts. > > But a request to forward mail is not a request to facilitate > abuse by forwarding spam. > > > I do not think AOL (or anyone) should consider mail forwarded > > at the customers request as indicating that our mail servers are sending spam. > > Why not? Because the recipient *expressly* requested that "all mail which would reach my inbox on your system be sent to me at AOL (or any other "somewhere else"). This means that every such message from the 'forwarding' system to the destination system is, BY DEFINITON, "solicited". The mailbox owner has expressly and explicictly requested those messages be sent to him at the receiving system. If that person then reports such messages -- that they have EXPRESSLY requested be sent to the receiving system -- as spam, to the operator of the receiving system, then that person is *indisputably* IN THE WRONG for doing so. The _person_ who issued the directive causing that message to end up in the recipient's inbox is the *recipient*himself*. If he reports the message as spam, then it can be logically held that *he* is the spammer. And his access on *both* systems (forwarding and receiving) should be terminated for AUP violation. Now, if the recipient wants to report it to the forwarding system -- so that they can block any further inbound attempts -- that's a whole nother story. Of course, this requires that the person involved be "smart enough" to read and understand the headers on the message. In actuality, *I* am not QUITE as draconian as suggested a couple of paragraphs previously. If I forward somebody's mail and get a complaint from the reciveing system about spam to that user, "originating" from my system, that user *permanently* loses any forwarding privileges/capabilities. No appeal, no _notice_ no 'second chance', no nothing -- forwarding just "stops working" for them. They _were_ told of this "down-side risk", with regard to such an error, *before* the forwarding was enabled. They get to live with the consequences.

3 2

Re: E1 - RJ45 pinout with ethernet crossover cable
by Miquel van Smoorenburg 26 Feb '05

26 Feb '05

In article <cistron.cvn2v1$kc2$1(a)news.cistron.nl>, Miquel van Smoorenburg <miquels(a)cistron.nl> wrote: > >In article ><cistron.Pine.WNT.4.61.0502251117300.4032(a)tech1.office.toastedmedia.net>, >Sam Stickland <sam_ml(a)spacething.org> wrote: >>Quick question: If I have two E1 ports (RJ45), then will running a >>straight ethernet cable between the two ports have the same affect as >>plugging a ballan into each port and using a pair of coax (over a v. >>short distance). >> >>Likewise would using an ethernet crossover cable have the same affect as >>swapping the pairs round on one balland. >> >>Or are the pinouts different to ethernet? I tried googling but couldn't >>find anything (perhaps because I can't seem to spell ballan :/ ). > >The pinouts are different. It's easy to make your own E1 crosscable >though. > >E1 uses pairs 4-5 and 3-6, just swap those. > > 4-5 <------------> 3-6 > 3-6 <------------> 4-5 I wrote this from memory, and I got it wrong. Sorry. It's not 4/5 and 3/6, but 1/2 and 4/5 (as others undoubtedly will point out). Mike.

1 0