- NANOG - lists.nanog.org

Re: SMTP authentication for broadband providers
by Miquel van Smoorenburg 13 Feb '04

13 Feb '04

In article <cistron.20040212023825.GA77062(a)metron.com>, Lou Katz <lou(a)metron.com> wrote: > >On Wed, Feb 11, 2004 at 03:13:30PM -0500, Sean Donelan wrote: >> >> On Wed, 11 Feb 2004 Valdis.Kletnieks(a)vt.edu wrote: >> > On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said: >> > > what about port 25 blocking that is now done by many access providers? >> > > this makes it impossible for mobile users, coming from those providers, >> > > to access your server and do the auth. >> > >> > Port 587. >> > >> >> So is it time for ISPs to start blocking port 587 too? >> >> If the complaints are going back to the IP address anwyay, why shouldn't >> an ISP force it subscribers to go through the ISPs mail servers so it can >> control any messages sent by its subscribers? > > >Because, maybe, I don't think it is a good idea for someone else to CONTROL >any messages I might send. Who will control the controllers? As if they don't yet CONTROL the messages you receive ? Where, exactly, is your POP3/IMAP mailbox located ? Ah, you run your own mailserver for your own domain. So, you can use the submission port on your own mailserver, right ? Mike.

4 4

Re: SMTP authentication for broadband providers -- A MODEST PROPOSAL
by Dr. Jeffrey Race 13 Feb '04

13 Feb '04

On Thu, 12 Feb 2004 22:58:18 -0800, Dave Crocker wrote: > To attack spam, we need to attack it at its core, not at some secondary or > tertiary side-effect, with a mechanism that also hurt legitimate users. > So, what, exactly, _is_ that core? > Unless and until there is broad community consensus that answers that > question in concrete and practical terms, then all our efforts are > losing and stop-gap. A concrete and practical solution, which has been proven to work in hours, engineered from well-known principles of human behavior: <http://www.camblab.com/misc/univ_std.txt> derived from <http://www.camblab.com/nugget/spam_03.pdf>. Suggestions welcome. When I get some time (maybe in April) I may get to put this into the RFC-draft hopper. Needs a day of reformatting I've not gotten to yet. Anyone who has done this and could volunteer to help, contact me offlist. Kind regards to all, Jeffrey Race, today in Bangkok Thailand ---------------------------------------- USA tieline (rings at Bangkok residence) TIME ZONE GMT +7 -------------+1 617 395-4111------------ Tel +66 2 291-2235 Fax +66 2 688-4540 Tel +66 6 709-7645 (mobile -- 24 hours) Tel +66 6 563-5682 (mobile -- odd times) ADVENTURES IN THAI JUSTICE Cautionary real-life case studies for potential investors or visitors <http://pws.prserv.net/studies/>

1 0

SMTP authentication for broadband providers
by Dan Ellis 13 Feb '04

13 Feb '04

Greetings, We're a medium sized regional MSO/broadband provider with 200k+ mailboxes, strongly considering enabling SMTP authentication on our customer-facing SMTP mail servers. We feel this is the next logical step to minimize our users UCE/virus impact (we already tarpit, virus scan, UCE scan, subscribe to RBL's, reject prior to SMTP close). I'm looking for comments on whether this is generally seen as a positive change or a waste of time (ie - will the next virus or worm gleam your SMTP username and password from Outlook Express and use it to replicate/SPAM)? Is anyone aware of any well known mail clients that do not support SMTP authentication (Unix, Windows or Mac)? Thanks in advance. --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay

12 18

Interesting BIND error
by Brian Wallingford 13 Feb '04

13 Feb '04

We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same. Seems harmless enough, but the logging is eating a disproportionate amount of cpu. Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument >From socket.c: #undef ALWAYS_HARD /* * The other error types depend on whether or not the * socket is UDP or TCP. If it is UDP, some errors * that we expect to be fatal under TCP are merely * annoying, and are really soft errors. * * However, these soft errors are still returned as * a status. */ isc_sockaddr_format(&dev->address, addrbuf, sizeof(addrbuf)); isc__strerror(send_errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, "internal_send: %s: %s", addrbuf, strbuf); dev->result = isc__errno2result(send_errno); return (DOIO_HARD);

10 11

Where can I find a list of IPs and their regions.
by Matthew Crocker 12 Feb '04

12 Feb '04

I've look at IANA but it doesn't give enough detailed information. I would like to find a list of /8 or /16s and what geographic region the exist in. I know it isn't an exact science but something close would be nice. I know 210/8 & 211/8 are APNIC, I likes to know stuff like 210.100/16 is Korea and 210.120/16 is China, etc. Does anyone have a list I can pull from? -Matt

