- Test - lists.nanog.org

Analogies=dead threads (was RE:Open, anonymous services and dealing with abuse)
by Rainer Atkins 18 Feb '04

18 Feb '04

Is it just me, or is it a clear indication that a thread is ending its useful life is when people start debating the merits of the analogies that have been posed rather than the original subject matter of the thread? Or, maybe a thread is exhausted when the analogies start to crop up. _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx

4 3

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

18 Feb '04

> 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. We, as network operators don't need to attack spam. We need to ignore spam itself and get to work securing the network that enables spammers to do their dirty work. > 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. I wouldn't go quite so far as that. Yes, broad consensus of the network operator community would help us to secure the architecture of the email system. That's why I have suggested that large email operators should be meeting regularly in a forum where they can discuss and agree upon *BEST PRACTICES*. But it also helps for people to implement best practices in a piecemeal fashion because that provides the real-world operational experience to prove that a particular practice is feasible. >From recent conversations on the list it appears that the BCPs for email include using the submission protocol for all end-user sending of email. But I would like to see this go a step further and require SMTP AUTH for every single SMTP session on port 25 as well. That means that AOL's mailservers would have to authenticate their sessions on Hotmail's servers before sending email and vice versa. It means that you cannot operate a mailserver without having a bilateral agreement in place with some set of email peers. It provides a chain of trust through those bilateral agreements that makes it easier to block SPAM and catch spammers. Yes, this probably means that we need to have some DNS related changes so that a domain can publish a list of their email peers and so that MTA software can figure out where to forward a particular email to reach its destination. But none of this is rocket science. And all of it could be accomplished by sitting the major email operators around a table to hash it out. NANOG could help here by devoting the next meeting to the various technical operational email issues and by extending to an additional day for the email operators forum. There is plenty of BCP material that could be presented and even though some of the operators like AOL have presented this in the past, an update would be useful to a lot of us. --Michael Dillon

15 19

NTIA/DoC public comment period
by Tony Hain 18 Feb '04

18 Feb '04

As I mentioned yesterday, the DoC is looking for public comment on IPv6. http://www.ntia.doc.gov/reports.html Specifically toward the end they ask: In some instances, government has responded to concerns over potential "chicken and egg" problems by playing an active role in the introduction of certain products and services, such as FM radio and HDTV. We request comment on how the deployment of IPv6 compares to other standards-based technology transitions and whether IPv6 presents the same or similar concerns that warrant government action. If you have opinions, be sure to send them by March 8. Tony

3 3

RE: Clueless service restrictions (was RE: Anti-spam System Idea)
by Chen, Weijing 17 Feb '04

17 Feb '04

You are right. End station (PC) is SCP-equivalent in packet world. Will Internet community allow or push for it? How to manage credentials, etc...? Pain and more pain... -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Tuesday, February 17, 2004 4:21 PM To: Chen, Weijing; nanog(a)merit.edu Cc: Alex Bligh Subject: RE: Clueless service restrictions (was RE: Anti-spam System Idea) --On 17 February 2004 16:10 -0600 "Chen, Weijing" <Weijing_Chen(a)labs.sbc.com> wrote: > Sound like an any to any end to end signaling/control mechanism with > authentication capabilities. Smell fishy (packet version of dial tone?) Since when had dialtone got end-to-end signalling/control? My POTS line doesn't run C7/SS7. I mean authentication as in scp (and not tftp). IE one end user authorizes the other end user, using whatever credentials they like. Alex

1 0

RE: Clueless service restrictions (was RE: Anti-spam System Idea)
by Chen, Weijing 17 Feb '04

17 Feb '04

Sound like an any to any end to end signaling/control mechanism with authentication capabilities. Smell fishy (packet version of dial tone?) -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Tuesday, February 17, 2004 3:48 PM To: Tony Hain; nanog(a)merit.edu Cc: Alex Bligh Subject: Re: Clueless service restrictions (was RE: Anti-spam System Idea) The real problem here is that there are TWO problems which interact. It is a specific case of the following general problem: * A desire for any to any end to end connectivity using the protocol concerned => filter free internet * No authentication scheme

2 1

Data center design ideas
by Michael.Dillon＠radianz.com 17 Feb '04

17 Feb '04

