June 2008 - Test - lists.nanog.org

Re: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]
by Ken Simpson 24 Jun '08

24 Jun '08

> On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME <frnkblk at > iname.com> wrote: > > Is there a vendor that makes a product that perform spam/malware > filtering > > literally in the network, i.e. as a service provider, can I > provide spam > > filtering for the enterprises in my customer base by adding a > piece of > > network gear? I'm not aware of one today except those who provide > > enterprise-oriented gateways like SonicWall. > > Symantec Mail Security / Turntide > Mailchannels Traffic Control > > --srs BTW, we CAN do "in the cloud" email traffic shaping - on EC2, ironically. But also on your own equipment if that's your preference. Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel

3 5

APNIC dns glitch ?
by Danny Thomas 24 Jun '08

24 Jun '08

I thought I'd sent this a couple of hours ago APNIC are aware of the problem and things have partially recovered though the arin and ripe name-servers still SERVFAIL the second run of our delegation-checking script this morning started complaining about our 203.in-addr zones and it seems there is an issue with apnic.net the delegation shows 4 entries spread across 3 domains which is good, albeit all are under the same registry. Sometimes cumin.apnic.net and innie.apnic.net. are not reachable, or give a REFUSED response, or give a response with no A records nor any additional section. Unfortunately both tinnie.arin.net and ns-sec.ripe.net return SERVFAIL, as if they had not been able to perform a zone transfer for a while (assuming AXFR is the replication mechanism). I don't have ipv6 connectivity, but that's not likely to help. I don't think this will significantly impact reverse dns lookups as I think the dns is spread across other RIR's seems there was a different type of issue in May http://www.bauani.org/thinkings/2008/05/issue-with-apnic-dns-nameservers.ht… Danny Thomas # dig @I.GTLD-SERVERS.net apnic.net +norec ; <<>> DiG 9.4.2 <<>> @I.GTLD-SERVERS.net apnic.net +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5460 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;apnic.net. IN A ;; AUTHORITY SECTION: apnic.net. 172800 IN NS cumin.apnic.net. apnic.net. 172800 IN NS ns-sec.ripe.net. apnic.net. 172800 IN NS tinnie.apnic.net. apnic.net. 172800 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: cumin.apnic.net. 172800 IN A 202.12.29.59 ns-sec.ripe.net. 172800 IN A 193.0.0.196 ns-sec.ripe.net. 172800 IN AAAA 2001:610:240:0:53::4 tinnie.apnic.net. 172800 IN A 202.12.29.60 tinnie.arin.net. 172800 IN A 168.143.101.18 dig @202.12.29.59 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33930 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 # dig @202.12.29.59 apnic.net any ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40744 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN ANY ;; ANSWER SECTION: apnic.net. 3600 IN SOA cumin.apnic.net. dns-admin.apnic.net. 2008062101 3600 1800 604800 3600 apnic.net. 3600 IN NS cumin.apnic.net. apnic.net. 3600 IN NS ns-sec.ripe.net. apnic.net. 3600 IN NS tinnie.arin.net. apnic.net. 3600 IN NS tinnie.apnic.net. apnic.net. 3600 IN MX 10 kombu.apnic.net. apnic.net. 3600 IN MX 25 karashi.apnic.net. apnic.net. 3600 IN MX 35 fennel.apnic.net. ;; Query time: 3 msec ;; SERVER: 202.12.29.59#53(202.12.29.59) ;; WHEN: Tue Jun 24 10:35:13 2008 ;; MSG SIZE rcvd: 235 dig @193.0.0.196 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @193.0.0.196 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37668 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;apnic.net. IN ANY # dig @168.143.101.18 apnic.net ns ; <<>> DiG 9.4.2 <<>> @168.143.101.18 apnic.net ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41014 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN NS

2 1

Australian Co-Lo
by Bernard Becker 24 Jun '08

24 Jun '08

Looking for recommendations for carrier neutral co-lo facility for Melbourne Australia. Our searches so far seem to turn up sites either on Telstra or Optus affiliated co-lo facilities. We need to be in a carrier neutral space with access to any of the major providers. Searching for co-lo space in Australia from Toronto is somewhat challenging. Websites make lots of claims that can't be validated without going and seeing the place. Bernard Becker Senior Network Architect Filogix - A Davis & Henderson Company. Tel: 416-360-1777 x3341 Fax: 416-847-5816 Toll Free: 1-866-435-6165