9 16

Peering BOF VII Meeting Minutes (NANOG 30 Miami)
by William B. Norton 12 Feb '04

12 Feb '04

Hi all - For those of you who could not attend the BOF, here are my notes from the Peering BOF. Comments welcome - Peering BOF VII - NANOG 30 - Miami 2/10/2004 7PM Moderator: William B. Norton We were at capacity in the room and started right at 7PM. The Great Debate -------------------------- The Peering BOF started with a refereed debate on "Restrictive Peering Policy: Makes Business Sense vs. Counter Productive." The debate at the Peering BOF was a first miniature stab at a Internet Operations debate focusing on an emotional charged topic, one area perceived as being concealed by NDAs, hidden agendas, greedy corporate interests, ill will: Restrictive Peering Policies. People attending the BOF heard in about 20 minutes some pretty good arguments why such a policy made business sense, and why it was also counter productive. I opened sharing some of the controversy, sharing the definitions of peering, transit, restrictive, selective and open peerign policies, etc. These should be on-line at http://www.nanog.org/mtg-0402/norton.html Vijay Gill (AOL) agreed to present the Affirmative Case, that Restrictive Peering Policies make business sense. He argued that Peering Policies are not emotional, not personal, but black & white decisions based on economics, a calculation on a spreadsheet. Peering is not free and there are scaling issues and associated operational costs that must be justified. Peering is also somewhat of a threat to revenue production as well, since peering between customers bypasses the ISP. Avi Freedman (Akamai) agreed to present the Counter Case, that Restrictive Peering Policies are counter-productive. He pointed to the overhead associated with peering as being a rare exception; peering sessions tends to stay up. Avi pointed to the counter productive aspects of a Restrictive Peering Policy: 1) It inspires the wrong thing. Sprint will never peer with anyone that ever bought transit from them, and that in fact drives the "End-run, peer with Sprint's customers" behavior that lowers revenue for Sprint. 2) Many large networks lose revenue by not peering more openly, as it turns off customers, and 3) Performance improvements from peering widely *increase* revenue. Avi eluded to his AboveNet experience where he witnessed a) customer behavior: customers spending more time on line because of a better experience, b) lower latency and lower packet loss lead to the TCP window opening up faster means more data is exchanged, thus leading to more $ for those that charge on a per-Mbps basis. Better performance drives more revenue. Vijay countered with the "reducto ad adsurdium" argument; the case of peering with each of 200 million laptops computers running zebra. The overhead of peering with 200M laptops would certainly fail the cost benefit analysis. As far as the performance argument, he claimed that the top visited sites from AOL show little performance difference ("imperceptible") between paths reached across peering versus transit links. Finally, he dismissed the selection of an ISP based on Peering Policy, claiming it is today all driven by price. The peering decision is business and mathematical, black & white, a pure economic decision that does what is best for the company. Avi finished up by dismissing the peer-with-all-laptops as not reasonable, not what anyone is advocating, not what is being debated. He argued that the debate is really speaking to the reasonable middle ground case, where both parties have infrastructure deployed. Around 50% of customer traffic will go around you if you do not peer more openly. Restrictive Peering Policies analysis must include the opportunity cost of lost business and lost revenue, a more difficult calculation to make but one that ultimately shows Restrictive Peering policies as counter productive. VERDICT: The audience voted on "which side presented the more compelling case". The winner: Restrictive Peering Policies are Counter Productive (35-43). (Editor's note: this was much closer than I think most people expected; the audience at the Peering BOFs are generally open or selective peers, and have or expect to be stubbed if trying to peer with a Restrictive Peering Policy peer. Both sides presented a good case.) Cable & Wireless: A Tier 1 Peering Policy evolution & C&W migration to Savvis ------------------------------------------------------------------------------------------------------------------ After the debate, Peter Jansen (Peering Coordinator for C&W) volunteered to share with the audience a bit about the evolution of the C&W Peering Policy and what led to their current Peering Policy. He positioned a restrictive policy as a natural outcome of commercial interests (peering costs money) and but said that they will in fact peer with those that meet the peering criteria. There is a committee that evaluates and verifies the requests and there are no personalities involved here. There was a good exchange in the group with a handful of Q&A. Peter did a great job - he put a face to what was otherwise seen as cold corporate interests. He also spoke about the transition C&W is going through, migrating its network to Savvis. The audience was definitely engaged and interactive during these two sessions. The correlation was brought up between Restrictive Peering Policies and Bankruptcy (Wcom, C&W, Genuity, TeleGlobe, ...). Someone made the point that many of the ISPs with Restrictive Peering Policies that had argued for making Peering decisions based on economic analysis had in fact gone bankrupt... How good can those spreadsheets be? The debate generated a good sized crowd at the Peering BOF. Everyone likes a good fight I suppose, and the Peering BOF is one of the few places where people understand and care about this stuff. Peering Personals --------------------------- We spent the second half of the Peering BOF with Peering Personals, a chance for Peering Coordinators to introduce themselves to each other in a 2 minute talk. On the screen behind them were Contact details, AS#, Peering Policies, and a US Map with Peering locations mapped out. They spoke about their network, their peering policy, what they look for in a peer and why others should want to peer with them. The following people participated in the Peering Personals: (I note below a couple remarkable points brought up during their 2 minutes...) Company AS Number First Name Last Name -------------- ----------------- ---------------- ---------------- Akamai 12222 Patrick Gilmore Broadwing 6395 Allison Feese Carpathia Hosting, Inc. 29748 Scott Bethke CENIC 2150++ Dave Reese CET Networks 22934 Dennis Nugent - 4Gbps of traffic, little peering (yet) FLAG Telecom, Ltd. 15412 Nigel Titley Global Crossing 3549 Maurice Dean Japan Telecom America 4725 Amir Arif - 3.5Gbps to the U.S. JENS Co. 2915, 4682 Daizo Tomigahara New Edge Networks 19029 Cathy Chen - DSL in many tier 2 cities Packet Clearing House 3856, 42 Steve Gibbard ServePath 26228 Steve Gibbard SingAREN 7610 Steve Gibbard TDS Telecom 4181 Chris Malayter TeleGlobe 6453, 8297 Sylvie LaPerriere - very strict peering policy, 300Mbps, US, Asia, Europe, 24x7 NOC, <2:1 ratio UPC 6830 Frank Hellemink - 10 countries, 14Gbps traffic, 65% peering today Los Nettos 226 Celeste Anderson Walmart.com 17374 Will Campbell Yahoo 5779, 10310 Brokaw Price - Brokaw contested the operational load argument from the debate; - they have over 600 peering sessions and the load is mostly virtual - they are saving "in the seven figures" annually by peering Microsoft 8068, 8075 Doug Wilson - Doug had a good sense of humor (I flashed the BSOD 25 seconds in ;-) ) Aleron 4200 Ryan McClune - requires multiple locations across the U.S. AARNet 7575+ Mark Prior China Telecom 4134 xiaoyi liu - 11 Gbps between US & China - 80% traffic in China is China Telecom Cable & Wireless 1273 Christian Kaufmann - (PLC) in U.S. will have a more open peering policy Adelphia Communications Corporation 18756, 19548 Dean Deback - 10 Gbps in, 6Gbps out - ~ 40% peer2peer (see slides) SoftbankBB 17676 Masato YAMANISHI - not peering in U.S. yet, 48Gbps ingress in Japan, 24Gbps outbound - 10G peering Google, Inc. 15169 Paul Nguyen UltraDNS 12008 Rodney Joffe - 12Gbps of traffic There were a lot of people on this list with "Pulse Peering Policies"; if you have a pulse, we will peer with you. (The previous name for this policy was replaced.) I produced a matrix showing those with open policies that were colocated at the same IXes, and there were a lot of green squares indicating that peering could/should/maybe already does occur between these companies. All in all I thought it was a useful and interesting Peering BOF. We ran over by about 20 minutes due to the late addition of Peter's C&W talk, and a couple Peering Personals that were past the cut off date but too important for this group to pass up. Both of these however represent significant changes in the U.S. Peering Ecosystem that they were worth the time. Comments welcome - Bill // // William B. Norton <wbn(a)equinix.com> +1.650.315.8635 // Co-Founder and Chief Technical Liaison Equinix, Inc. //