Someone was recently looking for tips on data center design. If you have a look at the following URL, they have a flash presentation with an overview of their new $25 million data center including some building layout diagrams http://oneandone.co.uk/xml/static/hn_data_center --Michael Dillon

3 3

An alternate plan for reducing spam
by just me 17 Feb '04

17 Feb '04

http://www.wired.com/news/culture/0,1284,57760,00.html --mghali(a)snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

1 0

Commerce IPv6 RFC News
by Alfred Lee 17 Feb '04

17 Feb '04

I understand that the winter NANOG meeting had a panel session about IPv6 futures etc. I have been told by Doug Montgomery from NIST, who attended the session, that Tony Hain (from Cisco) pointed out that DoC has an RFC out on this topic and suggested that interested parties find the call and reply. The following announcement provides links to the Commerce IPv6 RFC for interested parties who may wish to participate. The U.S. Department of Commerce has formed an IPv6 Task Force to study deployment issues. The Task Force has published an RFC (Request for Comments) in the January 21, 2004 Federal Register, inviting interested parties to comment on a variety of IPv6-related issues. We have also posted the RFC on our website, at http://www.ntia.doc.gov/ntiahome/frnotices/2004/IPv6RFCFinal.htm, along with a press announcement at http://www.ntia.doc.gov/ntiahome/press/2004/IPv6_01152004.htm. Our comment deadline is March 8, 2004. We hope that you and your affiliated organizations will comment in our proceeding and look forward to your help in building a solid public record for our IPv6 study. Please contact me if you have questions. Alfred Lee Senior Advisor Office of Policy Analysis and Development National Telecommunications & Information Administration U.S. Department of Commerce Suite H4725 Washington, D.C. 20230 Phone: 202 482 1880 alee(a)ntia.doc.gov

1 0

Meeting stats from Miami
by Susan Harris 17 Feb '04

17 Feb '04

Greetings - here's some information about the last NANOG meeting (and thanks to Bob Stovall, Jason Russell, and Carol Wadsworth of Merit for gathering the stats): ====================================================================== NANOG 30 Feb. 8-10, 2004 Miami, Florida Host: Terremark Total Attendees: 488 (down from 529 at NANOG29) Speakers: 51 (3 panels) Tutorials: 4 Countries represented: 17 Peak data transmission from hotel 8.3M Peak data transmission to hotel 10.5M Wireless card loans: 26 Typical # of ethernet users: 28 Largest simultaneous # of wireless users: 335 Concurrent RealMedia viewers: up to 112 Meeting coordination: Merit Squid, DNS, DHCP: Measurement Factory Multicast/IPv6 feed: Florida International University Multicast/IPv6 equipment: Internet2 Sponsors: Arbor, Cariden, Cisco, Force10, Juniper, OPNET, Packet Design Procket, QoSmetrics, Riverstone, Switch and Data

1 0

RE: Anti-spam System Idea
by Lawrence Baldwin 16 Feb '04

16 Feb '04