5 4

Re: Cloud service [was: RE: EC2 and GAE means end of ip
by Joel M Snyder 24 Jun '08

24 Jun '08

> Date: Mon, 23 Jun 2008 20:47:17 -0700 > From: Joel Jaeggli <joelja(a)bogus.com> > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip > address reputation industry? (Re: Intrustion attempts from Amazon EC2 > IPs)] > To: frnkblk(a)iname.com > Cc: nanog(a)merit.edu > Message-ID: <48606E45.8000100(a)bogus.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > the argument in this thread however (which I more or less subcribe to) > is that in the future an ip address is insufficient granularity for mail > /badness filtering. Frankly it's not just computer clouds but also > address pressure, a million hosts behind a /24 are going to be rather > hard to pick out one at a time. ultimately the ability blackhole based > on something as gross as the source ip address is going to be > insufficiently fine grained for devices that must accept connections > from the internet at large. Ummm, probably not as big of a problem as you might think it is. From the point of view of an email administrator, those million hosts behind the /24 are all going to be on the Spamhaus PBL (policy block list) and it doesn't matter whether there are 10 or 10,000 or 10,000,000 hosts if the ISP has said "these are residential subscribers and they shouldn't be sending mail." Whether you believe in PBL or not, generally, it's going to be end users who are clustered behind those NATs more so than MTAs. Similarly, I don't see a huge incentive for someone to move their MTA to services like EC2--although anti-spam services 'in the cloud' like Postini are very popular, but that's a different issue. In our month-by-month anti-spam testing over the past 3 years, the number of unique email senders (MTAs, not individuals mind you) has actually dropped a bit; if you use the domain name as exposed in HELO/EHLO, it's dropped even more. While there will always be small MTAs out there handling small numbers of people, the trend has been to throttle that mail through larger systems. Sometimes this is done transparently/semi-transparently by the ISP ("you will send your mail through our SMTP server") using either a simple port 25 block or something like transparent destination NAT/WCCP. In other cases, this happens because small companies are discovering that their oh-so-exciting Exchange server is more of a pain in the ass than using commercial Gmail or whatever. SMTP is a special case in this discussion, I'll immediately admit. The number of hosts offering up web pages (assuming you want to filter for malware of some sort) is going nothing but up. Reputation services will be more challenged in that environment than in the SMTP environment. > >> I don't know if spammers are going to be using TLS in a big way soon, though >> I'll admit I've not measured. > > A couple years ago, when my former employer turned on tls support on the > outwardly facing mta's about 10% of our incoming smtp connections > immediately started using it after ehlo. That's not something I've kept > track of but I imagine it's an issue. Today's number for delivery using SSL by our mail cluster is 7% of just shy of 80K messages. Goes up, goes down, but definitely non-zero. > >> As long TLS usage is low, examining TCP port >> 25 traffic would likely be effective without redirecting SMTP traffic and >> making it effective for all customers downstream. That actually turns out to be a non-problem from the SMTP point of view. A "mean" ISP could simply intercept the response to EHLO and drop out the TLS capability string. A "nice" ISP could simply make up a certificate on the fly. Since SMTP senders don't have a GUI box to click during the SMTP transaction when a certificate doesn't check out, most (read as: all configured with default settings) of them simply send anyway even if the certificate smells like week-old fish. Put it another way: I ran (accidentally) for two years with an expired certificate on one of our mail servers and didn't get a single peep about misbehaving mail. But most of this discussion has been about reputation services, and of course those operate beautifully with or without TLS in the SMTP case. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

1 0

Happy 25th birthday for DNS
by Hank Nussbacher 23 Jun '08

23 Jun '08

http://www.wired.com/science/discoveries/news/2008/06/dayintech_0623 June 23, 1983: DNS Test Sets Stage for Internet Growth 1983: Paul Mockapetris and Jon Postel run the first successful test of the automated, distributed Domain Name System. DNS will lay the foundation for the massive expansion, popularization and commercialization of the internet. ... Thanks Paul & Jon! -Hank

1 0

smstools and CDMA
by Douglas K. Rand 23 Jun '08

23 Jun '08