1 0

RE: SMTP authentication for broadband providers
by Dan Ellis 12 Feb '04

12 Feb '04

First, a quick thanks to everyone that responded. I've received useful and excellent info from everyone. We do not block on 25 outbound/inbound, but we are considering it for the residential broadband connections - maybe filter, proxy, or at least monitor it. I should clarify one thing: We are considering REQUIRING SMTPAUTH for all connections from customers for relaying - whether they are on our IP space or not. I know this will only buy us a few months until the next round of viruses steal username/pass, but even then it will give us the ability to detect an infected/SPAMMING customer quicker and auto shut them down (vs having to shutdown the IP, and then the customer receives a new IP...) My question is: Have any or many of the larger ISP's gone the route of REQUIRING all customers to use SMTPAUTH - regardless of where they are connected. Can anyone disclose who these regional or national providers are? Thanks again --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 > -----Original Message----- > From: Florian Weimer [mailto:fw@deneb.enyo.de] > Sent: Thursday, February 12, 2004 2:01 AM > To: Dan Ellis > Cc: nanog(a)merit.edu > Subject: Re: SMTP authentication for broadband providers > > Dan Ellis wrote: > > > We're a medium sized regional MSO/broadband provider with 200k+ > > mailboxes, strongly considering enabling SMTP authentication on our > > customer-facing SMTP mail servers. We feel this is the next logical > > step to minimize our users UCE/virus impact (we already tarpit, virus > > scan, UCE scan, subscribe to RBL's, reject prior to SMTP close). > > Do you block incoming 25/TCP connections from customers? Some of your > hosts are listed on my mass-market IP access blacklist, so you probably > don't. 8-) > > IMHO, this is one of the next thing to consider if you want to reduce > the volume of unwanted email originating from your network. There's an > intermediate step: monitoring TCP/25 flows. The initial setup costs are > much lower, but the operating costs are higher and the effect is less > thorough. > > > Is anyone aware of any well known mail clients that do not support SMTP > > authentication (Unix, Windows or Mac)? > > qmail (as usual).