> The problem is not as much actual open relays (which are now rare and almost universlly blocked) but open proxies We have come up with some terms to clarify types of open proxies: *Naturally occurring* open proxy/relay: System on which the owner has intentionally installed a mail or proxy server but has left it mis-configured such that anyone can relay through it. *Synthetic* open proxy/relay: System on which miscreant has dropped (through virus, worm, infected download, etc.) a mail or proxy server on owners system, thus enabling open relaying. By open, I mean *anyone* who discovers the ports the proxy is listening on can utilize it. *Synthetic* protected proxy/relay: Same as above, but proxy contains some sort of authentication mechanism limiting who can use the proxy...e.g. JUST the spammers....this obviously defeats open proxy testing. Others also refer to Synthetic proxies as "hijacked proxies" or "ProxyBots". Some other comments on this approach: First, I definitely agree that current RBL approaches to spam are not very effective due to the dynamic nature of Synthetic open proxies. Though I can't prove it, I suspect that as much as 90% of current spam is transmitted through such proxies...and that the majority of these proxies are installed on compromised consumer Internet connections (cable, dsl, and yes, dialup!). Current RBLs DO discover all types of proxies, however, it a matter of how much time elapses between when a given IP begins to relay spam and when it is detected and blacklisted. I suspect that the current detection delay is measured in at least HOURS and perhaps even DAYS. Furthermore, many consumer connections utilize dynamic IPs (e.g. DHCP, PPPoE, and PPP )...I suspect that sometimes an infected system has changed IP addresses several times before the first IP that relayed spam from is even listed! And don't discount dialup connections, 28.8Kbps is plenty of bandwidth to spam through when you have 10,000 of such systems in your ProxyBot army...and the fact that the relay's IP will change after each dialup connection means you'll never be RBLed for very long. DHCP, though technically dynamic addressing is far less of a problem as IP address do NOT typically change very often...remember DHCP leases are renewed automatically by the client when the lease is 50% to expiration. Many DHCP clients also cache their previously leased IP (e.g. Windows) and explicitly request the same IP even across lease expirations...depending on the service provider, DHCP clients often maintain the same IP for months at a time (aka "sticky IP"). Some PPPoE gateways also maintain username to IP caches so sticky IPs can also result in that scenario as well. I agree that strategy of not accepting mail from a given IP until it has been open proxy tested would likely be effective in stopping proxy spam. Unfortunately this approach is also highly irresponsible...and spammers would quickly migrate the proxy approach to defeat open proxy testing. In order for such scanning to be effective you would need to perform two stages scans against 65,000 ports (if you limit to TCP only). First you have to find all open ports (65,000 probes * 3 for retries), then you'd need to do at least a HTTP, SOCKS V4 and SOCKS V5 (65,000 * 3 types * 3 for retries =585000 probes) proxy test against each of those ports. That's about 13MB of traffic just for the TCP scanning phase. Although a lot of the scanning would be directed at consumer Internet users (who probably wouldn't even notice), a significant amount would be directed at bona-fide mail servers. The administrators of the latter will likely NOT appreciate this and they WILL complain. Frankly, I think the complaints are justified...if someone did that level of scanning into my network (on a daily basis no less) I'd be obligated to investigate, potentially wasting hours of time until I find out the intent behind it. Despite the activity having good intentions, bottom line is has wasted my time...now multiply that time by the 1000s of network and security administrators that would do the same. Even if such an approach was initially effective it would ultimately fail. Spammers would simply migrate to authenticated proxies, proxying via UDP (which can almost impossible to scan for), or proxying using custom protocols thus defeating SOCKS and HTTP relaying tests. Personally, I think the better approach to fighting proxy spam is to identify the spammers that are *upstream* from the proxies and then get one or more of them thrown in jail, not for spamming, but for violating federal or state computer intrusion laws. Spammers are currently using open proxies because they are free and anonomous, until you make them non-anonomous AND costly (jail) there's nothing will stop them. This is not as hard as it sounds...if you are an ISP you have hijacked proxies on your network. The RBLs can tell you which IPs are hijacked proxies, all you need do is capture Netflow data and examine the upstream IPs pummeling the hijacked proxy on it's SOCKS and/or HTTP proxy port. The results of such analysis is extremely enlightening...these spammers have NOT moved off-shore, they are NOT using multiple levels of proxy chaining and obfuscation, they are spamming DIRECTLY from their web hosting and corporate offices in North America, and as is often the case, South Florida. The other approach is to identify the "master" servers that are controlling these ProxyBot networks (most hijacked proxies "call home" to the master to report their IP and current proxy port info). In the last few months I have reverse-engineered several proxyBots and identified quite a few master servers....some hosted at US-based web hosting companies. If you take out a master server, you take out 1000s or 10s of 1000s of proxies. What amazes me is that master servers that I identified back in Oct 2003 are STILL operational today. This suggests to me that almost no one is pursuing this approach. I suspect the problem is one of a lack of coordination within service provider organizations. They all want to stop spam, but they seem more focused on preventing it from coming in vs. stopping it from going out from their own customers. Sorry, but if you can't even stop it from being sent from you own subscribers you're not going to find any solutions to the more difficult problem of blocking inbound spam. An effective fight requires a combination of Netflow data (from network engineering/ops), spam complaints (from Abuse dept), spam proxy code (from customers system), and forensic examination (by security researchers or in-house security teams). Apply this approach across several large SP networks and I guarantee it will become clear where the majority of spam is really being transmitted from... Regards, Lawrence Baldwin Chief Forensics Officer myNetWatchman.com Atlanta, GA +1.678.624.0924

2 1