From the GMS point of view I live and work in the boondocks: Grand Forks, North Dakota. (OK, so there is a decent argument that the entire US is GSM boondocks.) Anyway, I'm trying to figure out a way of sending and receiving text messages using a tool like smstools and a CDMA modem. I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't seem to find any success stories to go along with it. I was wondering if anybody has had any luck with either this modem and smstools3 in particular, or with sending/receiving text messages with a CDMA modem.

6 10

Spamcop
by Mehmet Akcin 23 Jun '08

23 Jun '08

Hi If there are some members of Spamcop here, please contact me off-list Mehmet

1 0

Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)
by Laird Popkin 23 Jun '08

23 Jun '08

Normal hosting facilities let you do pretty much anything you want, unless you start causing problems for the ISP or their customers. You pay them to provide bandwidth, space, power and cooling. There are more restrictions for shared virtual sites (i.e. the $10/month web sites). Usually they just let you upload PHP and HTML pages and access a MySQL database. But, as Brandon pointed out, even they usually let you do basic things in PHP such as sending email. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Brandon Galbraith" <brandon.galbraith(a)gmail.com> To: "Nathan Ward" <nanog(a)daork.net> Cc: "nanog" <nanog(a)merit.edu> Sent: Monday, June 23, 2008 1:45:03 AM (GMT-0500) America/New_York Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) On 6/23/08, Nathan Ward <nanog(a)daork.net> wrote: > > > Do 'normal' web hosting providers allow customer created scripts to create > TCP sessions out to arbitrary things? > Doesn't PHP provide a fair amount of TCP functionality that can be used simply by uploading the code you need to your shared web hosting account? -brandon

1 0

Best utilizing fat long pipes and large file transfer
by Sean Knox 22 Jun '08

22 Jun '08

Hi, I'm looking for input on the best practices for sending large files over a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). I'd like to avoid modifying TCP windows and options on end hosts where possible (I have a lot of them). I've seen products that work as "transfer stations" using "reliable UDP" to get around the windowing problem. I'm thinking of setting up servers with optimized TCP settings to push big files around data centers but I'm curious to know how others deal with LFN+large transfers. thanks, Sean

28 40

Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST
by ekagan＠axsne.com 21 Jun '08

21 Jun '08

FYI In case someone can get this to a clue-ful individual. There was been severe packet loss at Hop 11 below since 11AM EST this morning leaving Comcast Mass network out through Level 3 NY/Boston. I tried to report to Comcast (Request Summary: ID: 6863600) and was met with less than pleasant clue. So much for being a good net'izen. I agreed my "connection" was fine, but past that there was an issue. If there is actually a way to report to Comcast NOC, please advise. I've also reported to Internap from my side so they can investigate as well. Thanks Eric Packets Pings Hostname %Loss Rcv Snt Last Best Avg Worst 1. 192.168.100.5 0% 47 47 0 0 0 1 2. c-3-0-ubr04.brockton.ma.boston.comcast.net 0% 47 47 7 6 8 16 3. ge-2-40-ur01.brockton.ma.boston.comcast.net 0% 47 47 7 6 8 13 4. 68.85.162.73 0% 47 47 10 8 10 16 5. 68.85.162.58 0% 47 47 15 11 13 32 6. 68.85.162.57 0% 47 47 14 11 13 19 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net 0% 46 46 46 45 46 53 8. xe-11-1-0.edge1.NewYork2.Level3.net 0% 46 46 45 44 52 175 9. vlan69.csw1.NewYork1.Level3.net 0% 46 46 52 44 52 60 10. ae-61-61.ebr1.NewYork1.Level3.net 0% 46 46 45 45 51 60 11. ae-1-8.bar2.Boston1.Level3.net 50% 23 46 51 49 54 104 12. ae-0-11.bar1.Boston1.Level3.net 0% 46 46 118 49 58 174 13. ae-7-7.car1.Boston1.Level3.net 0% 46 46 50 49 52 67 14. 63.211.175.26 0% 46 46 53 49 60 215 15. border7.ge6-2-bbnet2.bsn.pnap.net 0% 46 46 154 50 60 187 16. host-4-64-203-66.axsne.net 0% 46 46 52 51 54 93 Packets: Sent = 240, Received = 230, Lost = 10 (4% loss), Packets: Sent = 54, Received = 49, Lost = 5 (9% loss), Minimum = 54ms, Maximum = 227ms, Average = 62ms Eric Kagan Access Northeast 24 x 7 NOC: 508-281-7600 x4

3 4