2 1

New subgroups in the IRTF ASRG
by John R Levine 12 Feb '04

12 Feb '04

The newly reorganizaed Anti-Spam Research Group has set up some new subgroups to see if we can get some work done. Our slant is sort of applied research; it's stuff that's not ready for the standards track yet, but isn't blue sky. Several of the groups have a lot of operational relevance, notably abuse reporting standards, BCP, filtering standards (eg, ways to pass around updated filtering info in real time), and the two verify groups. Each of these has a mailing list you can read at gmane.org. If interested in participating, drop me a note with a sentence or two describing your interest and I'll pass it along to the appropriate subgroup head. The list of the subgroups is as follows (http://asrg.sp.am/about/subgroups.shtml) ------------------------------------------------------------------------ o Abuse Reporting Standards - researches standard formats and protocols for reporting email and network abuse Homepage: http://asrg.sp.am/subgroups/abuse_reports.shtml) o Analysis & Characterization (A&C) - applies empirical and quantitative methods to problems and issues surrounding spam Homepage: http://asrg.sp.am/subgroups/analysis.shtml o Best Current Practices (BCP) - researches and documents best practices for spam management Homepage: http://asrg.sp.am/subgroups/bcp.shtml o Filtering Standards (FILTERING) - researches filtering standards for dynamic updating and interaction with MTAs Homepage: http://asrg.sp.am/subgroups/filtering.shtml o Inventory of Problems - research problems with the current email architechture that facilitate spam http://asrg.sp.am/subgroups/problems.shtml o Message Verification (MSG-VERIFY) - researches solutions dealing with verification and authetication in the email messages and headers http://asrg.sp.am/subgroups/msg_verify.shtml o SMTP Session Verification (SMTP-VERIFY) - researches solutions dealing with authetication and verification of the SMTP session (will encompass the old LMAP and CRI subgroups) http://asrg.sp.am/subgroups/smtp_verify.shtml Regards, John Levine, johnl(a)taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com

1 0

Re: SMTP authentication for broadband providers
by Michael.Dillon＠radianz.com 12 Feb '04

12 Feb '04

>Right now SMTP AUTH is a bit more useful because the mailer can directly >identify the compromised subscriber. But I expect this to also be >short-lived. Eventually the compromised computers will start passing >authentication information. SMTP AUTH and 587 might not be silver bullets but they can shift the action into an arena where we can use bigger clubs to beat the spammers. Right now, if someone sends SPAM they are not breaking the law. However, if someone compromises another person's computer, steals their authentication credentials, transfers those credentials to another compromised computer and then sends SPAM, they are clearly breaking the law. They are also doing something that banks, credit card companies and law enforcement agencies are very interested in tracking down, namely the theft and transfer of authentication credentials. And if we get to the point where people can rightly claim that 94.7% of SPAM is the direct result of security flaws in Microsoft operating systems, then there is another big club in the form of the FTC and class action suits that can be applied to the problem. --Michael Dillon

1 0

Re: IPv6 reverse lookup - lame delegation?
by Paul Vixie 12 Feb '04

12 Feb '04

> > or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> into effect. > > I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)? A6 and bitstring labels are deprecated. DNAME remains in full force.

4 6