From jra at baylink.com Sat Oct 1 09:14:24 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 1 Oct 2011 10:14:24 -0400 (EDT) Subject: FCC - with Klezmer backup In-Reply-To: <20110930195346.GD1468@vacation.karoshi.com.> Message-ID: <22164011.3734.1317478464359.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: bmanning at vacation.karoshi.com > http://gcn.com/articles/2011/09/26/fcc-net-neutrality-rules-nov-20.aspx > > wondering who is going to publically announce any changes prior to the > 20nov date. > > Or is this a non-issue for the Internet as we know it? This guy, who seems to have 'is feces all assembled, thinks that it will just be a game of T-ball: everyone has fun, no one gets hurt: http://www.telecomramblings.com/2011/09/net-neutrality-t-ball/ He also notes that L3/GBLX was approved, in a more recent post. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From lists at foks.se Sat Oct 1 09:24:40 2011 From: lists at foks.se (foks) Date: Sat, 01 Oct 2011 16:24:40 +0200 Subject: Mails to Google being blocked for illegal attachments In-Reply-To: References: <20110930111947.5A677F2D5905D@bmail04.one.com> Message-ID: <20111001142440.AF8D91B5C5436@bmail03.one.com> On Sep 30, 2011 13:34 "Alex Brooks" wrote: > On Fri, Sep 30, 2011 at 12:19 PM, foks > > wrote: > > > > Hello, > > > > Since Sep 7 Google has bounced a specific type of our mails with > > this > > message: > > > > host aspmx.l.google.com[74.125.43.27] said: 552-5.7.0 Our system > > detected an illegal attachment on your message. Please 552-5.7.0 > > visit > > to 552 > > 5.7.0 > > review our attachment guidelines. z4si211085bkd.116 (in reply to end > > of > > DATA command) > > > > The only attachment is a gif image so it seems that Googles check is > > wrong. Has anyone experienced this issue, or has any helpful contact > > information to Google? I have checked > > > rt.ht> > > ml and called these numbers, but they were not able to help me. > > Hi, > > Have you reported it through their support pages? The one you're > after is probably: > ers&group=bugflow_attachmentsnewbug&trouble_type=attachments> > > Generally, checking > > is > the first place to go with GMail issues if you're not an Apps > customer; they have a link to reporting problems at the bottom. > Though if you're not an Apps customer (or can't find one to report the > issue on your behalf as not receiving e-mails from you), I wouldn't > hold out too much hope for a response from it. > > Do let us know how you solve the problem in the end. > > Alex > Hi, Thank you for reply. I have reported it there yesterday. No response yet. I also tried to send the same mail without the attached gif image, so it seems to be something else that triggers the error message. /J?rgen From jvanoppen at spectrumnet.us Sat Oct 1 10:24:31 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Sat, 1 Oct 2011 15:24:31 +0000 Subject: facebook spying on us? In-Reply-To: <4E864752.2030105@bogus.com> References: <4E863EE6.9000207@bogus.com> ,<4E864752.2030105@bogus.com> Message-ID: That comment about wholesale prices is not actually quite true here in the northwest where avoiding BPA actually sometimes results in cheaper power (ie grant, douglas and chelan counties whoes PUDs own their own dams and are obligated to service their customer and as non-profits actually sell to retail users at near the wholesale grid rates since they have nearly zero cost). Because pacificorp is a private utility they are actually only able to get the leftovers of the hydro from the northwest, BPA must sell to public utilities first (even if it is LA) so there are effectively two prices here in the northwest for wholesale and that is why pacificorp, portland general and puget sound energy all have far far higher rates than the public utilities, even the public utilities with no generation of their own. I was pretty surprised about facebook's choice as well, almost an identical climate can be found along the columbia river in the same places that the very cheapest power is located. They must have some other factors than just weather significantly contribute to the costs to justify not going for the cheapest power. John ________________________________________ From: Joel jaeggli [joelja at bogus.com] Sent: Friday, September 30, 2011 3:48 PM To: Steven G. Huter Cc: nanog at nanog.org Subject: Re: facebook spying on us? On 9/30/11 15:19 , Steven G. Huter wrote: >>> I can't tell you the kind of servers, but I can say that I was >>> recently in Prineville, OR, where FB is building a data center (and a >>> second data center). I was used to the ol data centers - you know, >>> where there's raised floors, cabinets, cool air, a guard and a few >>> guys around with some screens? >>> >>> But this was massive. I was amazed at the size - a few city blocks >>> long and a city block wide, with a transformer and power line the >>> size of a small city. I wonder if the Feds were involved. >> >> the bonneville power administration. > > hey joelja > > this August 2011 article in the Economist outlines some relevant info > about the prineville, oregon FB datacenter. > > http://www.economist.com/node/21525237 ambient cooling is important just like power is important, by sonic.net gets ~240days of ambient in santa rosa so it's feasible wholesale market prices a driven by availability from the largest producer. so you'll pay market price as benchmarked at the bonnevilla transmission yard just as is much of california and az the refence price is at palo verde az. there's only one coal plan in oregon and it's 600MW of generating capacity in boardman that's portland general electric. we've got a 20MW interuptable contract with siliconvalley power precisely becuase it's vanishingly close to the wholesale rate compared to PGEs pricing structure so if you ever wonder why the DCs are in sunnyvale and santa clara but not mountainview, there's a good reason. > steve > From simon.leinen at switch.ch Sat Oct 1 14:36:18 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 01 Oct 2011 21:36:18 +0200 Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header In-Reply-To: <4E85DF11.1030905@foobar.org> (Nick Hilliard's message of "Fri, 30 Sep 2011 16:24:01 +0100") References: <20110930100257.GA30922@pob.ytti.fi> <20110930142639.GA30986@pob.ytti.fi> <4E85DF11.1030905@foobar.org> Message-ID: > which traceroute? icmp? udp? tcp? Traceroute is not a single protocol. Router processing is only dependent on noticing that TTL is expiring, and being able to return an ICMP message (including a "quote" of part of the original packet) to the sender. >> what is that limit? from a single port? from a single linecard? from a >> chassis? how about we remove complexity here and just deal with this >> in the fastpath? > on a pfc3, the mls rate limiters deal with handling all punts from the > chassis to the RP. It's difficult to handle this in any other way. If the rate limit is done "in hardware" (which one should hope), then it would be more natural to do it on a per-PFC/DFC basis. So on a box with DFCs on all linecards, it would be per linecard, not per chassis. Maybe someone who knows for sure can decide. >> My point in calling this all 'stupid' is that by now we all have been >> burned by this sort of behavior, vendors have heard from all of us >> that 'this is really not a good answer', enough is enough please stop >> doing this. > "This is a Hard Problem". There is a balance to be drawn between > hardware complexity, cost and lifecycle. In the case of the PFC3, > we're talking about hardware which was released in 2000 - 11 years > ago. Um, no, in 2000 there was no PFC3. That came out (on the Supervisor 720) in March 2003. > The ipv6 fragment punting problem was fixed in the pfc3c, which was > released in 2003. The PFC 3C was announced (with the RSP720) in December 2006. > I'm aware that cisco is still selling the pfc3b, but they really only > push the rsp720 for internet stuff (if they're pushing the 6500/7600 > line at all). See Janos' reply, the Catalyst 6500 seems alive and kicking with the Supervisor 2T. The 7600 is a somewhat different story. As far as I see, all development is going into feature-rich ES+ cards and a few relatively narrow applications such as mobile backhaul and FTTH aggregation(?). We have been using the 7600 as a cheap fast IPv4/IPv6 (and later also MPLS) backbone router. According to Cisco we should probably move "up" to the ASR9000 or CRS-3, but I'm tempted to "downgrade" to Catalyst 6500 with Sup-2T (until we need 100G :-). -- Simon. From mysidia at gmail.com Sat Oct 1 15:56:39 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 1 Oct 2011 15:56:39 -0500 Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header In-Reply-To: References: Message-ID: On Fri, Sep 30, 2011 at 12:55 AM, Christopher Morrow wrote: > On Fri, Sep 30, 2011 at 1:07 AM, Mikael Abrahamsson wrote: > when will vendors learn that punting to the RE/RP/smarts for packets > in the fastpath is ... not just 'unwise' but wholesale stupid? :( Yeah, that's a nice one, thanks. At this point, I would have to describe it as ludicrous product engineering. Unless we're talking about small-business CPE devices, or true beasts with RPs capable of actually handling the load at wire speed. It goes beyond 'stupid' and well into the range of unreasonably insane UI design. Are cars designed to automatically slow to a stop when you turn on the radio if you forget to push a "don't let the radio interfere with my engine" button? The default/convention on real routers should be: Never punt a packet to RP for ACL processing. If someone asks to establish an ACL for a type of traffic would be subject to that, the request should generate an error. Or it should warn the user "% ACL Processing for this command will not be performed on fragments, unless you enable software ACL processing of IPv6 fragments using the blah blah blah command." And ask the human to manually turn on a " platform ipv6 acl fragment allow-software yes-i-am-really-really-sure " setting. -- -JH From morrowc.lists at gmail.com Sat Oct 1 16:39:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 1 Oct 2011 17:39:34 -0400 Subject: Mails to Google being blocked for illegal attachments In-Reply-To: <20111001142440.AF8D91B5C5436@bmail03.one.com> References: <20110930111947.5A677F2D5905D@bmail04.one.com> <20111001142440.AF8D91B5C5436@bmail03.one.com> Message-ID: On Sat, Oct 1, 2011 at 10:24 AM, foks wrote: > I also tried to send the same mail without the attached gif image, so it > seems to be something else that triggers the error message. So, to be clear, sending the message without the image attachment also bounced? From nicholas.hatch at gmail.com Sat Oct 1 17:54:24 2011 From: nicholas.hatch at gmail.com (nick hatch) Date: Sat, 1 Oct 2011 17:54:24 -0500 Subject: facebook spying on us? In-Reply-To: References: Message-ID: On Thu, Sep 29, 2011 at 8:13 AM, Glen Kent wrote: > I also wonder about the kind of servers facebook must be having to be > able to manage millions of TCP connections that must be terminating > there. > For what it's worth, with some kernel tuning you can maintain 500k - 1MM persistent connections on a mid-range Linux box. Providers of mobile push-notification services seem to be the ones most actively pushing these limits publicly. Urban Airship has posted some information on how they maintain 500k connections on EC2 m1.large instances: http://urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/ http://urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/ WhatsApp claim to be able to maintain 1MM connections on single machine, although details are thin: http://blog.whatsapp.com/index.php/2011/09/one-million/ http://news.ycombinator.com/item?id=3028547 (discussion) -n From jra at baylink.com Sun Oct 2 00:16:34 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 2 Oct 2011 01:16:34 -0400 (EDT) Subject: facebook spying on us? In-Reply-To: Message-ID: <14892840.3742.1317532594572.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Jones" > I can't tell you the kind of servers, but I can say that I was > recently in Prineville, OR, where FB is building a data center (and a > second data center). I was used to the ol data centers - you know, > where there's raised floors, cabinets, cool air, a guard and a few > guys around with some screens? Data Center Knowledge posted about 20 minutes of very poorly shot video of Prineville. They're Open Compute servers in 'triplet' racks. > But this was massive. I was amazed at the size - a few city blocks > long and a city block wide, with a transformer and power line the size > of a small city. I wonder if the Feds were involved. Their power supply (also open) runs across 2 legs of a 277/480 3-phase feed, which is usually what the substation supplies to your PDUs, which step it down further to 120/208. It also takes -48, and each pair of triplets has a 48V float string that will run the 180 servers for about 45 seconds. It's a nice setup. I plan to steal it. :-) (The substation input voltage is very often 13k2 to 13k8, though it can be even higher.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From simon.leinen at switch.ch Sun Oct 2 02:30:05 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 02 Oct 2011 09:30:05 +0200 Subject: facebook spying on us? In-Reply-To: <14892840.3742.1317532594572.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Sun, 2 Oct 2011 01:16:34 -0400 (EDT)") References: <14892840.3742.1317532594572.JavaMail.root@benjamin.baylink.com> Message-ID: > Data Center Knowledge posted about 20 minutes of very poorly shot > video of Prineville. They're Open Compute servers in 'triplet' racks. [...] > Their power supply (also open) runs across 2 legs of a 277/480 3-phase > feed, which is usually what the substation supplies to your PDUs, > which step it down further to 120/208. It also takes -48, and each > pair of triplets has a 48V float string that will run the 180 servers > for about 45 seconds. > It's a nice setup. I plan to steal it. :-) That's what they want you to do - check out the specs on http://opencompute.org/ -- Simon. From mike at mtcc.com Sun Oct 2 10:38:36 2011 From: mike at mtcc.com (Michael Thomas) Date: Sun, 02 Oct 2011 08:38:36 -0700 Subject: Facebook insecure by design In-Reply-To: <4E85865F.60700@gmail.com> References: <4E85865F.60700@gmail.com> Message-ID: <4E88857C.7040106@mtcc.com> William Allen Simpson wrote: > In accord with the recent thread, "facebook spying on us?" > > We should also worry about other spying on us. Without > some sort of rudimentary security, all that personally > identifiable information is exposed on our ISP networks, > over WiFi, etc. > > Facebook claims to be able to run over TLS connections. > Not so much (see attached picture). > > This wasn't an "app", this is the simple default content of a > page accessed after a Google search. > I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Mike From mysidia at gmail.com Sun Oct 2 11:36:20 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 2 Oct 2011 11:36:20 -0500 Subject: Facebook insecure by design In-Reply-To: <4E88857C.7040106@mtcc.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> Message-ID: On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: > I'm not sure why lack of TLS is considered to be problem with Facebook. > The man in the middle is the other side of the connection, tls or otherwise. That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to. Supporting TLS in their case is not good enough... they would need to force all connections to be over TLS, to achieve security against MITM. As soon as an app causes the end user to switch to a non-TLS connection, they are vulnerable. > > Mike -- -JH From william.allen.simpson at gmail.com Sun Oct 2 12:27:00 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 02 Oct 2011 13:27:00 -0400 Subject: Facebook insecure by design In-Reply-To: References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> Message-ID: <4E889EE4.7090600@gmail.com> On 10/2/11 12:36 PM, Jimmy Hess wrote: > On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: >> I'm not sure why lack of TLS is considered to be problem with Facebook. >> The man in the middle is the other side of the connection, tls or otherwise. > > That's where the X509 certificate comes in. A man in the middle > would not have the proper private key to impersonate the Facebook > server that the certificate was issued to. > My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true. From snabb at epipe.com Sun Oct 2 12:40:23 2011 From: snabb at epipe.com (Janne Snabb) Date: Sun, 2 Oct 2011 17:40:23 +0000 (UTC) Subject: F.ROOT-SERVERS.NET moved to Beijing? Message-ID: I happened to notice the following at three separate sites around the US and one site in Europe: $ dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT "pek2a.f.root-servers.org" and: $ dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT "pek2b.f.root-servers.org" After running a couple of traceroutes it appears that he.net has a route for F's anycast IPv6 address (2001:500:2f::f) towards Beijing. According to https://www.isc.org/community/f-root/sites the Beijing node should be a "Local Node" (without IPv6 but I suppose the list is not up to date). I believe this means that a lot of DNS queries from IPv6 enabled sites in US and other countries are going to Beijing. I wonder if this is intentional? Chinese government (CNNIC) seems to be in the path. All my sites seem to have he.net somewhere in the IPv6 connectivity path. I wonder if this is specific to he.net or more wide-spread routing anomaly? I have notified he.net NOC and F-root @ ISC. Best Regards, -- Janne Snabb / EPIPE Communications snabb at epipe.com - http://epipe.com/ From source_route at yahoo.com Sun Oct 2 12:59:10 2011 From: source_route at yahoo.com (Philip Lavine) Date: Sun, 2 Oct 2011 10:59:10 -0700 (PDT) Subject: Time Warner to centurylink/qwest Message-ID: <1317578350.64624.YahooMailNeo@web30806.mail.mud.yahoo.com> Can not reach Centurylink/qwest from time Warner. From mike at mtcc.com Sun Oct 2 13:01:41 2011 From: mike at mtcc.com (Michael Thomas) Date: Sun, 02 Oct 2011 11:01:41 -0700 Subject: Facebook insecure by design In-Reply-To: <4E889EE4.7090600@gmail.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <4E889EE4.7090600@gmail.com> Message-ID: <4E88A705.7030803@mtcc.com> William Allen Simpson wrote: > On 10/2/11 12:36 PM, Jimmy Hess wrote: >> On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: >>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>> The man in the middle is the other side of the connection, tls or >>> otherwise. >> >> That's where the X509 certificate comes in. A man in the middle >> would not have the proper private key to impersonate the Facebook >> server that the certificate was issued to. >> > My understanding of his statement is that Facebook itself is the MITM, > collecting all our personal information. Too true. Bingo. Mike From mysidia at gmail.com Sun Oct 2 14:03:19 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 2 Oct 2011 14:03:19 -0500 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: Message-ID: I see similar, intermittedly # dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT "pek2a.f.root-servers.org" # dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT "ord1b.f.root-servers.org" On Sun, Oct 2, 2011 at 12:40 PM, Janne Snabb wrote: > I happened to notice the following at three separate sites around > the US and one site in Europe: > > $ dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT > "pek2a.f.root-servers.org" > > and: > > $ dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT > "pek2b.f.root-servers.org" > > After running a couple of traceroutes it appears that he.net has a > route for F's anycast IPv6 address (2001:500:2f::f) towards Beijing. > According to https://www.isc.org/community/f-root/sites the Beijing > node should be a "Local Node" (without IPv6 but I suppose the list > is not up to date). > > I believe this means that a lot of DNS queries from IPv6 enabled > sites in US and other countries are going to Beijing. I wonder if > this is intentional? Chinese government (CNNIC) seems to be in the > path. > > All my sites seem to have he.net somewhere in the IPv6 connectivity > path. I wonder if this is specific to he.net or more wide-spread > routing anomaly? > > I have notified he.net NOC and F-root @ ISC. > > Best Regards, > -- > Janne Snabb / EPIPE Communications > snabb at epipe.com - http://epipe.com/ > > -- -JH From rsm at fast-serv.com Sun Oct 2 14:04:26 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Sun, 2 Oct 2011 15:04:26 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: Message-ID: <20111002190300.M49658@fast-serv.com> On Sun, 2 Oct 2011 17:40:23 +0000 (UTC), Janne Snabb wrote > I happened to notice the following at three separate sites around > the US and one site in Europe: Getting palo alto from east coast. 3 10gigabitethernet1-2.core1.atl1.he.net (2001:470:0:1b5::2) 8.166 ms 8.135 ms 8.103 ms 4 2001:470:0:ce::2 (2001:470:0:ce::2) 77.881 ms 77.866 ms 77.909 ms 5 iana.r1.atl1.isc.org (2001:500:61:6::1) 77.885 ms 77.924 ms 77.896 ms 6 int-0-5-0-1.r1.pao1.isc.org (2001:4f8:0:1::49:1) 76.846 ms 75.854 ms 75.819 ms 7 f.root-servers.net (2001:500:2f::f) 75.788 ms 75.756 ms 75.726 ms From bicknell at ufp.org Sun Oct 2 14:08:35 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 2 Oct 2011 12:08:35 -0700 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: Message-ID: <20111002190835.GA17278@ussenterprise.ufp.org> In a message written on Sun, Oct 02, 2011 at 05:40:23PM +0000, Janne Snabb wrote: > I happened to notice the following at three separate sites around > the US and one site in Europe: ISC has verified our PEK2 route was being leaked further than intended, and for the moment we have pulled the route until we can get confirmation from our partners that the problem has been resolved. Service should be back to normal, but if anyone is still having problems noc at isc.org will open a ticket. -- 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 toddunder at gmail.com Sun Oct 2 16:30:37 2011 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 2 Oct 2011 17:30:37 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111002190835.GA17278@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> Message-ID: leo, all, in the past, name servers that operated inside of china were subject to arbitrary rewriting or blocking of their results by the Great Firewall. this is obviously bad for Chinese citizens but it's *dramatically* worse for people outside of china who end up reaching a root server in china by mistake, no? people who ostensibly live free of this kind of interference and censorship are now subject to it by mistake. a previous time this happened renesys did a good write up on it. http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml i guess my questions now are: 1) how long was this happening? 2) can any root server operator who serves data inside of china verify that the data that they serve have not been rewritten by the great firewall? 3) does ISC (or ) have a plan for monitoring route distribution to ensure that this doesn't happen again (without prompt detection and mitigation)? i'm not really singling out ISC here--this is a serious problem for anyone who chooses to operate a root server node on untrustworthy or malicious network infrastructure (which is one appropriate way of thinking of a rewriting firewall from the perspective of a root server operator). cheers, t On Sun, Oct 2, 2011 at 3:08 PM, Leo Bicknell wrote: > In a message written on Sun, Oct 02, 2011 at 05:40:23PM +0000, Janne Snabb wrote: >> I happened to notice the following at three separate sites around >> the US and one site in Europe: > > ISC has verified our PEK2 route was being leaked further than > intended, and for the moment we have pulled the route until we can > get confirmation from our partners that the problem has been resolved. > Service should be back to normal, but if anyone is still having > problems noc at isc.org will open a ticket. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > From Valdis.Kletnieks at vt.edu Sun Oct 2 16:53:55 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 02 Oct 2011 17:53:55 -0400 Subject: Facebook insecure by design In-Reply-To: Your message of "Sun, 02 Oct 2011 08:38:36 PDT." <4E88857C.7040106@mtcc.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> Message-ID: <240172.1317592435@turing-police.cc.vt.edu> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: > I'm not sure why lack of TLS is considered to be problem with Facebook. > The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :) -------------- 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 Sun Oct 2 17:02:49 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 02 Oct 2011 18:02:49 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: Your message of "Sun, 02 Oct 2011 17:30:37 EDT." References: <20111002190835.GA17278@ussenterprise.ufp.org> Message-ID: <240436.1317592969@turing-police.cc.vt.edu> On Sun, 02 Oct 2011 17:30:37 EDT, Todd Underwood said: > 2) can any root server operator who serves data inside of china verify > that the data that they serve have not been rewritten by the great > firewall? DNSSEC should help this issue dramatically. This however could be problematic if the Chinese govt (or any repressive regime) decides to ban the use of technology that allows a user to identify when they're being repressed. > 3) does ISC (or ) have a plan for > monitoring route distribution to ensure that this doesn't happen again > (without prompt detection and mitigation)? Leaked routes happen External monitors and looking glasses and filters and communities are all things we should probably be doing more of, in order to minimize routing bogosity. But when all is said and done, there's no real way to have a dynamic routing protocol like BGP and at the same time *guarantee* that some chucklehead NOC monkey won't bollix things up. At best, we'll be able to get to "less than N brown-paper-bag moments per Tier-[12] per annum" for some value of N. -------------- 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 Sun Oct 2 17:04:23 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 02 Oct 2011 18:04:23 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: Your message of "Sun, 02 Oct 2011 12:08:35 PDT." <20111002190835.GA17278@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> Message-ID: <240490.1317593063@turing-police.cc.vt.edu> On Sun, 02 Oct 2011 12:08:35 PDT, Leo Bicknell said: > ISC has verified our PEK2 route was being leaked further than > intended, and for the moment we have pulled the route until we can > get confirmation from our partners that the problem has been resolved. So Leo - you don't have to give us a full reveal of the root cause, but did the phrase "chuckleheaded NOC monkey" enter at all into the saga? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From toddunder at gmail.com Sun Oct 2 17:07:14 2011 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 2 Oct 2011 18:07:14 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <240436.1317592969@turing-police.cc.vt.edu> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> Message-ID: valdis, all, On Sun, Oct 2, 2011 at 6:02 PM, wrote: > On Sun, 02 Oct 2011 17:30:37 EDT, Todd Underwood said: > >> 2) can any root server operator who serves data inside of china verify >> that the data that they serve have not been rewritten by the great >> firewall? > > DNSSEC should help this issue dramatically. ?This however could be problematic > if the Chinese govt (or any repressive regime) decides to ban the use of > technology that allows a user to identify when they're being repressed. sure, but DNSSEC is still basically unused. > >> 3) does ISC (or ) have a plan for >> monitoring route distribution to ensure that this doesn't happen again >> (without prompt detection and mitigation)? > > Leaked routes happen ?External monitors and looking glasses and filters and > communities are all things we should probably be doing more of, in order to > minimize routing bogosity. ?But when all is said and done, there's no real way > to have a dynamic routing protocol like BGP and at the same time *guarantee* > that some chucklehead NOC monkey won't bollix things up. ?At best, we'll be > able to get to "less than N brown-paper-bag moments per Tier-[12] per annum" for > some value of N. yep. this is a *great* argument *against* running critical information services on known-malicious network infrastructure, right? i.e.: if you are sure you're going to be interfered with regularly and you're positive you can't restrict the damage of that interference narrowly to the people who were already suffering such interference, perhaps you should choose to not locate your critical network information resource on that network. yes, i'm (again) suggesting that people take seriously not doing root name service inside of china as long as the great firewall exists. t From mysidia at gmail.com Sun Oct 2 17:25:21 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 2 Oct 2011 17:25:21 -0500 Subject: Facebook insecure by design In-Reply-To: <240172.1317592435@turing-police.cc.vt.edu> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> Message-ID: On Sun, Oct 2, 2011 at 4:53 PM, wrote: > On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: >> I'm not sure why lack of TLS is considered to be problem with Facebook. >> The man in the middle is the other side of the connection, tls or otherwise. > Ooh.. subtle. :) Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack. In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook. Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit. -- -JH From joelja at bogus.com Sun Oct 2 17:43:47 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 02 Oct 2011 15:43:47 -0700 Subject: Facebook insecure by design In-Reply-To: References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> Message-ID: <4E88E923.2000006@bogus.com> On 10/2/11 15:25 , Jimmy Hess wrote: > On Sun, Oct 2, 2011 at 4:53 PM, wrote: >> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: >>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>> The man in the middle is the other side of the connection, tls or otherwise. >> Ooh.. subtle. :) > > Man in the Middle (MITM) is a technical term that refers to a rather > specific kind of attack. > > In this case, I believe the proper term would be just "The man". > [Or "Man at the Other End (MATOE)"]; you either trust Facebook with > info to send to > them or you don't, and network security is only for securing the > transportation of that information > you opt to send facebook. alice sends charlie a message using bob's api, bob can observe and probably monetize the contents. > Yes, if Alice sends Bob an encrypted message that Bob can read, and > Bob turns out to > be untrustworthy, then Bob can sell/re-use the information in an > abusive/unapproved way for > personal or economic profit. charlie is probably untrustworthy, bob is probably moreso (mostly because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there. > -- > -JH > From joelja at bogus.com Sun Oct 2 18:05:38 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 02 Oct 2011 16:05:38 -0700 Subject: Facebook insecure by design In-Reply-To: <4E88E923.2000006@bogus.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> <4E88E923.2000006@bogus.com> Message-ID: <4E88EE42.8000407@bogus.com> On 10/2/11 15:43 , Joel jaeggli wrote: > On 10/2/11 15:25 , Jimmy Hess wrote: >> On Sun, Oct 2, 2011 at 4:53 PM, wrote: >>> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: >>>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>>> The man in the middle is the other side of the connection, tls or otherwise. >>> Ooh.. subtle. :) >> >> Man in the Middle (MITM) is a technical term that refers to a rather >> specific kind of attack. >> >> In this case, I believe the proper term would be just "The man". >> [Or "Man at the Other End (MATOE)"]; you either trust Facebook with >> info to send to >> them or you don't, and network security is only for securing the >> transportation of that information >> you opt to send facebook. > > alice sends charlie a message using bob's api, bob can observe and > probably monetize the contents. > >> Yes, if Alice sends Bob an encrypted message that Bob can read, and >> Bob turns out to >> be untrustworthy, then Bob can sell/re-use the information in an >> abusive/unapproved way for >> personal or economic profit. > > charlie is probably untrustworthy, bob is probably moreso (mostly ^ trustworthy > because bob has more to lose than charlie), alice isn't cognizant of the > implications of running charlie's app on bob's platform despite the > numerous disclaimers she blindly clicked through on the way there. > > > >> -- >> -JH >> > > From bicknell at ufp.org Sun Oct 2 18:06:44 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 2 Oct 2011 16:06:44 -0700 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> Message-ID: <20111002230644.GA24751@ussenterprise.ufp.org> In a message written on Sun, Oct 02, 2011 at 05:30:37PM -0400, Todd Underwood wrote: > i guess my questions now are: > > 1) how long was this happening? > 2) can any root server operator who serves data inside of china verify > that the data that they serve have not been rewritten by the great > firewall? > 3) does ISC (or ) have a plan for > monitoring route distribution to ensure that this doesn't happen again > (without prompt detection and mitigation)? I can't answer #1 with precision yet, but will attempt to get a precise answer soon. I'd like to partially address #2 and #3. ISC can verify that the responses sent from F-Root boxes are always the same, regardless of which server returns the answer. That is, there is no filtering or rewriting on any ISC root servers. We do know there are a number of locations around the world that have various rewriting and blocking systems employed. We have found networks where a query sent to F-Root never reaches an ISC run server. As a root operator we hate this, and believe the best way to solve the problem is DNSSEC. Short of providing a method like DNSSEC to verify the answer is legitimate, we know of no other countermeasure. There are in fact networks in the world that impersonate all 13 root servers, and we don't know of a lever to make them stop (short of local empowerment). In the case of transparent re-writers or blockers between us and the end users there is no practical way for us to detect that the modifications are happening, and thus I don't think anyone could answer your second question with precision. DNSSEC will at least let every user do the verification from their own vantage point, which is part of why it is so important. Regarding #3, ISC does monitor for leaked routes. Unfortunately these monitors are only as good as the vantage points they occupy, and so with upwards of 40,000 ASN's I don't know of any way to cover them all with any certianty. In this case it was even harder, as the leak (appears to have been) IPv6 only. There are a lot fewer IPv6 monitors, and folks are generally sloppy with their IPv6 configs so there is more leaking. The situation is improving rapidly. > i'm not really singling out ISC here--this is a serious problem for > anyone who chooses to operate a root server node on untrustworthy or > malicious network infrastructure (which is one appropriate way of > thinking of a rewriting firewall from the perspective of a root server > operator). I think the problem goes a lot further than root operators. The fact of the matter is that there are networks that tamper with your packets. From the benign NAT, to the full on transparent content filter/blocker. Most places that tamper with root queries also tamper with lots of other things. Without sort of reliable end to end crypto you really have no way of knowing. The root zone is signed. You can enable DNSSEC validation in your caching resolvers. There are plugins for popular browsers that attempt to do DNSSEC validation and show the results to the end user in some pleasing way. Much more work needs to be done in this area, but the technology is usable today. If you care about authentic responses, use it. Lastly, for some reason a ton of people always jump to the conclusion that these sort of events are the plot of $insert_bad_guy. I've chased down many leaks of F-Root during my time, and 100% of them to date have been an accident. The clueless NOC monkey. The poorly written route map. Someone not reading the documentation. Even if $insert_bad_guy wanted to hijack F-Root (or any other root), doing it in this way is very visable and easy to work around. It just doesn't make sense to even try. -- 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 jra at baylink.com Sun Oct 2 22:11:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 2 Oct 2011 23:11:28 -0400 (EDT) Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <240436.1317592969@turing-police.cc.vt.edu> Message-ID: <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > DNSSEC should help this issue dramatically. This however could be problematic > if the Chinese govt (or any repressive regime) decides to ban the use of > technology that allows a user to identify when they're being repressed. We won't be permitted to see the repression inherent in the system? Cheers, -- jr 'Run Away!' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From phil at cluestick.net Sun Oct 2 22:25:20 2011 From: phil at cluestick.net (Phil Dyer) Date: Sun, 2 Oct 2011 23:25:20 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Oct 2, 2011 at 11:11 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Valdis Kletnieks" > >> DNSSEC should help this issue dramatically. This however could be problematic >> if the Chinese govt (or any repressive regime) decides to ban the use of >> technology that allows a user to identify when they're being repressed. > > We won't be permitted to see the repression inherent in the system? help, help! I'm being repressed! phil From mysidia at gmail.com Sun Oct 2 23:26:41 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 2 Oct 2011 23:26:41 -0500 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Oct 2, 2011 at 10:11 PM, Jay Ashworth wrote: >> DNSSEC should help this issue dramatically. This however could be problematic >> if the Chinese govt (or any repressive regime) decides to ban the use of >> technology that allows a user to identify when they're being repressed. > We won't be permitted to see the repression inherent in the system? You actually think China will be the first to ban DNSSEC? Maybe, but It will probably be banned first indirectly, by governments legislating requirements of SPs that are incompatible with DNSSEC. The repression is at home in the form of the US PROTECT IP bill that will provide a framework for DNS authorities, domain registries, and ISPs/operators of non-authoritative nameservers to be sent letters requiring them to modify DNS responses for other organization's domains based on allegations/suspicions. -- -JH From randy at psg.com Mon Oct 3 00:47:58 2011 From: randy at psg.com (Randy Bush) Date: Mon, 03 Oct 2011 14:47:58 +0900 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> Message-ID: china nukes 120,000 domains for going against the policy of the state. oops! that wasn't china, was it? perhaps, we should postpone telling others what to do until our side of the street is clean? randy From ops.lists at gmail.com Mon Oct 3 00:59:43 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 3 Oct 2011 11:29:43 +0530 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> Message-ID: 120K domains - basically cnnic seems to have finally got tired of russian botmaster types registering thousands of domains at a time, and put in a rule that says you need business registration in China / ID in china to register a .cn Beyond that, that's one ccTLD - however large. There are multiple gTLDs that have already done a great job of cleanup (biz, info for example) and so far I haven't heard of .us having an infestation of botmasters / spammers. And of course there are all the registrars out there that need to be reached out to / handled etc etc - but that's another kettle of fish. We're discussing two different things here - apples and oranges, though it does look like they're all part of the same fruit salad. 1. Action by different registrars / registries [in .cn's case, a government controlled registry, to be sure] 2. State policy to route internet access and DNS through an inspecting + rewriting firewall that blocks or replaces politically unacceptable content --srs On Mon, Oct 3, 2011 at 11:17 AM, Randy Bush wrote: > china nukes 120,000 domains for going against the policy of the state. > > oops! that wasn't china, was it? > > perhaps, we should postpone telling others what to do until our side of > the street is clean? > > randy > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From Valdis.Kletnieks at vt.edu Mon Oct 3 01:12:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Oct 2011 02:12:32 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: Your message of "Mon, 03 Oct 2011 11:29:43 +0530." References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> Message-ID: <258047.1317622352@turing-police.cc.vt.edu> On Mon, 03 Oct 2011 11:29:43 +0530, Suresh Ramasubramanian said: > 120K domains - basically cnnic seems to have finally got tired of russian No, I think Randy was referring to this sort of thing: http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ops.lists at gmail.com Mon Oct 3 01:15:31 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 3 Oct 2011 11:45:31 +0530 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <258047.1317622352@turing-police.cc.vt.edu> References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> <258047.1317622352@turing-police.cc.vt.edu> Message-ID: Sure - but what was being discussed in this thread was transparent / on the fly rewrites of root server responses getting exposed to people beyond china. Whether these responses should be altered / censored within china or not is a different can of worms, and that too has nothing at all to do with either registry policy, or law enforcement mandated domain seizure. On Mon, Oct 3, 2011 at 11:42 AM, wrote: > > No, I think Randy was referring to this sort of thing: > > http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/ -- Suresh Ramasubramanian (ops.lists at gmail.com) From bortzmeyer at nic.fr Mon Oct 3 02:03:12 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 3 Oct 2011 09:03:12 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: Message-ID: <20111003070312.GA29884@nic.fr> On Sun, Oct 02, 2011 at 05:40:23PM +0000, Janne Snabb wrote a message of 32 lines which said: > I happened to notice the following at three separate sites around > the US and one site in Europe: Good analysis at From bortzmeyer at nic.fr Mon Oct 3 02:26:06 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 3 Oct 2011 09:26:06 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111002230644.GA24751@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> <20111002230644.GA24751@ussenterprise.ufp.org> Message-ID: <20111003072606.GB29884@nic.fr> On Sun, Oct 02, 2011 at 04:06:44PM -0700, Leo Bicknell wrote a message of 107 lines which said: > We have found networks where a query sent to F-Root never reaches an > ISC run server. For details on such behavior, i highly recommend the excellent paper "Identifying and Characterizing Anycast in the Domain Name System" , which shows, among other things, that such masquerading (by a false root name server) happens. From tvhawaii at shaka.com Mon Oct 3 02:51:41 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 2 Oct 2011 21:51:41 -1000 Subject: F.ROOT-SERVERS.NET moved to Beijing? References: <240436.1317592969@turing-police.cc.vt.edu> <7618989.3878.1317611488132.JavaMail.root@benjamin.baylink.com> <258047.1317622352@turing-police.cc.vt.edu> Message-ID: ----- Original Message ----- From: On Mon, 03 Oct 2011 11:29:43 +0530, Suresh Ramasubramanian said: > 120K domains - basically cnnic seems to have finally got tired of russian >No, I think Randy was referring to this sort of thing: http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/ "Our government has gone rogue on us," Eric Goldman, a professor at Santa Clara University School of Law, said. "Our government is going into court with half-baked facts and half-baked legal theories and shutting down operations. This is exactly what we thought the government couldn't do. I'm scratching my head why we aren't' grabbing the pitchforks." ? I.C.E., our very own Gestapo-Without-Borders. Makes me proud. From bortzmeyer at nic.fr Mon Oct 3 05:33:44 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 3 Oct 2011 12:33:44 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: Message-ID: <20111003103344.GB8924@nic.fr> On Sun, Oct 02, 2011 at 05:40:23PM +0000, Janne Snabb wrote a message of 32 lines which said: > $ dig +short +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT > "pek2a.f.root-servers.org" The next time, I suggest to also run "data" queries such as "A www.facebook.com" or "A www.twitter.com" to see if there is hard evidence of an actual security problem. (Most articles on this case mentioned that "we have no proof there was a rewriting of answers from the F-root instance".) From dot at dotat.at Mon Oct 3 06:29:48 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 3 Oct 2011 12:29:48 +0100 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> Message-ID: Todd Underwood wrote: > > sure, but DNSSEC is still basically unused. If you are running BIND 9.8 there is really no reason not to turn on DNSSEC validation, then you won't have to worry about anycast routes leaking from behind the great firewall. dnssec-validation auto; dnssec-lookaside auto; Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Southerly veering southwesterly 6 to gale 8, occasionally severe gale 9 at first in northwest Viking. Moderate or rough becoming very rough or high. Rain then squally showers. Moderate or good, occasionally poor. From ryanczak at gmail.com Mon Oct 3 08:22:11 2011 From: ryanczak at gmail.com (Matt Ryanczak) Date: Mon, 03 Oct 2011 09:22:11 -0400 Subject: Ashburn Va. Datacenter Movers Message-ID: <4E89B703.40105@gmail.com> Can anyone recommend a vendor in the D.C. metro region with experience moving equipment between datacenters? I'm looking for an experienced, bonded, team of professionals to help with un-racking, moving and re-racking network equipment, servers and all of the related gear. Feel free to contact me offlist. Thanks, ~Matt From danny at tcb.net Mon Oct 3 08:27:46 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 3 Oct 2011 09:27:46 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> Message-ID: <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> On Oct 3, 2011, at 7:29 AM, Tony Finch wrote: > > If you are running BIND 9.8 there is really no reason not to turn on > DNSSEC validation, then you won't have to worry about anycast routes > leaking from behind the great firewall. User Exercise: What happens when you enable integrity checking in an application (e.g., 'dnssec-validation auto') and datapath manipulation persists? Bonus points for analysis of implementation and deployment behaviors and resulting systemic effects. Network layer integrity techniques and secure routing infrastructure are all that's going to fix this. In the interim, the ability to detect such incidents at some rate faster than the speed of mailing lists would be ideal. -danny From isabeldias1 at yahoo.com Mon Oct 3 08:32:18 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Mon, 3 Oct 2011 06:32:18 -0700 (PDT) Subject: Ashburn Va. Datacenter Movers In-Reply-To: <4E89B703.40105@gmail.com> References: <4E89B703.40105@gmail.com> Message-ID: <1317648738.57189.YahooMailNeo@web121620.mail.ne1.yahoo.com> ask your account manager if he has any agreement in place with any supplier ________________________________ From: Matt Ryanczak To: nanog at nanog.org Sent: Monday, October 3, 2011 2:22 PM Subject: Ashburn Va. Datacenter Movers Can anyone recommend a vendor in the D.C. metro region with experience moving equipment between datacenters? I'm looking for an experienced, bonded, team of professionals to help with un-racking, moving and re-racking network equipment, servers and all of the related gear. Feel free to contact me offlist. Thanks, ~Matt From toddunder at gmail.com Mon Oct 3 09:30:47 2011 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 3 Oct 2011 10:30:47 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> Message-ID: > User Exercise: ?What happens when you enable integrity checking in an > application (e.g., 'dnssec-validation auto') and datapath manipulation > persists? ?Bonus points for analysis of implementation and deployment > behaviors and resulting systemic effects. > i agree with danny here. ignoring randy (and others) off-topic comments about hypocrisy, this situation is fundamentally a situation of bad (or different) network policy being applied outside of its scope. i would prefer that china not censor the internet, sure. but i really require that china not censor *my* internet when i'm not in china. t From bmanning at vacation.karoshi.com Mon Oct 3 09:42:21 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 3 Oct 2011 14:42:21 +0000 Subject: ..."my" Internet... snicker :) In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> Message-ID: <20111003144221.GA1992@vacation.karoshi.com.> On Mon, Oct 03, 2011 at 10:30:47AM -0400, Todd Underwood wrote: > > User Exercise: What happens when you enable integrity checking in an > > application (e.g., 'dnssec-validation auto') and datapath manipulation > > persists? Bonus points for analysis of implementation and deployment > > behaviors and resulting systemic effects. > > > > i agree with danny here. > > ignoring randy (and others) off-topic comments about hypocrisy, this > situation is fundamentally a situation of bad (or different) network > policy being applied outside of its scope. i would prefer that china > not censor the internet, sure. but i really require that china not > censor *my* internet when i'm not in china. > > t well, not to disagree - BUT.... the sole reason we have BGP and use ASNs the way we do is to ensure/enforce local policy. It is, after all, an AUTONOMOUS SYSTEM number. One sets policy at its boundaries on what/how to accept/reject/modify traffic crossing the boundary. If you dont -like- the ASN policy - then don't use/traverse that ASN. and rPKI has the same problems as DNSSEC. lack of uniform use/implementation is going to be a huge party - full of fun & games. /bill From emile.aben at ripe.net Mon Oct 3 09:45:01 2011 From: emile.aben at ripe.net (Emile Aben) Date: Mon, 03 Oct 2011 16:45:01 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111003070312.GA29884@nic.fr> References: <20111003070312.GA29884@nic.fr> Message-ID: <4E89CA6D.8030303@ripe.net> On 03/10/2011 09:03, Stephane Bortzmeyer wrote: > On Sun, Oct 02, 2011 at 05:40:23PM +0000, > Janne Snabb wrote > a message of 32 lines which said: > >> I happened to notice the following at three separate sites around >> the US and one site in Europe: > > Good analysis at We used DNSMON data to analyse this event, and found an earlier leak on 29 and 30 September: https://labs.ripe.net/Members/emileaben/f-root-route-leak-the-dnsmon-view best regards, Emile Aben RIPE NCC From randy at psg.com Mon Oct 3 09:46:58 2011 From: randy at psg.com (Randy Bush) Date: Mon, 03 Oct 2011 23:46:58 +0900 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> Message-ID: > ignoring randy (and others) off-topic comments about hypocrisy actually, if you had followed the thread in its sad detail, at that point of jingoism they were on. > this situation is fundamentally a situation of bad (or different) > network policy being applied outside of its scope. kink is gonna leak. rfc1918 is gonna leak. ula-foo is gonna leak. pakistani kink is gonna leak. anycast 'local' cones are gonna leak. chinese kink is gonna leak. american kink is gonna leak. s/are gonna/has already/g are people gonna stop doing kink? sadly, not likely. so all we are left is Danny McPherson wrote: > Network layer integrity techniques and secure routing infrastructure > are all that's going to fix this. and Danny McPherson wrote: > In the interim, the ability to detect such incidents at some rate > faster than the speed of mailing lists would be ideal. is not a lot of good unless you insert "and fix." watching train wrecks is about as fun as reading pontification on nanog. qed :) randy From patrick.sumby at sohonet.co.uk Mon Oct 3 09:53:28 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Mon, 03 Oct 2011 15:53:28 +0100 Subject: Facebook insecure by design In-Reply-To: <4E88A705.7030803@mtcc.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <4E889EE4.7090600@gmail.com> <4E88A705.7030803@mtcc.com> Message-ID: <4E89CC68.5010206@sohonet.co.uk> On 02/10/2011 19:01, Michael Thomas wrote: > William Allen Simpson wrote: >> On 10/2/11 12:36 PM, Jimmy Hess wrote: >>> On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: >>>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>>> The man in the middle is the other side of the connection, tls or >>>> otherwise. >>> >>> That's where the X509 certificate comes in. A man in the middle >>> would not have the proper private key to impersonate the Facebook >>> server that the certificate was issued to. >>> >> My understanding of his statement is that Facebook itself is the MITM, >> collecting all our personal information. Too true. > > Bingo. > > Mike > +1 From bicknell at ufp.org Mon Oct 3 10:20:01 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 3 Oct 2011 08:20:01 -0700 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> Message-ID: <20111003152001.GA65695@ussenterprise.ufp.org> In a message written on Mon, Oct 03, 2011 at 09:27:46AM -0400, Danny McPherson wrote: > User Exercise: What happens when you enable integrity checking in an > application (e.g., 'dnssec-validation auto') and datapath manipulation > persists? Bonus points for analysis of implementation and deployment > behaviors and resulting systemic effects. I think this is a (to some on the list) cryptic way of asking "If all your routes to the server go to someone masquerading, what happens when you try to validate that data?" The question being if you configure your nameserver to validate the root, but don't get signed answers back will your nameserver refuse to serve up any data, effectively taking you and your users offline? The answer should be no. This is part of why there are 13 root servers. If a nameserver is told the root is signed and it gets unsigned answers from one of the 13, it should ignore them and move on. I do not off the top of my head know all the timeouts and implementation dependant behaviors, but also remember that a up caching resolver will make approximately 1 query to the root per day for _valid_ names, but many queries per day for invalid names. Thus the impact to valid names should be minimal, even in the face of longer timeouts. Is there enough operational experience with DNSSEC? No. Can we fix that by saying it's not good enough yet? No. Run it. The people who write nameserver software are comitted to fixing any issues as quickly as possible, because it is our best way to secure DNS. > Network layer integrity techniques and secure routing infrastructure are > all that's going to fix this. In the interim, the ability to detect such > incidents at some rate faster than the speed of mailing lists would be > ideal. Network layer integrity and secure routing don't help the majority of end users. At my house I can choose Comcast or AT&T service. They will not run BGP with me, I could not apply RPKI, secure BGP, or any other method to the connections. They may well do NXDOMAIN remapping on their resolvers, or even try and transparently rewrite DNS answers. Indeed some ISP's have even experimented with injecting data into port 80 traffic transparently! Secure networks only help if the users have a choice, and choose to not use "bad" networks. If you want to be able to connect at Starbucks, or the airport, or even the conference room Wifi on a clients site you need to assume it's a rogue network in the middle. The only way for a user to know what they are getting is end to end crypto. Period. As for the speed of detection, its either instantenous (DNSSEC validation fails), or it doesn't matter how long it is (minutes, hours, days). The real problem is the time to resolve. It doesn't matter if we can detect in seconds or minutes when it may take hours to get the right people on the phone and resolve it. Consider this weekend's activity; it happened on a weekend for both an operator based in the US and a provider based in China, so you're dealing with weekend staff and a 12 hour time difference. If you want to insure accuracy of data, you need DNSSEC, period. If you want to insure low latency access to the root, you need multiple Anycasted instances because at any one point in time a particular one may be "bad" (node near you down for maintenance, routing issue, who knows) which is part of why there are 13 root servers. Those two things together can make for resilliance, security and high performance. -- 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 leschnik at gmail.com Mon Oct 3 11:08:41 2011 From: leschnik at gmail.com (Jason Leschnik) Date: Tue, 4 Oct 2011 03:08:41 +1100 Subject: Facebook insecure by design In-Reply-To: <4E889EE4.7090600@gmail.com> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <4E889EE4.7090600@gmail.com> Message-ID: On Mon, Oct 3, 2011 at 4:27 AM, William Allen Simpson < william.allen.simpson at gmail.com> wrote: > On 10/2/11 12:36 PM, Jimmy Hess wrote: > >> On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: >> >>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>> The man in the middle is the other side of the connection, tls or >>> otherwise. >>> >> >> That's where the X509 certificate comes in. A man in the middle >> would not have the proper private key to impersonate the Facebook >> server that the certificate was issued to. >> >> My understanding of his statement is that Facebook itself is the MITM, > collecting all our personal information. Too true. > > I assume that any MITM is actually going to try and prevent our data from making it to the end point i.e the real attacker. -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@] jml974 at uow.edu.au From danny at tcb.net Mon Oct 3 11:38:25 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 3 Oct 2011 12:38:25 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111003152001.GA65695@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> Message-ID: <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> On Oct 3, 2011, at 11:20 AM, Leo Bicknell wrote: > > Thus the impact to valid names should be minimal, even in the face > of longer timeouts. If you're performing validation on a recursive name server (or similar resolution process) expecting a signed response yet the response you receive is either unsigned or doesn't validate (i.e., bogus) you have to: 1) ask other authorities? how many? how frequently? impact? 2) consider implications on _entire chain of trust? 3) tell the client something? 4) cache what (e.g., zone cut from who you asked)? how long? 5) other? "minimal" is not what I was thinking.. > Network layer integrity and secure routing don't help the majority of > end users. At my house I can choose Comcast or AT&T service. They will > not run BGP with me, I could not apply RPKI, secure BGP, or any other > method to the connections. They may well do NXDOMAIN remapping on their > resolvers, or even try and transparently rewrite DNS answers. Indeed > some ISP's have even experimented with injecting data into port 80 > traffic transparently! > > Secure networks only help if the users have a choice, and choose to not > use "bad" networks. If you want to be able to connect at Starbucks, or > the airport, or even the conference room Wifi on a clients site you need > to assume it's a rogue network in the middle. > > The only way for a user to know what they are getting is end to end > crypto. Period. I'm not sure how "end to end" crypto helps end users in the advent of connectivity and *availability* issues resulting from routing brokenness in an upstream network which they do not control. "crypto", OTOH, depending on what it is and where in the stack it's applied, might well align with my "network layer integrity" assertion. > As for the speed of detection, its either instantenous (DNSSEC > validation fails), or it doesn't matter how long it is (minutes, > hours, days). The real problem is the time to resolve. It doesn't > matter if we can detect in seconds or minutes when it may take hours > to get the right people on the phone and resolve it. Consider this > weekend's activity; it happened on a weekend for both an operator > based in the US and a provider based in China, so you're dealing > with weekend staff and a 12 hour time difference. > > If you want to insure accuracy of data, you need DNSSEC, period. > If you want to insure low latency access to the root, you need > multiple Anycasted instances because at any one point in time a > particular one may be "bad" (node near you down for maintenance, > routing issue, who knows) which is part of why there are 13 root > servers. Those two things together can make for resilliance, > security and high performance. You miss the point here Leo. If the operator of a network service can't detect issues *when they occur* in the current system in some automated manner, whether unintentional or malicious, they won't be alerted, they certainly can't "fix" the problem, and the potential exposure window can be significant. Ideally, the trigger for the alert and detection function is more mechanized than "notification by services consumer", and the network service operators or other network operators aware of the issue have some ability to institute reactive controls to surgically deal with that particular issue, rather than being captive to the [s]lowest common denominator of all involved parties, and dealing with additional non-determinsitic failures or exposure in the interim. Back to my earlier point, for *resilience* network layer integrity techniques and secure routing infrastructure are the only preventative controls here, and necessarily to augment DNSSEC's authentication and integrity functions at the application layer. Absent these, rapid detection enabling reactive controls that mitigate the issue are necessary. -danny From morrowc.lists at gmail.com Mon Oct 3 12:09:17 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Oct 2011 13:09:17 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> Message-ID: On Mon, Oct 3, 2011 at 12:38 PM, Danny McPherson wrote: > ?If the operator of a network service > can't detect issues *when they occur* in the current system in some > automated manner, whether unintentional or malicious, they won't be > alerted, they certainly can't "fix" the problem, and the potential > exposure window can be significant. > > Ideally, the trigger for the alert and detection function is more > mechanized than "notification by services consumer", and the network > service operators or other network operators aware of the issue have Does ISC (or any other anycast root/*tld provider) have external polling methods that can reliably tell when, as was in this case, local-anycast-instances are made global? (or when the cone of silence widens?) Given that in the ISC case the hostname.bind query can tell you at least the region + instance#, it seems plausible that some system of systems could track current/changes in the mappings, no? and either auto-action some 'fix' (SHUT DOWN THE IAD INSTANCE IT's ROGUE!) or at least log and notify a hi-priority operations fixer. Given something like the unique-as work Verisign has been behind you'd think monitoring route origins and logging 'interesting' changes could accomplish this as well? (I suppose i'm not prescribing solutions above, just wondering if something like these is/could-be done feasibly) -chris From mike at mtcc.com Mon Oct 3 12:21:36 2011 From: mike at mtcc.com (Michael Thomas) Date: Mon, 03 Oct 2011 10:21:36 -0700 Subject: Facebook insecure by design In-Reply-To: References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <4E889EE4.7090600@gmail.com> Message-ID: <4E89EF20.4070207@mtcc.com> Jason Leschnik wrote: > On Mon, Oct 3, 2011 at 4:27 AM, William Allen Simpson < > william.allen.simpson at gmail.com> wrote: > >> On 10/2/11 12:36 PM, Jimmy Hess wrote: >> >>> On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: >>> >>>> I'm not sure why lack of TLS is considered to be problem with Facebook. >>>> The man in the middle is the other side of the connection, tls or >>>> otherwise. >>>> >>> That's where the X509 certificate comes in. A man in the middle >>> would not have the proper private key to impersonate the Facebook >>> server that the certificate was issued to. >>> >>> My understanding of his statement is that Facebook itself is the MITM, >> collecting all our personal information. Too true. >> >> > I assume that any MITM is actually going to try and prevent our data from > making it to the end point i.e the real attacker. What fun would that be? Seriously though, a MITM doesn't have to be disruptive; there are a zillion and three other reasons. Like getting a big budg hollywood movie made about you. Mike From bicknell at ufp.org Mon Oct 3 12:34:31 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 3 Oct 2011 10:34:31 -0700 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> Message-ID: <20111003173431.GA71928@ussenterprise.ufp.org> In a message written on Mon, Oct 03, 2011 at 12:38:25PM -0400, Danny McPherson wrote: > 1) ask other authorities? how many? how frequently? impact? > 2) consider implications on _entire chain of trust? > 3) tell the client something? > 4) cache what (e.g., zone cut from who you asked)? how long? > 5) other? > > "minimal" is not what I was thinking.. I'm asking the BIND team for a better answer, however my best understanding is this will query a second root server (typically next best by RTT) when it gets a non-validating answer, and assuming the second best one validates just fine there are no further follow on effects. So you're talking one extra query when a caching resolver hits the root. We can argue if that is minimal or not, but I suspect most end users behind that resolver would never notice. > You miss the point here Leo. If the operator of a network service > can't detect issues *when they occur* in the current system in some > automated manner, whether unintentional or malicious, they won't be > alerted, they certainly can't "fix" the problem, and the potential > exposure window can be significant. In a message written on Mon, Oct 03, 2011 at 01:09:17PM -0400, Christopher Morrow wrote: > Does ISC (or any other anycast root/*tld provider) have external > polling methods that can reliably tell when, as was in this case, > local-anycast-instances are made global? (or when the cone of silence > widens?) Could ISC (or any other root operator) do more monitoring? I'm sure, but let's scope the problem first. We're dealing here with a relatively wide spread leak, but that is in fact the rare case. There are 39,000 ASN's active in the routing system. Each one of those ASN's can affect it's path to the root server by: 1) Bringing up an internal instance of a root server, injecting it into its IGP, and "hijacking" the route. 2) Turning up or down a peer that hosts a root server. 3) Turning up or down a transit provider. 4) Adding or removing links internal to their network that change their internal selection to use a different external route. The only way to make sure a route was correct, everywhere, would be to have 39,000+ probes, one on every ASN, and check the path to the root server. Even if you had that, how do you define when any of the changes in 1-4 are legitimate? You could DNSSEC verify to rule out #1, but #2-4 are local decisions made by the ASN (or one of its upstreams). I suppose, if someone had all 39,000+ probes, we could attempt to write algorythms that determined if too much "change" was happening at once; but I'm reminded of events like the earthquake that took out many asian cables a few years back. There's a very real danger in such a system shutting down a large number of nodes during such an event due to the magnitude of changes which I'd suggest is the exact opposite of what the Internet needs to have happen in that event. > (I suppose i'm not prescribing solutions above, just wondering if > something like these is/could-be done feasibly) Not really. Look, I chase down several dozen F-Root leaks a year. You never hear about them on NANOG. Why? Well, it's some small ISP in the middle of nowhere leaking to a peer who believes them, and thus they get a 40ms response time when they should have a 20ms response time by believing the wrong route. Basically, almost no one cares, generally it takes some uber-DNS nerd at a remote site to figure this out and contact us for help. This has tought me that viewpoints are key. You have to be on the right network to detect it has hijacked all 13 root servers, you can't probe that from the outside. You also have to be on the right network to see you're getting the F-Root 1000 miles away rather than the one 500. Those 39,000 ASN's are providing a moving playing field, with relationships changing quite literally every day, and every one of them may be a "leak". This one caught attention not because it was a bad leak. It was IPv6 only. Our monitoring suggests this entire leak siphoned away 40 queries per second, at it's peak, across all of F-Root. In terms of a percentage of queries it doesn't even show visually on any of our graphs. No, it drew attention for totally non-technical reasons, US users panicing that the Chinese goverment was hijacking the Internet which is just laughable in this context. There really is nothing to see here. DNSSEC fixes any security implications from these events. My fat fingers have dropped more than 40qps on the floor more than once this year, and you didn't notice. Bad events (like earthquakes and fiber cuts) have taken any number of servers from any number of operators multiple times this year. Were it not for the fact that someone posted to NANOG, I bet most of the people here would have never noticed their 99.999% working system kept working just fine. I think all the root ops can do better, use more monitoring services, detect more route hijacks faster, but none of us will ever get 100%. None will ever be instantaneous. Don't make that the goal, make the system robust in the face of that reality. My own resolution is better IPv6 monitoring for F-root. :) -- 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 danny at tcb.net Mon Oct 3 12:39:17 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 3 Oct 2011 13:39:17 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> Message-ID: On Oct 3, 2011, at 1:09 PM, Christopher Morrow wrote: > Given that in the ISC case the hostname.bind query can tell you at > least the region + instance#, it seems plausible that some system of > systems could track current/changes in the mappings, no? and either > auto-action some 'fix' (SHUT DOWN THE IAD INSTANCE IT's ROGUE!) or at > least log and notify a hi-priority operations fixer. That sort of capability at the application layer certainly seems prudent to me, noting that it does assume you have a measurement node within the catchment in question and are measuring at a high enough frequency to detect objective incidents. > Given something like the unique-as work Verisign has been behind you'd > think monitoring route origins and logging 'interesting' changes could > accomplish this as well? I'm a fan of both routing system && consumer-esque monitoring, and do believe that a discriminator in the routing system associated with globally anycasted prefixes makes this simpler - for both detection, and possibly even reactive or preventative controls IF necessary. A unique origin AS is not the only place you can do this in the routing system, as I'm sure some will observe, but it seems an ideal location to me. -danny From danny at tcb.net Mon Oct 3 12:49:04 2011 From: danny at tcb.net (Danny McPherson) Date: Mon, 3 Oct 2011 13:49:04 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111003173431.GA71928@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> Message-ID: On Oct 3, 2011, at 1:34 PM, Leo Bicknell wrote: > > I'm asking the BIND team for a better answer, however my best > understanding is this will query a second root server (typically > next best by RTT) when it gets a non-validating answer, and assuming > the second best one validates just fine there are no further follow > on effects. So you're talking one extra query when a caching > resolver hits the root. We can argue if that is minimal or not, > but I suspect most end users behind that resolver would never notice. I'm not talking "one extra query", and it's not simply about subsequent transaction attempts either - so conjecture aiming to marginalize the impact isn't particularly helpful. I.e., have that look, get back to us... :-) -danny From millnert at gmail.com Mon Oct 3 13:44:50 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 3 Oct 2011 20:44:50 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: <20111003173431.GA71928@ussenterprise.ufp.org> References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> Message-ID: Leo, On Mon, Oct 3, 2011 at 7:34 PM, Leo Bicknell wrote: > The only way to make sure a route was correct, everywhere, would > be to have 39,000+ probes, one on every ASN, and check the path to > the root server. ?Even if you had that, how do you define when any > of the changes in 1-4 are legitimate? ?You could DNSSEC verify to > rule out #1, but #2-4 are local decisions made by the ASN (or one > of its upstreams). > > I suppose, if someone had all 39,000+ probes, we could attempt to > write algorythms that determined if too much "change" was happening > at once; but I'm reminded of events like the earthquake that took > out many asian cables a few years back. ?There's a very real danger > in such a system shutting down a large number of nodes during such > an event due to the magnitude of changes which I'd suggest is the > exact opposite of what the Internet needs to have happen in that > event. This sounds an awfully lot like the notary concept: - http://perspectives-project.org/ - http://convergence.io/ Furthermore, changing network paths used to reach information probably should not be reason to shut down a service, in general. More interesting than which path is used, I suppose, is whether or not the data being returned has been changed in some unexpected/undesired way. Regards, Martin From markk at arin.net Mon Oct 3 14:11:34 2011 From: markk at arin.net (Mark Kosters) Date: Mon, 3 Oct 2011 19:11:34 +0000 Subject: FW: [arin-announce] Whois Query Behavior is Updated In-Reply-To: <4E89072D.80703@arin.net> Message-ID: Hi Apologies for the cross post from ARIN-Announce. Thought that many of you would be interested in hearing about the recent ARIN Whois change given the recent discussion on NANOG. Regards, Mark Kosters ARIN CTO On 10/2/11 8:51 PM, "ARIN" wrote: >ARIN has changed the Whois query behavior on port 43. A query for an IP >address in the ARIN region will return only that assignment/allocation >within the ARIN region, and will no longer included ARIN's parent record >(the /8). > >Both the Whois web interface and Whois-RWS behavior were not affected by >this configuration change. > >Regards, > >Mark Kosters >Chief Technical Officer >American Registry for Internet Numbers (ARIN) From morrowc.lists at gmail.com Mon Oct 3 15:33:39 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Oct 2011 16:33:39 -0400 Subject: FW: [arin-announce] Whois Query Behavior is Updated In-Reply-To: References: <4E89072D.80703@arin.net> Message-ID: On Mon, Oct 3, 2011 at 3:11 PM, Mark Kosters wrote: > Hi > > Apologies for the cross post from ARIN-Announce. Thought that many of you > would be interested in hearing about the recent ARIN Whois change given > the recent discussion on NANOG. thanks! :) From jabley at hopcount.ca Mon Oct 3 16:10:47 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 3 Oct 2011 17:10:47 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> Message-ID: On 2011-10-03, at 13:39, Danny McPherson wrote: > On Oct 3, 2011, at 1:09 PM, Christopher Morrow wrote: > >> Given that in the ISC case the hostname.bind query can tell you at >> least the region + instance#, it seems plausible that some system of >> systems could track current/changes in the mappings, no? and either >> auto-action some 'fix' (SHUT DOWN THE IAD INSTANCE IT's ROGUE!) or at >> least log and notify a hi-priority operations fixer. > > That sort of capability at the application layer certainly seems > prudent to me, noting that it does assume you have a measurement > node within the catchment in question and are measuring at a high > enough frequency to detect objective incidents. In principle there seems like no reason that a DNS client sending queries to authority-only servers couldn't decide to include the NSID option and log changes in declared server identity between subsequent queries (or take some other configured action). We support 5001 on L-Root (which runs NSD), for what that's worth, as well as HOSTNAME.BIND/CH/TXT, VERSION.BIND/CH/TXT, ID.SERVER/CH/TXT and VERSION.SERVER/CH/TXT, but those require separate queries. I appreciate NSID support is not universal, but perhaps that's ok in the sense of "better than nothing". > I'm a fan of both routing system && consumer-esque monitoring, and > do believe that a discriminator in the routing system associated with > globally anycasted prefixes makes this simpler - for both detection, > and possibly even reactive or preventative controls IF necessary. A > unique origin AS is not the only place you can do this in the routing > system, as I'm sure some will observe, but it seems an ideal location > to me. Whether it's the right-most entry in the AS_PATH or a bigger substring, you still need more measurement points than you have if you want to catch every leak. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Mon Oct 3 17:00:52 2011 From: randy at psg.com (Randy Bush) Date: Tue, 04 Oct 2011 07:00:52 +0900 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> Message-ID: > Furthermore, changing network paths used to reach information probably > should not be reason to shut down a service, in general. cool. then we can get rid of dynamic routing. it always has been a pain in the ass. randy From bicknell at ufp.org Mon Oct 3 17:07:02 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 3 Oct 2011 15:07:02 -0700 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> Message-ID: <20111003220702.GA92536@ussenterprise.ufp.org> In a message written on Tue, Oct 04, 2011 at 07:00:52AM +0900, Randy Bush wrote: > cool. then we can get rid of dynamic routing. it always has been a > pain in the ass. If we went back to hosts.txt this pesky DNS infrastructure would be totally unnecessary. -- 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 Valdis.Kletnieks at vt.edu Mon Oct 3 17:21:36 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Oct 2011 18:21:36 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: Your message of "Mon, 03 Oct 2011 15:07:02 PDT." <20111003220702.GA92536@ussenterprise.ufp.org> References: <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> <20111003220702.GA92536@ussenterprise.ufp.org> Message-ID: <25767.1317680496@turing-police.cc.vt.edu> On Mon, 03 Oct 2011 15:07:02 PDT, Leo Bicknell said: > If we went back to hosts.txt this pesky DNS infrastructure would > be totally unnecessary. You're just saying that because you're hoping your employer will get to sell bandwidth to SRI-NIC.ARPA ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aiden at sullivan.in Mon Oct 3 17:35:58 2011 From: aiden at sullivan.in (Aiden Sullivan) Date: Mon, 3 Oct 2011 15:35:58 -0700 Subject: he.net down? Message-ID: <20111003223558.GA30417@hothead.caltech.edu> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is going on? -- Aiden From tknchris at gmail.com Mon Oct 3 17:37:16 2011 From: tknchris at gmail.com (chris) Date: Mon, 3 Oct 2011 18:37:16 -0400 Subject: he.net down? In-Reply-To: <20111003223558.GA30417@hothead.caltech.edu> References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: Down here as well chris On Oct 3, 2011 6:36 PM, "Aiden Sullivan" wrote: > www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is > going on? > > -- > Aiden > > From morrowc.lists at gmail.com Mon Oct 3 17:39:30 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Oct 2011 18:39:30 -0400 Subject: he.net down? In-Reply-To: References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: On Mon, Oct 3, 2011 at 6:37 PM, chris wrote: > Down here as well > ~$ ping6 www.he.net PING www.he.net(he.net) 56 data bytes 64 bytes from he.net: icmp_seq=2 ttl=54 time=124 ms > chris > On Oct 3, 2011 6:36 PM, "Aiden Sullivan" wrote: >> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what > is >> going on? >> >> -- >> Aiden >> >> > From tshaw at oitc.com Mon Oct 3 17:46:01 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 3 Oct 2011 18:46:01 -0400 Subject: he.net down? In-Reply-To: References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: <9B29642E-EA4D-4AEC-AA45-866FD5829760@oitc.com> Fine here in FL $ ping6 www.he.net PING6(56=40+8+8 bytes) 2001:470:5:4ed:cabc:c8ff:fea1:560c --> 2001:470:0:76::2 16 bytes from 2001:470:0:76::2, icmp_seq=0 hlim=55 time=178.017 ms On Oct 3, 2011, at 6:39 PM, Christopher Morrow wrote: > On Mon, Oct 3, 2011 at 6:37 PM, chris wrote: >> Down here as well >> > > ~$ ping6 www.he.net > PING www.he.net(he.net) 56 data bytes > 64 bytes from he.net: icmp_seq=2 ttl=54 time=124 ms > >> chris >> On Oct 3, 2011 6:36 PM, "Aiden Sullivan" wrote: >>> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what >> is >>> going on? >>> >>> -- >>> Aiden >>> >>> >> > From hartzell at gmail.com Mon Oct 3 17:54:36 2011 From: hartzell at gmail.com (Dave hartzell) Date: Mon, 3 Oct 2011 15:54:36 -0700 Subject: he.net down? In-Reply-To: References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: My peering with them at PAIX has been down for almost 50 minutes. Not able to get to them via other paths... On Mon, Oct 3, 2011 at 3:37 PM, chris wrote: > Down here as well > > chris > On Oct 3, 2011 6:36 PM, "Aiden Sullivan" wrote: >> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what > is >> going on? >> >> -- >> Aiden >> >> > From patrick at ianai.net Mon Oct 3 17:56:34 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Oct 2011 18:56:34 -0400 Subject: he.net down? In-Reply-To: References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: <80C76380-63AC-482A-A267-E7019FCC9E93@ianai.net> On Oct 3, 2011, at 6:54 PM, Dave hartzell wrote: > My peering with them at PAIX has been down for almost 50 minutes. > > Not able to get to them via other paths... Just posted to outages@ (where this discussion should likely be taking place): HE's entire network is intermittently down. They claim it is a DoS: It is not the first time this week. Mike & the team are good engineers, they'll do what they can to bring it backup quickly. There are lots of other rumors floating around, but I think you should wait for official word. HE is not a telco, they will tell you what happened. (Right Mike? :) -- TTFN, patrick From marka at isc.org Mon Oct 3 18:11:46 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 04 Oct 2011 10:11:46 +1100 Subject: he.net down? In-Reply-To: Your message of "Mon, 03 Oct 2011 18:46:01 EDT." <9B29642E-EA4D-4AEC-AA45-866FD5829760@oitc.com> References: <20111003223558.GA30417@hothead.caltech.edu> <9B29642E-EA4D-4AEC-AA45-866FD5829760@oitc.com> Message-ID: <20111003231146.E9970148F1F1@drugs.dv.isc.org> In message <9B29642E-EA4D-4AEC-AA45-866FD5829760 at oitc.com>, TR Shaw writes: > Fine here in FL > > $ ping6 www.he.net > PING6(56=3D40+8+8 bytes) 2001:470:5:4ed:cabc:c8ff:fea1:560c --> = > 2001:470:0:76::2 > 16 bytes from 2001:470:0:76::2, icmp_seq=3D0 hlim=3D55 time=3D178.017 ms > > On Oct 3, 2011, at 6:39 PM, Christopher Morrow wrote: > > > On Mon, Oct 3, 2011 at 6:37 PM, chris wrote: > >> Down here as well > >>=20 > >=20 > > ~$ ping6 www.he.net > > PING www.he.net(he.net) 56 data bytes > > 64 bytes from he.net: icmp_seq=3D2 ttl=3D54 time=3D124 ms > >=20 > >> chris > >> On Oct 3, 2011 6:36 PM, "Aiden Sullivan" wrote: > >>> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone = > know what > >> is > >>> going on? > >>>=20 > >>> -- > >>> Aiden > >>>=20 > >>>=20 > >>=20 > >=20 Looks like fremont/lax is down which is the normal path to my tunnel endpoint (currently unreachable). There were issue late last week as well. Mark traceroute to 64.71.128.82 (64.71.128.82), 64 hops max, 44 byte packets 1 10.72.0.1 (10.72.0.1) 8.059 ms 6.195 ms 7.196 ms 2 bla1-ge0-0-1.gw.optusnet.com.au (198.142.160.181) 7.895 ms 7.501 ms 8.788 ms 3 bla5-ge2-1.gw.optusnet.com.au (211.29.126.77) 8.692 ms 6.985 ms 7.314 ms 4 203.208.190.85 (203.208.190.85) 162.929 ms 162.457 ms 163.349 ms 5 10gigabitethernet1-3.core1.lax1.he.net (206.223.123.37) 163.099 ms 164.391 ms 174.027 ms 6 10gigabitethernet1-1.core1.phx1.he.net (72.52.92.250) 178.051 ms 173.395 ms 174.653 ms 7 10gigabitethernet1-3.core1.dal1.he.net (72.52.92.254) 197.036 ms 196.807 ms 202.276 ms 8 * 10gigabitethernet4-4.core1.chi1.he.net (184.105.213.118) 223.289 ms 224.630 ms 9 10gigabitethernet3-2.core1.den1.he.net (184.105.213.86) 247.460 ms 247.256 ms * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike at m5computersecurity.com Mon Oct 3 18:14:03 2011 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 3 Oct 2011 23:14:03 +0000 Subject: he.net down? Message-ID: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry> Our session with them is up and down at Any2 at OWB. ------Original Message------ From: Aiden Sullivan To: nanog at nanog.org Subject: he.net down? Sent: Oct 3, 2011 3:35 PM www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is going on? -- Aiden Sent from my Verizon Wireless BlackBerry From paul at paulgraydon.co.uk Mon Oct 3 18:17:25 2011 From: paul at paulgraydon.co.uk (Paul) Date: Mon, 03 Oct 2011 13:17:25 -1000 Subject: he.net down? In-Reply-To: <20111003223558.GA30417@hothead.caltech.edu> References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: <4E8A4285.3040105@paulgraydon.co.uk> On 10/03/2011 12:35 PM, Aiden Sullivan wrote: > www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is > going on? > Linode's Fremont location was effected too, HE are their network providers, was down for about an hour. Paul From nanog at konadogs.net Mon Oct 3 18:25:08 2011 From: nanog at konadogs.net (Nate Itkin) Date: Mon, 3 Oct 2011 13:25:08 -1000 Subject: he.net down? In-Reply-To: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry> References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry> Message-ID: <20111003232508.GA25449@li92-81.konadogs.net> On Mon, Oct 03, 2011 at 11:14:03PM +0000, Michael J McCafferty wrote: > Our session with them is up and down at Any2 at OWB. > > ------Original Message------ > From: Aiden Sullivan > To: nanog at nanog.org > Subject: he.net down? > Sent: Oct 3, 2011 3:35 PM > > www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is > going on? > -- > Aiden > Sent from my Verizon Wireless BlackBerry Blaming DDOS. http://status.linode.com "The incident was a probable DDOS attack, but its behavior was unusual and difficult to identify. Our network engineers made some adjustments to the DOS countermeasures acquired after last week's incident, and that seems to have stabilized traffic flow. We apologize for the inconvenience. -Ben Larsen Hurricane Electric Internet Services" Some supporting evidence would be nice. - Nate Itkin From patrick at ianai.net Mon Oct 3 18:33:10 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Oct 2011 19:33:10 -0400 Subject: he.net down? In-Reply-To: <20111003232508.GA25449@li92-81.konadogs.net> References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry> <20111003232508.GA25449@li92-81.konadogs.net> Message-ID: <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> On Oct 3, 2011, at 7:25 PM, Nate Itkin wrote: > On Mon, Oct 03, 2011 at 11:14:03PM +0000, Michael J McCafferty wrote: >> Our session with them is up and down at Any2 at OWB. >> >> ------Original Message------ >> From: Aiden Sullivan >> To: nanog at nanog.org >> Subject: he.net down? >> Sent: Oct 3, 2011 3:35 PM >> >> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is >> going on? >> -- >> Aiden >> Sent from my Verizon Wireless BlackBerry > > > Blaming DDOS. http://status.linode.com > > "The incident was a probable DDOS attack, but its behavior was unusual and difficult to identify. Our network engineers made some adjustments to the DOS countermeasures acquired after last week's incident, and that seems to have stabilized traffic flow. We apologize for the inconvenience. -Ben Larsen Hurricane Electric Internet Services" > > Some supporting evidence would be nice. Exactly what do you expect a network which is attacked to post to NANOG, or a random web page, to "prove" they were attacked? Given the 1000s of network outages over the last decade, I can think of maybe a handful that supplied "supporting evidence". As I said before, Mike & the gang at HE are stand-up people. If they said it was a DoS, it was a DoS - although I note they did not say it was a DoS, just probably a DoS. But I extend my faith if their lack of prevarication to even statement as well. In fact, it speaks well that they are being equivocal until they are certain themselves. -- TTFN, patrick From brandon.kim at brandontek.com Mon Oct 3 18:38:23 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 3 Oct 2011 19:38:23 -0400 Subject: he.net down? In-Reply-To: <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry>, <20111003232508.GA25449@li92-81.konadogs.net>, <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> Message-ID: Since we're on the topic of DoS. What best practice actions can be taken AFTER such an attack? > Subject: Re: he.net down? > From: patrick at ianai.net > Date: Mon, 3 Oct 2011 19:33:10 -0400 > To: nanog at nanog.org > > On Oct 3, 2011, at 7:25 PM, Nate Itkin wrote: > > On Mon, Oct 03, 2011 at 11:14:03PM +0000, Michael J McCafferty wrote: > >> Our session with them is up and down at Any2 at OWB. > >> > >> ------Original Message------ > >> From: Aiden Sullivan > >> To: nanog at nanog.org > >> Subject: he.net down? > >> Sent: Oct 3, 2011 3:35 PM > >> > >> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is > >> going on? > >> -- > >> Aiden > >> Sent from my Verizon Wireless BlackBerry > > > > > > Blaming DDOS. http://status.linode.com > > > > "The incident was a probable DDOS attack, but its behavior was unusual and difficult to identify. Our network engineers made some adjustments to the DOS countermeasures acquired after last week's incident, and that seems to have stabilized traffic flow. We apologize for the inconvenience. -Ben Larsen Hurricane Electric Internet Services" > > > > Some supporting evidence would be nice. > > Exactly what do you expect a network which is attacked to post to NANOG, or a random web page, to "prove" they were attacked? Given the 1000s of network outages over the last decade, I can think of maybe a handful that supplied "supporting evidence". > > As I said before, Mike & the gang at HE are stand-up people. If they said it was a DoS, it was a DoS - although I note they did not say it was a DoS, just probably a DoS. But I extend my faith if their lack of prevarication to even statement as well. In fact, it speaks well that they are being equivocal until they are certain themselves. > > -- > TTFN, > patrick > > From tom+nanog at oneshoeco.com Mon Oct 3 18:42:39 2011 From: tom+nanog at oneshoeco.com (Tom Lanyon) Date: Tue, 4 Oct 2011 10:12:39 +1030 Subject: he.net down? In-Reply-To: References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry>, <20111003232508.GA25449@li92-81.konadogs.net>, <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> Message-ID: <30429BD5-B74E-4418-9C9E-11839E3BD53E@oneshoeco.com> On 04/10/2011, at 10:08 AM, Brandon Kim wrote: > Since we're on the topic of DoS. What best practice actions can be taken AFTER such an attack? Notifying NANOG/*NOG lists? ;) From sethm at rollernet.us Mon Oct 3 18:46:55 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 03 Oct 2011 16:46:55 -0700 Subject: he.net down? In-Reply-To: References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry>, <20111003232508.GA25449@li92-81.konadogs.net>, <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> Message-ID: <4E8A496F.2000206@rollernet.us> On 10/3/11 4:38 PM, Brandon Kim wrote: > > Since we're on the topic of DoS. What best practice actions can be taken AFTER such an attack? > Wait to hear from Roland. ;) ~Seth From breeve at o1.com Mon Oct 3 18:48:47 2011 From: breeve at o1.com (Blaine Reeve) Date: Mon, 3 Oct 2011 23:48:47 +0000 Subject: he.net down? In-Reply-To: <4E8A496F.2000206@rollernet.us> References: <1918971735-1317683645-cardhu_decombobulator_blackberry.rim.net-704092685-@b1.c3.bise6.blackberry>, <20111003232508.GA25449@li92-81.konadogs.net>, <5186F97B-95D5-4006-AEF9-5D796B2C3347@ianai.net> <4E8A496F.2000206@rollernet.us> Message-ID: We are back up in LAX, 16:39PDT. Hopefully, it stays up. ~ Blaine -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, October 03, 2011 4:47 PM To: nanog at nanog.org Subject: Re: he.net down? On 10/3/11 4:38 PM, Brandon Kim wrote: > > Since we're on the topic of DoS. What best practice actions can be taken AFTER such an attack? > Wait to hear from Roland. ;) ~Seth From mike at m5computersecurity.com Mon Oct 3 19:43:47 2011 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 03 Oct 2011 17:43:47 -0700 Subject: he.net down? In-Reply-To: <4E8A4285.3040105@paulgraydon.co.uk> References: <20111003223558.GA30417@hothead.caltech.edu> <4E8A4285.3040105@paulgraydon.co.uk> Message-ID: <1317689027.3268.10931.camel@mike-desktop> Here's what Linode at Fremont looked like from our network (m5hosting.com) and the Linode sites in Newark, and London. http://smokev.m5hosting.com/smokeping/smokeping.cgi?target=World.USA.Hurricane The smokeping from our network at m5hosting.com is through the Any2 at OWB. On Mon, 2011-10-03 at 13:17 -1000, Paul wrote: > On 10/03/2011 12:35 PM, Aiden Sullivan wrote: > > www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is > > going on? > > > Linode's Fremont location was effected too, HE are their network > providers, was down for about an hour. > > Paul > -- ************************************************************ 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 ops.lists at gmail.com Mon Oct 3 20:08:33 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Oct 2011 06:38:33 +0530 Subject: [arin-announce] Whois Query Behavior is Updated In-Reply-To: References: <4E89072D.80703@arin.net> Message-ID: <2962FC40-B9E3-4CC0-9199-CCB40D14B26E@gmail.com> 'twas a consummation devoutly to be wished .. thanks, mark! --srs(iPad) On 04-Oct-2011, at 2:03, Christopher Morrow wrote: > On Mon, Oct 3, 2011 at 3:11 PM, Mark Kosters wrote: >> Hi >> >> Apologies for the cross post from ARIN-Announce. Thought that many of you >> would be interested in hearing about the recent ARIN Whois change given >> the recent discussion on NANOG. > > thanks! :) > From ebais at A2B-Internet.com Tue Oct 4 00:40:13 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Tue, 4 Oct 2011 07:40:13 +0200 Subject: he.net down? In-Reply-To: <1317689027.3268.10931.camel@mike-desktop> References: <20111003223558.GA30417@hothead.caltech.edu> <4E8A4285.3040105@paulgraydon.co.uk> <1317689027.3268.10931.camel@mike-desktop> Message-ID: Hi Michael, Our smokeping shows a similar thing. http://smokeping.a2b-internet.com/smokeping/?target=US.HE A lot of packetloss around the 30th / 1st on IPv4 while V6 was unaffected. Their support stated it was a fibercut in the usa somewhere. From Amsterdam all shows good and green again. Erik Verstuurd vanaf mijn iPad Op Oct 4, 2011 om 2:43 heeft Michael J McCafferty het volgende geschreven: > > Here's what Linode at Fremont looked like from our network > (m5hosting.com) and the Linode sites in Newark, and London. > > http://smokev.m5hosting.com/smokeping/smokeping.cgi?target=World.USA.Hurricane > > The smokeping from our network at m5hosting.com is through the Any2 at > OWB. > > On Mon, 2011-10-03 at 13:17 -1000, Paul wrote: >> On 10/03/2011 12:35 PM, Aiden Sullivan wrote: >>> www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is >>> going on? >>> >> Linode's Fremont location was effected too, HE are their network >> providers, was down for about an hour. >> >> Paul >> > > -- > ************************************************************ > 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 viraviralh at gmail.com Tue Oct 4 00:57:39 2011 From: viraviralh at gmail.com (Viral Vira) Date: Tue, 4 Oct 2011 11:27:39 +0530 Subject: he.net down? In-Reply-To: <20111003223558.GA30417@hothead.caltech.edu> References: <20111003223558.GA30417@hothead.caltech.edu> Message-ID: Its working fine from India as well... -Thanks, Viral. On 4 October 2011 04:05, Aiden Sullivan wrote: > www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what > is > going on? > > -- > Aiden > > > From bitkraft at gmail.com Tue Oct 4 03:33:53 2011 From: bitkraft at gmail.com (Brian Spade) Date: Tue, 4 Oct 2011 01:33:53 -0700 Subject: events In-Reply-To: <4E861023.7020001@opennms.org> References: <4E861023.7020001@opennms.org> Message-ID: Jeff, When is 1.10 going to be released? thx, /bs On Fri, Sep 30, 2011 at 11:53 AM, Jeff Gehlbach wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/30/2011 09:50 AM, harbor235 wrote: > > > Soalrwinds, splunk, fwanalog, and others come to mind, any other > good ones > > out there? > > We've made some great strides in OpenNMS in the area of syslog event > processing. The upcoming 1.10 release will be much easier to get > going, particularly since we now have pluggable message parsers -- you > no longer need Wireshark and a black belt in regular expressions to > start receiving events from syslog sources. We've also made it > possible to split the syslog rules across multiple files, which makes > maintaining your own rules much easier compared to the old monolithic > style. > > It's still not going to be Splunk-easy to configure, but it's now > darned close to Netcool OMNIbus syslogd probe-easy. Plus you get > pretty JasperReports reports based on your events like this one (or > roll your own): > > http://opennms.org/~jeffg/event-analysis-sample.pdf > > Also flexible event notifications, event de-duplication, and SNMP trap > handling as well as service-assurance polling, performance data > collection via SNMP, HTTP, WMI, SQL/JDBC, and other protocols. > > Oh yeah, it's 100% free / libre / open source software. And you can > get support for it from my employer. > > PR hat off, > - -jeff > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6GEB0ACgkQB3953+hexDrEPACfRzSKZxijkirgVgTA0OTRrGjX > 27IAoJ7Ef0Cv33zRsYVN50YNbL3tVvLq > =5v3H > -----END PGP SIGNATURE----- > > From ben.roeder at sohonet.co.uk Tue Oct 4 04:58:04 2011 From: ben.roeder at sohonet.co.uk (Ben Roeder) Date: Tue, 4 Oct 2011 10:58:04 +0100 Subject: events In-Reply-To: References: Message-ID: <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> Hi Mike, We have used octopussy ( http://www.8pussy.org/dokuwiki/doku.php?id=home yes it is work safe :-) ) with ok results. Have used sec ( simple event correlator http://simple-evcorr.sourceforge.net/ ) to some success in simple cases. Currently having another look at this myself and the following look interesting, but have not deployed them yet http://logstash.net/ http://graylog2.org/about Ben On 30 Sep 2011, at 14:50, harbor235 wrote: > What is everyone using to collect, alert, and analyze syslog data? > I am looking for something that can generate reports as well as support > multiple vendors. We have done some home grown stuff in the past but > would be interested in something that incorprates all the best features. > > Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones > out there? > > > Mike From leigh.porter at ukbroadband.com Tue Oct 4 05:00:47 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 4 Oct 2011 10:00:47 +0000 Subject: events In-Reply-To: <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> References: , <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> Message-ID: 8pussy.org ? -- Leigh Porter On 4 Oct 2011, at 10:59, "Ben Roeder" wrote: > Hi Mike, > We have used octopussy ( http://www.8pussy.org/dokuwiki/doku.php?id=home yes it is work safe :-) ) with ok results. > Have used sec ( simple event correlator http://simple-evcorr.sourceforge.net/ ) to some success in simple cases. > > Currently having another look at this myself and the following look interesting, but have not deployed them yet > http://logstash.net/ > http://graylog2.org/about > > Ben > On 30 Sep 2011, at 14:50, harbor235 wrote: > >> What is everyone using to collect, alert, and analyze syslog data? >> I am looking for something that can generate reports as well as support >> multiple vendors. We have done some home grown stuff in the past but >> would be interested in something that incorprates all the best features. >> >> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones >> out there? >> >> >> Mike > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jml at packetpimp.org Tue Oct 4 09:27:29 2011 From: jml at packetpimp.org (Jason LeBlanc) Date: Tue, 04 Oct 2011 10:27:29 -0400 Subject: events In-Reply-To: <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> References: <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> Message-ID: <4E8B17D1.1010101@packetpimp.org> +1 for SEC, minimal hit on the cpu like most parsing tools, the regexp can be painful but it is fairly extensible. Once you get used to it you'll love it. On 10/04/2011 05:58 AM, Ben Roeder wrote: > Hi Mike, > We have used octopussy ( http://www.8pussy.org/dokuwiki/doku.php?id=home yes it is work safe :-) ) with ok results. > Have used sec ( simple event correlator http://simple-evcorr.sourceforge.net/ ) to some success in simple cases. > > Currently having another look at this myself and the following look interesting, but have not deployed them yet > http://logstash.net/ > http://graylog2.org/about > > Ben > On 30 Sep 2011, at 14:50, harbor235 wrote: > >> What is everyone using to collect, alert, and analyze syslog data? >> I am looking for something that can generate reports as well as support >> multiple vendors. We have done some home grown stuff in the past but >> would be interested in something that incorprates all the best features. >> >> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones >> out there? >> >> >> Mike > > > From bill.pilloud at gmail.com Tue Oct 4 10:28:53 2011 From: bill.pilloud at gmail.com (Bill.Pilloud) Date: Tue, 4 Oct 2011 08:28:53 -0700 Subject: Facebook insecure by design References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> <4E88E923.2000006@bogus.com> <4E88EE42.8000407@bogus.com> Message-ID: <093055FBC670440881925307C4117BF2@digitpc> Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that. ----- Original Message ----- From: "Joel jaeggli" To: "Jimmy Hess" Cc: Sent: Sunday, October 02, 2011 4:05 PM Subject: Re: Facebook insecure by design > On 10/2/11 15:43 , Joel jaeggli wrote: >> On 10/2/11 15:25 , Jimmy Hess wrote: >>> On Sun, Oct 2, 2011 at 4:53 PM, wrote: >>>> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: >>>>> I'm not sure why lack of TLS is considered to be problem with >>>>> Facebook. >>>>> The man in the middle is the other side of the connection, tls or >>>>> otherwise. >>>> Ooh.. subtle. :) >>> >>> Man in the Middle (MITM) is a technical term that refers to a rather >>> specific kind of attack. >>> >>> In this case, I believe the proper term would be just "The man". >>> [Or "Man at the Other End (MATOE)"]; you either trust Facebook with >>> info to send to >>> them or you don't, and network security is only for securing the >>> transportation of that information >>> you opt to send facebook. >> >> alice sends charlie a message using bob's api, bob can observe and >> probably monetize the contents. >> >>> Yes, if Alice sends Bob an encrypted message that Bob can read, and >>> Bob turns out to >>> be untrustworthy, then Bob can sell/re-use the information in an >>> abusive/unapproved way for >>> personal or economic profit. >> >> charlie is probably untrustworthy, bob is probably moreso (mostly > ^ > trustworthy >> because bob has more to lose than charlie), alice isn't cognizant of the >> implications of running charlie's app on bob's platform despite the >> numerous disclaimers she blindly clicked through on the way there. >> >> >> >>> -- >>> -JH >>> >> >> > > From BEJones at semprautilities.com Tue Oct 4 10:34:03 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 4 Oct 2011 08:34:03 -0700 Subject: Synology Disk DS211J In-Reply-To: <5449bd8$62a59bb7$407cb47$@com> References: <5449bd8$62a59bb7$407cb47$@com> Message-ID: Thanks everyone for the input. I've seen some very good responses, and this NANOG newbie appreciates the take... :-) -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Friday, September 30, 2011 1:05 PM To: nanog at nanog.org Subject: Re: Synology Disk DS211J It's updates, I've got a 1511+ here and at the office. It phones home to check for updates. I noticed this the day I got it. Blocked the dst IP and that was the only thing that "broke". Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Pierre-Yves Maunier" Sent: Friday, September 30, 2011 8:32 AM To: "Jones, Barry" Subject: Re: Synology Disk DS211J 2011/9/29 Jones, Barry > Hey all. > A little off topic, but wanted to share... I purchased a home storage > Synology DS1511+. After configuring it on the home net, I did some captures > to look at the protocols, and noticed that the DS1511+ is making outgoing > connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 & 89) on a > regular basis. These addresses are owned by Synology and Chungwa Telecom in > Taiwan. > > So far, I've not been able to find much information on their support sites, > or Synology's wiki, but I wanted to put it out there. > > > Maybe it's for checking new firmware update availability... -- Pierre-Yves Maunier From jra at baylink.com Tue Oct 4 10:38:00 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Oct 2011 11:38:00 -0400 (EDT) Subject: OT: Social Networking, Privacy and Control In-Reply-To: <093055FBC670440881925307C4117BF2@digitpc> Message-ID: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> [ if you were already over this topic, plonk the thread ] ----- Original Message ----- > From: "Bill.Pilloud" > Is this not the nature of social media? If you want to make sure something > is secure (sensitive information), Why is it on social media. If you are > worried about it being monetised, I think Google has already done that. No. Because "sensitive" is a word with different definitions at different times for different people. I don't mind my friends knowing that I (used to) go to Rocky Horror every Saturday night and run around in my underwear. I don't particularly want a potential employer to know that, and I might not want a new girlfriend to know it *immediately*. The promise of Social Networking is *precisely* that it permits this more fine-grained *control* (that's the key word, for those who weren't playing the home game) over the information you disseminate, as opposed to just posting all of it on your blog. *Telling people you're going to provide them that control* and then being sloppy about it -- or worse, purposefully evil -- is the thing that has people up in arms. As usual, the underlying issue is one of trust. Alas, I see no theoretical way that distributed systems like Diaspora *can* provide some of the functions that are core to systems like Facebook, *exactly by virtue* (vice?) of the fact that they are distributed; there is no central Trust Broker. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From BEJones at semprautilities.com Tue Oct 4 10:47:22 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 4 Oct 2011 08:47:22 -0700 Subject: events In-Reply-To: <4E85CA71.6030003@ip-solutions.net> References: <4E85CA71.6030003@ip-solutions.net> Message-ID: A sub question to this would be - is anyone using an app or client that will forward windows OS events to said collector? I've seen Loglogic and others. Was just curious if you've used a small scale version to collect security events - log on, log off, etc...? -----Original Message----- From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] Sent: Friday, September 30, 2011 6:56 AM To: nanog at nanog.org Subject: Re: events It's a bit old but still works well. Russel Fulton and I worked on this when I was down in NZ. You still need to run syslog-ng but this allows you to ignore, warn, alert on logs via regex. http://www.ip-solutions.net/syslog-ng/ Cheers, Harry On 09/30/2011 09:50 AM, harbor235 wrote: > What is everyone using to collect, alert, and analyze syslog data? > I am looking for something that can generate reports as well as support > multiple vendors. We have done some home grown stuff in the past but > would be interested in something that incorprates all the best features. > > Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones > out there? > > > Mike > From jcmurphy at jeffmurphy.org Tue Oct 4 10:50:25 2011 From: jcmurphy at jeffmurphy.org (jeff murphy) Date: Tue, 4 Oct 2011 11:50:25 -0400 Subject: events In-Reply-To: References: <4E85CA71.6030003@ip-solutions.net> Message-ID: <9E925F62-F16A-4B33-949D-29F4F11FD18D@jeffmurphy.org> http://code.google.com/p/eventlog-to-syslog/ On Oct 4, 2011, at 11:47 AM, Jones, Barry wrote: > A sub question to this would be - is anyone using an app or client that will forward windows OS events to said collector? I've seen Loglogic and others. Was just curious if you've used a small scale version to collect security events - log on, log off, etc...? > > -----Original Message----- > From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] > Sent: Friday, September 30, 2011 6:56 AM > To: nanog at nanog.org > Subject: Re: events > > It's a bit old but still works well. Russel Fulton and I worked on this when I was down in NZ. > > You still need to run syslog-ng but this allows you to ignore, warn, alert on logs via regex. > > > http://www.ip-solutions.net/syslog-ng/ > > > Cheers, > Harry > > > > On 09/30/2011 09:50 AM, harbor235 wrote: >> What is everyone using to collect, alert, and analyze syslog data? >> I am looking for something that can generate reports as well as support >> multiple vendors. We have done some home grown stuff in the past but >> would be interested in something that incorprates all the best features. >> >> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones >> out there? >> >> >> Mike >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1972 bytes Desc: not available URL: From betty at newnog.org Tue Oct 4 11:55:35 2011 From: betty at newnog.org (Betty Burke) Date: Tue, 4 Oct 2011 12:55:35 -0400 Subject: [NANOG-announce] NANOG 53 Last Agenda and Registration Reminder Message-ID: Everyone, The last update regarding NANOG 53 Registration and Agenda ! Do not miss out. - Late Registration starting October 4, 2011 (non-member $600, member $575, student $100) - On-Site Registration starting October 9, 2011 (non-member $675, member $650, student $100) - Submit your lightning talk proposal at http://pc.nanog.org starting October 3, 2011. Lightning Talks: A lightning talk is a very short presentation or speech by any attendee on any topic relevant to the NANOG audience. These are limited to ten minutes; this will be strictly enforced. - topic that are timely, interesting, or even a crackpot idea you want to share, we encourage you to consider presenting it. The Program Committee will vote on all Lightning Talk submissions onsite at the meeting, and a submitter will be notified about his or her submission one day prior to the scheduled talk time. See you in Philly! All best. Betty -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 NANOG Direct (510) 492-4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From kurtis at kurtis.pp.se Tue Oct 4 12:15:29 2011 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Tue, 4 Oct 2011 19:15:29 +0200 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> Message-ID: <709036AD-1777-4CEB-A0AE-3119BAE8722C@kurtis.pp.se> On 3 okt 2011, at 16:30, Todd Underwood wrote: > > ignoring randy (and others) off-topic comments about hypocrisy, this > situation is fundamentally a situation of bad (or different) network > policy being applied outside of its scope. i would prefer that china > not censor the internet, sure. but i really require that china not > censor *my* internet when i'm not in china. Most if not all European operators today force rewrite or blocking of DNS lookups. Belgium added a fairly large site today. There is virtually no way that this can be contained just inside a country. This problem is waaaay beyond root-servers, China etc. Filtering on the net is becoming common, and was pushed quite hard for at Interent Governance Forum last week. By Interpol and MPAA. Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cdel at firsthand.net Tue Oct 4 12:35:24 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Tue, 4 Oct 2011 18:35:24 +0100 Subject: OT: Social Networking, Privacy and Control In-Reply-To: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> Message-ID: <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> You know I don't need Facebook to introduce (broker) me to anyone! I am more than happy managing my own relationships (gradations of trust included!) Oh and my friends are distributed in the real world as well! This works pretty well even without a "social network" or a "system". When the Diginotar certification authority was badly compromised I got a bunch of information from many sources using those protocols which span the standards sphere of the Internet each bringing information that I value at varying levels of trust and applicability. Between and in combination of all this input I was able to take action and remove Diginotar from my keychain. I could have waited for Apple to stir its stumps but didn't need to. All those independent distributed "trust brokers" did a fine job! thanks folks! Christian On 4 Oct 2011, at 16:38, Jay Ashworth wrote: > As usual, the underlying issue is one of trust. > > Alas, I see no theoretical way that distributed systems like Diaspora *can* > provide some of the functions that are core to systems like Facebook, *exactly > by virtue* (vice?) of the fact that they are distributed; there is no central > Trust Broker. From zhanna at yahoo-inc.com Tue Oct 4 14:35:15 2011 From: zhanna at yahoo-inc.com (Zachary Hanna) Date: Tue, 4 Oct 2011 12:35:15 -0700 Subject: Over a decade of DDOS--any progress yet? In-Reply-To: <4D081B20.3080408@bogus.com> Message-ID: The NIST has proposed a framework for operators to notify botnet victims. The call for comments and article discussing it are described here: https://www.infosecisland.com/blogview/17021-Government-Proposes-ISPs-Notif y-Victims-of-Botnets.html#.TotXA6C-16Q.twitter "Comments on the proposed Code of Conduct and botnet reporting initiative are due on or before 5 p.m. EDT, November 4, 2011. Written comments on the proposal may be submitted by mail to the National Institute of Standards and Technology at the U.S. Department of Commerce, 1401 Constitution Avenue, NW., Room 4822, Washington, DC 20230. Submissions may be in any of the following formats: HTML, ASCII, Word, rtf, or pdf. Online comment submissions in electronic form may be sent to Consumer_Notice_RFI at nist.gov. Paper submissions should include a compact disc (CD). CDs should be labeled with the name and organizational affiliation of the filer and the name of the word processing program used to create the document. Comments will be posted at http://www.nist.gov/itl/. A list of questions are included in the Request for Information, and can be accessed at the source link below: Source: http://www.federalregister.gov/articles/2011/09/21/2011-24180/models-to-adv ance-voluntary-corporate-notification-to-consumers-regarding-the-illicit-us e-of#p-3 " IMHO this would go a long way to addressing the underlying root cause (botted machines). Regards, Zachary On 12/14/10 5:34 PM, "Joel Jaeggli" wrote: >On 12/8/10 6:30 AM, Drew Weaver wrote: >> Yes, but this obviously completes the 'DDoS attack' and sends the >>signal that the bully will win. > >it's part of a valid mitigation strategy. shifting the target out from >underneath the blackholed address is also part of the activity. that's >easier in some cases than others. the bots will move and you play whack >a rat with your upstreams. > >joel > >> -Drew > >> From: alvaro.sanchez at adinet.com.uy >>[mailto:alvaro.sanchez at adinet.com.uy] >> Sent: Wednesday, December 08, 2010 8:46 AM >> To: rdobbins at arbor.net; North American Operators' Group >> Subject: Re: Over a decade of DDOS--any progress yet? >> >> A very common action is to blackhole ddos traffic upstream by sending a >> bgp route to the next AS with a preestablished community indicating the >> traffic must be sent to Null0. The route may be very specific, in order >> to impact as less as possible. This needs previous coordination between >> providers. >> Regards. >> > From pingwin at gmail.com Tue Oct 4 14:54:14 2011 From: pingwin at gmail.com (Brian Smith) Date: Tue, 04 Oct 2011 15:54:14 -0400 Subject: Nxdomain redirect revenue In-Reply-To: References: <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com> <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com> Message-ID: <4E8B6466.4070004@gmail.com> On 09/27/2011 07:55 PM, Jimmy Hess wrote: > the goal behind this would be integrity, not confidentiality. The > objective of using SSL is not to strongly encrypt data to keep it > secret, it's to apply whatever is necessary to provide a level of > integrity assurance. If all you want is integrity then shouldn't you argue that every computer should operate a DNSSEC validating recursive resolver on the machine? After all that is the point of DNSSEC after all isn't it, the validation of DNS records for endpoint authenticity. Even still SNI isn't even widely supported by the major browsers as I understand it. just my 2c From pingwin at gmail.com Tue Oct 4 14:55:22 2011 From: pingwin at gmail.com (Brian Smith) Date: Tue, 04 Oct 2011 15:55:22 -0400 Subject: Nxdomain redirect revenue In-Reply-To: References: <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com> Message-ID: <4E8B64AA.2030903@gmail.com> +1 to the use of CAA/DANE -brian On 09/27/2011 07:34 PM, Rubens Kuhl wrote: > On Tue, Sep 27, 2011 at 7:29 PM, David E. Smith wrote: >> On Tue, Sep 27, 2011 at 17:08, Jimmy Hess wrote: >>> That is, HTTPs should become assumed. >> As much as that would be wonderful from a security standpoint, IMO >> it's not realistic to expect every mom-and-pop posting a personal Web >> site to pay extra for a static/dedicated IP address from their hosting >> company (even if IPv6 were widely deployed, Web hosts probably would >> charge extra for this just on principle), and to pay extra for an SSL >> certificate, even a "weak" one that only verifies the domain name. > Self-signed certificates published thru DNSSEC using CAA/DANE can cost nothing. > (And somebody else pointed out SNI to have TLS work without exclusive > IP requirement) > > Rubens > From leothelion.murtaza at gmail.com Wed Oct 5 01:39:59 2011 From: leothelion.murtaza at gmail.com (Murtaza) Date: Wed, 5 Oct 2011 17:39:59 +1100 Subject: passive bandwidth estimation Message-ID: Hi everyone, I want to do passive available bandwidth measurement. I was just wandering what tools/techniques people are generally using these days. And is it a good idea to use congestion window as parameter. Ghulam From leigh.porter at ukbroadband.com Wed Oct 5 03:18:07 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 5 Oct 2011 08:18:07 +0000 Subject: passive bandwidth estimation In-Reply-To: References: Message-ID: I used a passive TCP RTT calculator and TCP re-trans monitor to guess the conditions to a host or group of hosts with some success. I the. Derived the network "weather" from this and it worked pretty well to dynamically tune DPI box policing for wireless networks. It also makes cool graphs. Especially if you add other parameters and do it all in various colours. -- Leigh On 5 Oct 2011, at 07:41, "Murtaza" wrote: > Hi everyone, > I want to do passive available bandwidth measurement. I was just wandering > what tools/techniques people are generally using these days. And is it a > good idea to use congestion window as parameter. > Ghulam > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From clapidus at gmail.com Wed Oct 5 06:11:59 2011 From: clapidus at gmail.com (Claudio Lapidus) Date: Wed, 5 Oct 2011 08:11:59 -0300 Subject: DPI deployment use case Message-ID: Hello all, We have had a number of DPI boxes (SCE8080) sitting in the access network for a while now, so far they served mainly for congestion management and such, and are wondering if there are some real use case in the fine-grained service control land (as the vendors keep whispering in out ears...) Anyway, we are reviewing a couple of service manager solutions, but I would like to hear from you operators, what actual use cases have you seen in the field (if any) for DPI'ing user sessions, considering we are mostly a DSL shop. thanks in advance, cl. From positivelyoptimistic at gmail.com Wed Oct 5 09:05:06 2011 From: positivelyoptimistic at gmail.com (Positively Optimistic) Date: Wed, 5 Oct 2011 09:05:06 -0500 Subject: Looking Glass Functionality Message-ID: Greetings Does anyone know of a off-the-self product that provides looking glass functionality for a network ? Many thanks, -Optimistic From eric-list at truenet.com Wed Oct 5 09:41:42 2011 From: eric-list at truenet.com (Eric Tykwinski) Date: Wed, 5 Oct 2011 10:41:42 -0400 Subject: Email administrator for Comcast Philadelphia region? Message-ID: <00ff01cc836c$e64797e0$b2d6c7a0$@truenet.com> If there is anyone lurking on the list, we are having some strange issues with one of your clients. Please contact offlist. (support at truenet.com) Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 From jeffg at opennms.org Wed Oct 5 10:09:29 2011 From: jeffg at opennms.org (Jeff Gehlbach) Date: Wed, 05 Oct 2011 08:09:29 -0700 Subject: events In-Reply-To: References: <4E861023.7020001@opennms.org> Message-ID: <4E8C7329.8020005@opennms.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/2011 01:33 AM, Brian Spade wrote: > When is [OpenNMS] 1.10 going to be released? When it's done :) Most likely this month. The unit tests are failing right now: http://bamboo.internal.opennms.com:8085/ But that means that we know where the bugs are :) The 1.9.91 (aka 1.10.0rc2) release is quite solid, and we hope that Tuesday's 1.9.92 (RC3) will be the final release candidate. If you give it a try and run into trouble, be sure to hit the project mailing lists and IRC channel. - -jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6McyQACgkQB3953+hexDrOyQCgqu/MGMXAhfREgwytLkSpq9yQ SLYAn3RWWmvGMi06Hbl1062zoqXTinM8 =13RE -----END PGP SIGNATURE----- From pixitha.kyle at gmail.com Wed Oct 5 10:20:34 2011 From: pixitha.kyle at gmail.com (Kyle Duren) Date: Wed, 5 Oct 2011 08:20:34 -0700 Subject: Looking Glass Functionality In-Reply-To: References: Message-ID: http://mrlg.op-sec.us/ Its not quite off the shelf, but I found it easier to deploy than anything else I found. -Kyle On Wed, Oct 5, 2011 at 7:05 AM, Positively Optimistic < positivelyoptimistic at gmail.com> wrote: > Greetings > Does anyone know of a off-the-self product that provides looking glass > functionality for a network ? > > Many thanks, > -Optimistic > From michael at rancid.berkeley.edu Wed Oct 5 12:05:07 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 05 Oct 2011 10:05:07 -0700 Subject: DNSSEC in China Message-ID: <4E8C8E43.6030204@rancid.berkeley.edu> The thread on f-root reminded my of an anecdotal datum regarding DNSSEC in China. I was in China back in August, staying at the Green Lake Hotel in Kunming, Yunnan Provence. When connecting to the hotel in-room network (there was no wireless but a wired connection), I was able to properly validate DNSSEC for names like www.es.net and berkeley.edu, both of which are part of signed zones with a chain of trust from the root. I was able to do the validation on my caching resolver (BIND 9.8.x) running on my laptop. If a site was blocked by authorities, I couldn't resolve it at all, but that was also the case even if I wasn't doing validation on my laptop resolver, but instead using the resolver provided by DHCP. (FYI, I "stumbled" upon an expat bar later in my trip near Yunnan Provincial University and the folks there--Europeans and Americans--all said that the number of sites they can get to has expanded in recent months. One Finn was accessing the Guardian to get the latest on the London riots.) Another anecdote from NANOG 52: At the Denver Sheraton, I was unable to validate or resolve any name using my local laptop resolver. I couldn't even validate TLDs or dlv.isc.org, so *all* of my name resolution broke. In the end, I had to disable my local resolver entirely and use those provided by DHCP. I have nothing to say about hypocrisy or the relative level of oppression between the Chinese government versus the Starwood Group (although it's humorous to think about). What I will say is that DNSSEC made it very clear in the case of the Sheraton that they were messing with DNS because DNSSEC made the handcuffs so obviously tight. michael From strizhov at netsec.colostate.edu Wed Oct 5 12:10:03 2011 From: strizhov at netsec.colostate.edu (Mikhail Strizhov) Date: Wed, 05 Oct 2011 11:10:03 -0600 Subject: RADB/RIR Scraper In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH> Message-ID: <4E8C8F6B.1020700@netsec.colostate.edu> A little bit of topic, but is there a way to get the prefix list and AS number using the description in RADB/others? For example, for "Commonwealth Bank of Australia" I want to get the following route: 203.202.158.0/24 descr: Commonwealth Bank of Australia origin: AS7474 mnt-by: MAINT-AS7474 changed: noc at optus.net.au 20080918 source: RADB Thanks. From joelja at bogus.com Wed Oct 5 12:12:44 2011 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 05 Oct 2011 10:12:44 -0700 Subject: DNSSEC in China In-Reply-To: <4E8C8E43.6030204@rancid.berkeley.edu> References: <4E8C8E43.6030204@rancid.berkeley.edu> Message-ID: <4E8C900C.5090301@bogus.com> On 10/5/11 10:05 , Michael Sinatra wrote: > The thread on f-root reminded my of an anecdotal datum regarding DNSSEC > in China. I was in China back in August, staying at the Green Lake > Hotel in Kunming, Yunnan Provence. When connecting to the hotel in-room > network (there was no wireless but a wired connection), I was able to > properly validate DNSSEC for names like www.es.net and berkeley.edu, > both of which are part of signed zones with a chain of trust from the > root. I was able to do the validation on my caching resolver (BIND > 9.8.x) running on my laptop. > > If a site was blocked by authorities, I couldn't resolve it at all, but > that was also the case even if I wasn't doing validation on my laptop > resolver, but instead using the resolver provided by DHCP. (FYI, I > "stumbled" upon an expat bar later in my trip near Yunnan Provincial > University and the folks there--Europeans and Americans--all said that > the number of sites they can get to has expanded in recent months. One > Finn was accessing the Guardian to get the latest on the London riots.) > > Another anecdote from NANOG 52: At the Denver Sheraton, I was unable to > validate or resolve any name using my local laptop resolver. I couldn't > even validate TLDs or dlv.isc.org, so *all* of my name resolution broke. > In the end, I had to disable my local resolver entirely and use those > provided by DHCP. > > I have nothing to say about hypocrisy or the relative level of > oppression between the Chinese government versus the Starwood Group > (although it's humorous to think about). What I will say is that DNSSEC > made it very clear in the case of the Sheraton that they were messing > with DNS because DNSSEC made the handcuffs so obviously tight. "Nomadix developed DAT to actively monitor every packet transmitted from each device to ensure all packets are correctly configured for the network. If necessary, DAT will perform standard Network and Port Address Translation and supports Application Level Gateways (ALGs) for protocols such as FTP, H.323, PPTP, IPSec, and others. DAT also ensures that a DNS server is always available to a user through the DNS redirection function. This function redirects a user?s DNS requests to a local DNS server closer to the customer?s location?improving the response time and enabling true plug-and-play access when the subscriber?s configured DNS server is behind a firewall or located on a private Intranet. Transparent proxy assures that subscribers who have proxy configured to work with their native network get broadband access in the HotZone." http://www.nomadix.com/telecom_advantage.php > michael > From pixitha.kyle at gmail.com Wed Oct 5 12:15:44 2011 From: pixitha.kyle at gmail.com (Kyle Duren) Date: Wed, 5 Oct 2011 10:15:44 -0700 Subject: RADB/RIR Scraper In-Reply-To: <4E8C8F6B.1020700@netsec.colostate.edu> References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH> <4E8C8F6B.1020700@netsec.colostate.edu> Message-ID: I've always found it helpful to use the "inverse query by" feature, where you can query for any object that has x "mnt-by" or "origin" and it will list any objects with that mnt-by or origin you query for. RADB has this built directly into the Advanced Object Query form on the website. -Kyle On Wed, Oct 5, 2011 at 10:10 AM, Mikhail Strizhov < strizhov at netsec.colostate.edu> wrote: > A little bit of topic, but is there a way to get the prefix list and AS > number using the description in RADB/others? > For example, for "Commonwealth Bank of Australia" I want to get the > following > > route: 203.202.158.0/24 > descr: Commonwealth Bank of Australia > origin: AS7474 > mnt-by: MAINT-AS7474 > changed: noc at optus.net.au 20080918 > source: RADB > > Thanks. > > From eric at opticfusion.net Wed Oct 5 12:59:52 2011 From: eric at opticfusion.net (Eric Stockwell) Date: Wed, 05 Oct 2011 10:59:52 -0700 Subject: Looking Glass Functionality In-Reply-To: References: Message-ID: <4E8C9B18.9040602@opticfusion.net> OpenBSD does, see "man 8 bgplg". Eric Stockwell Optic Fusion On 10/05/2011 07:05 AM, Positively Optimistic wrote: > Greetings > Does anyone know of a off-the-self product that provides looking glass > functionality for a network ? > > Many thanks, > -Optimistic From jamel at cin.ufpe.br Wed Oct 5 13:42:21 2011 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Wed, 5 Oct 2011 15:42:21 -0300 Subject: TEDB Message-ID: Hi, Does anyone know of any Traffic Engineering database or trace available somewhere? Thanks, Djamel From tbiehn at gmail.com Wed Oct 5 13:48:04 2011 From: tbiehn at gmail.com (Travis Biehn) Date: Wed, 5 Oct 2011 14:48:04 -0400 Subject: OT: Social Networking, Privacy and Control In-Reply-To: <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> Message-ID: At the end of the day Social Networks just want to make interactions as natural as possible so they can continue to mine and monetize your relationship data as you get more comfortable sharing the 'real you.' Anyone who hasn't and has an interest in privacy, graph and content ownership on social networks should check out the Diaspora project. -Travis On Tue, Oct 4, 2011 at 1:35 PM, Christian de Larrinaga wrote: > You know I don't need Facebook to introduce (broker) me to anyone! I am > more than happy managing my own relationships (gradations of trust > included!) Oh and my friends are distributed in the real world as well! > > This works pretty well even without a "social network" or a "system". When > the Diginotar certification authority was badly compromised I got a bunch of > information from many sources using those protocols which span the standards > sphere of the Internet each bringing information that I value at varying > levels of trust and applicability. Between and in combination of all this > input I was able to take action and remove Diginotar from my keychain. I > could have waited for Apple to stir its stumps but didn't need to. > > All those independent distributed "trust brokers" did a fine job! > > thanks folks! > > > > Christian > > > > On 4 Oct 2011, at 16:38, Jay Ashworth wrote: > > > As usual, the underlying issue is one of trust. > > > > Alas, I see no theoretical way that distributed systems like Diaspora > *can* > > provide some of the functions that are core to systems like Facebook, > *exactly > > by virtue* (vice?) of the fact that they are distributed; there is no > central > > Trust Broker. > > > -- Twitter | LinkedIn| GitHub | TravisBiehn.com From Timothy.Green at ManTech.com Wed Oct 5 14:16:02 2011 From: Timothy.Green at ManTech.com (Green, Timothy) Date: Wed, 5 Oct 2011 15:16:02 -0400 Subject: Config files? In-Reply-To: References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> Message-ID: Hey all! I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. I have some experience in networking but nothing like what is mostly talked about on here. I just love the talks you experts have and researching the tools you all mention. I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday! I'm trying to put a baseline policy together for all my network equipment and I have a few questions: 1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere? 2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite. 3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice? 4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane! If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction. Thanks in advance! TG From eosterweil at verisign.com Wed Oct 5 15:08:02 2011 From: eosterweil at verisign.com (Eric Osterweil) Date: Wed, 5 Oct 2011 16:08:02 -0400 Subject: F.ROOT-SERVERS.NET moved to Beijing? In-Reply-To: References: <20111002190835.GA17278@ussenterprise.ufp.org> <240436.1317592969@turing-police.cc.vt.edu> <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net> <20111003152001.GA65695@ussenterprise.ufp.org> <5AA6B83A-EC11-48A7-8EE0-50A85F5B85EA@tcb.net> <20111003173431.GA71928@ussenterprise.ufp.org> Message-ID: <13E79CDC-4F5C-4659-A86B-671D560332BD@verisign.com> On Oct 3, 2011, at 2:44 PM, Martin Millnert wrote: > Leo, > > On Mon, Oct 3, 2011 at 7:34 PM, Leo Bicknell wrote: >> > > This sounds an awfully lot like the notary concept: > - http://perspectives-project.org/ > - http://convergence.io/ > > Furthermore, changing network paths used to reach information probably > should not be reason to shut down a service, in general. More > interesting than which path is used, I suppose, is whether or not the > data being returned has been changed in some unexpected/undesired way. Actually, some other related work that's been around for 3-6 years includes: - http://vantage-points.org/ - http://secspider.cs.ucla.edu/ The former has a tech report (listed on its page, http://techreports.verisignlabs.com/tr-lookup.cgi?trid=1110001 ) that presents candidate closed form analysis of how much faith you can gain using network path diversity. Eric From bill at herrin.us Wed Oct 5 18:10:05 2011 From: bill at herrin.us (William Herrin) Date: Wed, 5 Oct 2011 19:10:05 -0400 Subject: Config files? In-Reply-To: References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> Message-ID: On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy wrote: > 1. ?Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere? Hi Timothy, STIGs are a DoD thing. http://iase.disa.mil/stigs/. They're not particularly relevant to public Internet operations. In a few cases they're not particularly sane. (Manually install the latest bleeding edge version of OpenSSL whose bugs have not yet been found and whose API is incompatible with every linked app in the OS? Really?) > 2. ?Are config file change alerts necessary for the security of network equipment? ?We have just purchased the SolarWinds suite. Depends on the configuration. If it's one that rarely changes, it's not a bad idea. But don't saturate yourself with alerts or you'll misinterpret or ignore the important ones. > 3. ?Should we obfuscate our Private addresses on our Network Diagram? ?What is the common practice? It depends. My personal predilection is that IP addresses belong in configurations while explanation and structure belong on network diagrams so I rarely reach the question of whether there's also security value in removing the IP addresses from the pretty pictures. > 4. ?How can I get a grip on my ACLs or is it even possible? ?How do you all maintain them without going insane! Simplify. Don't overdo it. Do you really need ACLs for 100 popular trojan horse TCP ports? The 500 outbound port whitelist? If your security is so complex you can't understand it then it almost certainly isn't secure. If you have a particular subsystem with special needs, it never hurts to give it its own firewall so you can strip the related complexity from your main firewall. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ray at oneunified.net Wed Oct 5 18:33:25 2011 From: ray at oneunified.net (Raymond Burkholder) Date: Wed, 5 Oct 2011 20:33:25 -0300 Subject: Looking Glass Functionality In-Reply-To: References: Message-ID: <000001cc83b7$2e7a42c0$8b6ec840$@oneunified.net> > Does anyone know of a off-the-self product that provides looking glass > functionality for a network ? RANCID at shrubbery.net has a looking glass script. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From paul4004 at gmail.com Wed Oct 5 19:10:36 2011 From: paul4004 at gmail.com (PC) Date: Wed, 5 Oct 2011 18:10:36 -0600 Subject: events In-Reply-To: <4E8B17D1.1010101@packetpimp.org> References: <09B27B5B-0C68-4263-BA3F-DFB4C80E4BEF@sohonet.co.uk> <4E8B17D1.1010101@packetpimp.org> Message-ID: I've tried quite a few solutions. And the solution that works for engineers who know linux and text parsing, is often ill-suited to many operations folks. I have to admit, Splunk is nice and I prefer it, but the price it outrageous. If I'm logging from 500 routers/switches, I can likely get away with a reasonable 5gb/day license. However, any firewall logging per-connection statistics towards anything reasonably busy will quickly chew through the 5gb in no time with a single device, and I don't like paying more in software licensing to log than I did for the firewall itself. This, combined with the removal of e-mail alerts in the 4.0 version when upgrading from 3.0 resulting in breakage without warning and no downgrade path, irked me. So that solution is out. I've also heard of a coworker liking a solution called PHP-SYSLOG-NG. It's claim to fame was putting the events in a database so they are easily and quickly searchable. I didn't explore it further when I looked about a year ago, as it was clear further development had ceased as the author had turned it into a commercial solution called logzilla. I haven't explored pricing. I now use SEC/simple event coorelator linked by someone below. It works adequately well if you can write a REGEX which matches what you're watching for and an output action. Performance is acceptable, but there is some hit. However, it can keep the logs available in text file format which is nice for data parsing with command line tools for certain cases, where many of the database alternatives don't. The one thing SEC is missing that I would enjoy, is a community based rules database for common alerts in network products. I believe there are adequate open source solutions, but the best seem to be the commercial products, IMHO. On Tue, Oct 4, 2011 at 8:27 AM, Jason LeBlanc wrote: > +1 for SEC, minimal hit on the cpu like most parsing tools, the regexp can > be painful but it is fairly extensible. Once you get used to it you'll love > it. > > > On 10/04/2011 05:58 AM, Ben Roeder wrote: > >> Hi Mike, >> We have used octopussy ( http://www.8pussy.org/** >> dokuwiki/doku.php?id=home yes it is work safe :-) ) with ok results. >> Have used sec ( simple event correlator http://simple-evcorr.** >> sourceforge.net/ ) to some >> success in simple cases. >> >> Currently having another look at this myself and the following look >> interesting, but have not deployed them yet >> http://logstash.net/ >> http://graylog2.org/about >> >> Ben >> On 30 Sep 2011, at 14:50, harbor235 wrote: >> >> What is everyone using to collect, alert, and analyze syslog data? >>> I am looking for something that can generate reports as well as support >>> multiple vendors. We have done some home grown stuff in the past but >>> would be interested in something that incorprates all the best features. >>> >>> Soalrwinds, splunk, fwanalog, and others come to mind, any other good >>> ones >>> out there? >>> >>> >>> Mike >>> >> >> >> >> > From D.Reak at F5.com Wed Oct 5 19:13:44 2011 From: D.Reak at F5.com (Dennis Reak) Date: Thu, 6 Oct 2011 00:13:44 +0000 Subject: No subject Message-ID: From alex at corp.nac.net Wed Oct 5 19:15:02 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 5 Oct 2011 20:15:02 -0400 Subject: Steve Jobs has died Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Not entirely on-list-topic, but still relevant. http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-steve-jobs-dies/?tag=cnetRiver From jim at miltonsecurity.com Wed Oct 5 19:25:27 2011 From: jim at miltonsecurity.com (James McMurry) Date: Wed, 5 Oct 2011 17:25:27 -0700 Subject: Steve Jobs has died In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <63BDA271-EDA6-43BA-BE5F-074BA1D9AF7E@miltonsecurity.com> "Don't be trapped by dogma. Have the courage to follow your heart and intuition. Everything else is secondary." - Steve Jobs 2005 You will be missed. From wolfric1 at gmail.com Wed Oct 5 19:34:25 2011 From: wolfric1 at gmail.com (Wolfric) Date: Thu, 6 Oct 2011 01:34:25 +0100 Subject: Steve Jobs has died In-Reply-To: <63BDA271-EDA6-43BA-BE5F-074BA1D9AF7E@miltonsecurity.com> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> <63BDA271-EDA6-43BA-BE5F-074BA1D9AF7E@miltonsecurity.com> Message-ID: http://www.apple.com/stevejobs/ On Thu, Oct 6, 2011 at 1:25 AM, James McMurry wrote: > "Don't be trapped by dogma. Have the courage to follow your heart and intuition. Everything else is secondary." - Steve Jobs 2005 > > You will be missed. From andrew.wallace at rocketmail.com Wed Oct 5 19:40:55 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 5 Oct 2011 17:40:55 -0700 (PDT) Subject: Steve Jobs has died In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <1317861655.94363.YahooMailNeo@web59609.mail.ac4.yahoo.com> Sad day for all concerned in the tech industry. RIP Andrew ________________________________ From: Alex Rubenstein To: 'NANOG list' Sent: Thursday, October 6, 2011 1:15 AM Subject: Steve Jobs has died Not entirely on-list-topic, but still relevant. http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-steve-jobs-dies/?tag=cnetRiver From rfinnesey at gmail.com Wed Oct 5 19:42:06 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Wed, 5 Oct 2011 20:42:06 -0400 Subject: Steve Jobs has died In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: Sad day for all. He will be missed -----Original Message----- From: Alex Rubenstein [mailto:alex at corp.nac.net] Sent: Wednesday, October 05, 2011 8:15 PM To: 'NANOG list' Subject: Steve Jobs has died Not entirely on-list-topic, but still relevant. http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-stev e-jobs-dies/?tag=cnetRiver From aaron at heyaaron.com Wed Oct 5 20:32:49 2011 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 5 Oct 2011 18:32:49 -0700 Subject: Steve Jobs has died In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: I remember the first 'real' program I wrote waay back in 1985 on an Apple IIe. It was a very simple reminder program that would show me my todo list for the day. Wonder if they'll be holding an iPhone-camera-flash-bulb vigil outside the Apple stores. ;) -A On Wed, Oct 5, 2011 at 17:42, Ryan Finnesey wrote: > Sad day for all. ?He will be missed > > -----Original Message----- > From: Alex Rubenstein [mailto:alex at corp.nac.net] > Sent: Wednesday, October 05, 2011 8:15 PM > To: 'NANOG list' > Subject: Steve Jobs has died > > Not entirely on-list-topic, but still relevant. > > > http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-stev > e-jobs-dies/?tag=cnetRiver > > > > > > > From packetjockey at gmail.com Wed Oct 5 20:33:31 2011 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Wed, 5 Oct 2011 21:33:31 -0400 Subject: Looking Glass Functionality In-Reply-To: References: Message-ID: I'm currently considering this one: https://github.com/Cougar/lg On Wed, Oct 5, 2011 at 10:05 AM, Positively Optimistic < positivelyoptimistic at gmail.com> wrote: > Greetings > Does anyone know of a off-the-self product that provides looking glass > functionality for a network ? > > Many thanks, > -Optimistic > From nccariaga at stluke.com.ph Wed Oct 5 21:20:35 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Thu, 06 Oct 2011 10:20:35 +0800 Subject: status of cable breaks in Asia (IAC, C2C, AAG) Message-ID: <4E8D1073.9040501@stluke.com.ph> Hi, Just wondering if anyone here have an idea on the restoration efforts of IAC, C2C, AAG Cable systems? Thanks! -- -nathan From leothelion.murtaza at gmail.com Wed Oct 5 23:29:39 2011 From: leothelion.murtaza at gmail.com (Murtaza) Date: Thu, 6 Oct 2011 15:29:39 +1100 Subject: passive bandwidth estimation In-Reply-To: References: Message-ID: I am more interested in getting an "Available Bandwidth" estimator. Due to this available bandwidth, I am interested in congestion window. As whenever congestion window goes to half it means the data rate has gone to its upper limit. I want to use this particular property of congestion window to calculate bandwidth. Any idea how can one do bandwidth measurement based on this? Thanks a lot, Ghulam On Wed, Oct 5, 2011 at 7:18 PM, Leigh Porter wrote: > I used a passive TCP RTT calculator and TCP re-trans monitor to guess the > conditions to a host or group of hosts with some success. I the. Derived the > network "weather" from this and it worked pretty well to dynamically tune > DPI box policing for wireless networks. > > It also makes cool graphs. Especially if you add other parameters and do it > all in various colours. > > -- > Leigh > > > On 5 Oct 2011, at 07:41, "Murtaza" wrote: > > > Hi everyone, > > I want to do passive available bandwidth measurement. I was just > wandering > > what tools/techniques people are generally using these days. And is it a > > good idea to use congestion window as parameter. > > Ghulam > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From randy at psg.com Wed Oct 5 23:46:07 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Oct 2011 13:46:07 +0900 Subject: passive bandwidth estimation In-Reply-To: References: Message-ID: > I am more interested in getting an "Available Bandwidth" estimator. Due to > this available bandwidth, I am interested in congestion window. As whenever > congestion window goes to half it means the data rate has gone to its upper > limit. I want to use this particular property of congestion window to > calculate bandwidth. > Any idea how can one do bandwidth measurement based on this? vern paxson did extensive work in this area. van jacobson too. randy From vern at ee.lbl.gov Thu Oct 6 00:49:24 2011 From: vern at ee.lbl.gov (vern at ee.lbl.gov) Date: Wed, 05 Oct 2011 22:49:24 -0700 Subject: passive bandwidth estimation In-Reply-To: (Thu, 06 Oct 2011 13:46:07 +0900). Message-ID: <20111006054924.50AE02C4009@rock.ICSI.Berkeley.EDU> > > Any idea how can one do bandwidth measurement based on this? > > vern paxson did extensive work in this area. van jacobson too. For more recent work, see the papers of Constantine Dovrolis. (Likely others, too, but that's the work that comes immediately to mind.) Vern From leothelion.murtaza at gmail.com Thu Oct 6 03:00:37 2011 From: leothelion.murtaza at gmail.com (Murtaza) Date: Thu, 6 Oct 2011 19:00:37 +1100 Subject: passive bandwidth estimation In-Reply-To: References: Message-ID: Thanks a lot for referring to such valuable resources. However, the problem is that these are active measurement tools. Anyways, I will keep on looking and will post if I'll find a good passive measurement solution. Regards, Ghulam On Thu, Oct 6, 2011 at 6:26 PM, Ricardo Oliveira wrote: > http://www.icir.org/models/tools.html > > --Ricardo > > On Oct 4, 2011, at 11:39 PM, Murtaza wrote: > > > Hi everyone, > > I want to do passive available bandwidth measurement. I was just > wandering > > what tools/techniques people are generally using these days. And is it a > > good idea to use congestion window as parameter. > > Ghulam > > From tayeb.meftah at gmail.com Thu Oct 6 03:23:35 2011 From: tayeb.meftah at gmail.com (Tayeb Meftah) Date: Thu, 6 Oct 2011 10:23:35 +0200 Subject: Steve Jobs has died In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <5094959502807675854@unknownmsgid> If no Steve ? blind man can not use iPhone Envoy? de mon iPhone Le 6 oct. 2011 ? 03:33, "Aaron C. de Bruyn" a ?crit : > I remember the first 'real' program I wrote waay back in 1985 on an > Apple IIe. It was a very simple reminder program that would show me my > todo list for the day. > > Wonder if they'll be holding an iPhone-camera-flash-bulb vigil outside > the Apple stores. ;) > > -A > > > On Wed, Oct 5, 2011 at 17:42, Ryan Finnesey wrote: >> Sad day for all. He will be missed >> >> -----Original Message----- >> From: Alex Rubenstein [mailto:alex at corp.nac.net] >> Sent: Wednesday, October 05, 2011 8:15 PM >> To: 'NANOG list' >> Subject: Steve Jobs has died >> >> Not entirely on-list-topic, but still relevant. >> >> >> http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-stev >> e-jobs-dies/?tag=cnetRiver >> >> >> >> >> >> >> > From tayeb.meftah at gmail.com Thu Oct 6 03:26:54 2011 From: tayeb.meftah at gmail.com (Tayeb Meftah) Date: Thu, 6 Oct 2011 10:26:54 +0200 Subject: In-Reply-To: References: Message-ID: <-1618265497594980689@unknownmsgid> Whhat ??? Envoy? de mon iPhone Le 6 oct. 2011 ? 02:14, Dennis Reak a ?crit : > > From ahebert at pubnix.net Thu Oct 6 05:30:07 2011 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 06 Oct 2011 06:30:07 -0400 Subject: Looking Glass Functionality In-Reply-To: References: Message-ID: <4E8D832F.10205@pubnix.net> Depend on what you need... This one still works: http://freshmeat.net/projects/lg/ There an example to route-views: http://www.metrooptic.com/support/lg/index.cgi Contact me offlist if you want an example of the .conf file. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 10/05/11 10:05, Positively Optimistic wrote: > Greetings > Does anyone know of a off-the-self product that provides looking glass > functionality for a network ? > > Many thanks, > -Optimistic > From james at freedomnet.co.nz Thu Oct 6 09:02:35 2011 From: james at freedomnet.co.nz (James Jones) Date: Thu, 6 Oct 2011 10:02:35 -0400 Subject: Steve Jobs has died In-Reply-To: <5094959502807675854@unknownmsgid> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> <5094959502807675854@unknownmsgid> Message-ID: Steve Jobs passing is very sad and has affected me more than I thought it would. He was and still will be in many regards the gold standard on which innovators in the world of technology will be measured. He has had an effect on many aspects of the world we live in today. You can see the ripple effects of what two guys and some ICs in a garage did so long ago. You can see his influence not only in the technology we use today but in corporate culture, media, art and social interaction. He was a man of passion and conviction. That is why he succeeded. He was unyielding to what he thought was the right way to do something. This may have cause many to think that he was a "Jerk" or "Hard to work with", but it was those passions for doing it right that made him and Apple a success. I am not trying to say that it was all swings and roundabouts, but if you were watching you could see that as Steve grew up so did Apple. In the end I think he got mostly right. Apple please keep Steve's legacy going. Still keep innovating and don't be afraid to take chances. I wish the best for Steve's family. Steve you will be missed. God's speed. On Thu, Oct 6, 2011 at 4:23 AM, Tayeb Meftah wrote: > If no Steve ? blind man can not use iPhone > > > Envoy? de mon iPhone > > Le 6 oct. 2011 ? 03:33, "Aaron C. de Bruyn" a ?crit : > > > I remember the first 'real' program I wrote waay back in 1985 on an > > Apple IIe. It was a very simple reminder program that would show me my > > todo list for the day. > > > > Wonder if they'll be holding an iPhone-camera-flash-bulb vigil outside > > the Apple stores. ;) > > > > -A > > > > > > On Wed, Oct 5, 2011 at 17:42, Ryan Finnesey wrote: > >> Sad day for all. He will be missed > >> > >> -----Original Message----- > >> From: Alex Rubenstein [mailto:alex at corp.nac.net] > >> Sent: Wednesday, October 05, 2011 8:15 PM > >> To: 'NANOG list' > >> Subject: Steve Jobs has died > >> > >> Not entirely on-list-topic, but still relevant. > >> > >> > >> > http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-stev > >> e-jobs-dies/?tag=cnetRiver > >> > >> > >> > >> > >> > >> > >> > > > > From jcdill.lists at gmail.com Thu Oct 6 11:10:58 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 06 Oct 2011 09:10:58 -0700 Subject: Steve Jobs has died In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <4E8DD312.6040800@gmail.com> On 05/10/11 5:15 PM, Alex Rubenstein wrote: > Not entirely on-list-topic, but still relevant. I heard the news while in my car - I turned on the radio and they were in the middle of listing major Apple innovations and I realized it must be a Steve Jobs obit. Then they said he was 56. Suddenly I recalled the passing of Jon Postel. Two great minds who both had a large effect on our industry, and who were both taken far too young. RIP. jc From surfer at mauigateway.com Thu Oct 6 14:56:17 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 6 Oct 2011 12:56:17 -0700 Subject: passive bandwidth estimation Message-ID: <20111006125617.9066766A@resin14.mta.everyone.net> --- vern at ee.lbl.gov wrote: > > Any idea how can one do bandwidth measurement based on this? > > vern paxson did extensive work in this area. van jacobson too. For more recent work, see the papers of Constantine Dovrolis. (Likely others, too, but that's the work that comes immediately to mind.) ---------------------------------------------------- For the interested; a shortcut... I went looking and found: http://www.cc.gatech.edu/~dovrolis/publications-area.html Under the "Network bandwidth estimation: capacity, available bandwidth and per-link measurements" heading I found "Available bandwidth measurement as simple as running wget". wget? heh. Looks like a fun read! :-) scott From millnert at gmail.com Thu Oct 6 18:00:34 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 7 Oct 2011 01:00:34 +0200 Subject: DPI deployment use case In-Reply-To: References: Message-ID: Hi, On Wed, Oct 5, 2011 at 1:11 PM, Claudio Lapidus wrote: > what actual use cases have you seen in the field (if any) for DPI'ing user sessions, > considering we are mostly a DSL shop. I've seen tyrannical governments use Bluecoat's to crack down on their own population(*). Was this the sort of use-case you were looking for? :) Best, Martin (*) http://tcxsyria.ceops.eu/95191b161149135ba7bf6936e01bc3bb From brett at the-watsons.org Thu Oct 6 18:58:17 2011 From: brett at the-watsons.org (Brett Watson) Date: Thu, 6 Oct 2011 16:58:17 -0700 Subject: Not operational, but related to the attendees in Philly Message-ID: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> I'm getting a rash of emails (as are some of my colleagues at work that are attending in Philly) from vendors that act like they know me, and just want to "have a drink and catch up while in Philly". Just me, or are others seeing an increase in spam from vendors that will be there? -b From jvanoppen at spectrumnet.us Thu Oct 6 20:11:24 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Fri, 7 Oct 2011 01:11:24 +0000 Subject: Not operational, but related to the attendees in Philly In-Reply-To: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> References: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> Message-ID: That does not seem to be unique to nanog. -----Original Message----- From: Brett Watson [mailto:brett at the-watsons.org] Sent: Thursday, October 06, 2011 4:58 PM To: nanog at nanog.org Subject: Not operational, but related to the attendees in Philly I'm getting a rash of emails (as are some of my colleagues at work that are attending in Philly) from vendors that act like they know me, and just want to "have a drink and catch up while in Philly". Just me, or are others seeing an increase in spam from vendors that will be there? -b From brett at the-watsons.org Thu Oct 6 20:32:32 2011 From: brett at the-watsons.org (Brett Watson) Date: Thu, 6 Oct 2011 18:32:32 -0700 Subject: Not operational, but related to the attendees in Philly In-Reply-To: References: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> Message-ID: <272FFE45-2336-4D0E-BCBC-509E418D63D7@the-watsons.org> On Oct 6, 2011, at 6:11 PM, John van Oppen wrote: > That does not seem to be unique to nanog. Oh I know, it's just never happened to me until this nanog, and I've been attending off/on since '94. (Ok, I probably got a few here and there). I just need to get older and more crotchety-er like Randy, maybe they'll leave me alone. -b From rcarpen at network1.net Thu Oct 6 20:45:27 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 06 Oct 2011 21:45:27 -0400 (EDT) Subject: Not operational, but related to the attendees in Philly In-Reply-To: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> Message-ID: I have been getting some from vendors that already have my email, and/or already have a relationship with. Nothing from someone I've never dealt with before. If that is what you are getting, then that is pretty slimy. -Randy ----- Original Message ----- > I'm getting a rash of emails (as are some of my colleagues at work > that are attending in Philly) from vendors that act like they know > me, and just want to "have a drink and catch up while in Philly". > > Just me, or are others seeing an increase in spam from vendors that > will be there? > > -b > > From web at typo.org Thu Oct 6 21:02:58 2011 From: web at typo.org (Wayne E Bouchard) Date: Thu, 6 Oct 2011 19:02:58 -0700 Subject: Steve Jobs has died In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <20111007020258.GA41873@wakko.typo.org> On Wed, Oct 05, 2011 at 08:15:02PM -0400, Alex Rubenstein wrote: > Not entirely on-list-topic, but still relevant. > > > http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-steve-jobs-dies/?tag=cnetRiver In some circles, he's being compared to Thomas Edison. Apply your own opinion there whether you feel that's accurate or not. I'll just state this: Both men were pasionate about what they did. They each changed the world and left it better than they found it. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From MGauvin at dryden.ca Thu Oct 6 21:06:10 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Thu, 6 Oct 2011 21:06:10 -0500 Subject: Telus mail server admin Message-ID: <4DEA063ACE629740877D59B74D6FB26424039E79E9@exchange.citydryden.local> Looking for a Telus tech with a clue to contact me offline regarding an issue that has arisen this week. DISCLAIMER: This communication and any files transmitted with it may contain information that is privileged or confidential and is intended to be for the use of the individual (s) or entity named above. This material may contain confidential or personal information which may be subject to the provisions of the Municipal Freedom of Information & Protection of Privacy Act. If you are not the intended recipient of this communication and any files transmitted with it, any use, review, retransmission, distribution, dissemination, copying, printing, or other use of, or taking of any action in reliance upon this communication, is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete the original and any copy of this e-mail, and any printout thereof, immediately. Finally, the recipient should check this e-mail and any attachments for the presence of viruses. The Dryden Police Services Board and the Corporation of the City of Dryden accepts no liability for any damage caused by any virus transmitted by this email. From paul at paulgraydon.co.uk Thu Oct 6 21:26:28 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 06 Oct 2011 16:26:28 -1000 Subject: Steve Jobs has died In-Reply-To: <20111007020258.GA41873@wakko.typo.org> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> <20111007020258.GA41873@wakko.typo.org> Message-ID: <4E8E6354.1090006@paulgraydon.co.uk> On 10/6/2011 4:02 PM, Wayne E Bouchard wrote: > On Wed, Oct 05, 2011 at 08:15:02PM -0400, Alex Rubenstein wrote: >> Not entirely on-list-topic, but still relevant. >> >> >> http://news.cnet.com/8301-13579_3-20116336-37/apple-co-founder-chairman-steve-jobs-dies/?tag=cnetRiver > In some circles, he's being compared to Thomas Edison. Apply your own > opinion there whether you feel that's accurate or not. I'll just state > this: Both men were pasionate about what they did. They each changed > the world and left it better than they found it. > > It's probably not a bad analogy, like Ford and many other champions of industry he didn't invent groundbreaking technology (Edison's only invention was the phonograph IIRC, all else was improvements on existing technology). They took what was already in existence and did something amazing with it: made it accessible, be it through price, ease of use or whatever. Paul From jlewis at lewis.org Thu Oct 6 21:29:11 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 6 Oct 2011 22:29:11 -0400 (EDT) Subject: Not operational, but related to the attendees in Philly In-Reply-To: References: <011A8F5E-85D8-4935-B29A-DB5A88B7D0B8@the-watsons.org> Message-ID: No, but it is annoying that "vendors" do seem to scrape the nanog attendee list and feel it's ok to spam those people. On Fri, 7 Oct 2011, John van Oppen wrote: > That does not seem to be unique to nanog. > > > -----Original Message----- > From: Brett Watson [mailto:brett at the-watsons.org] > Sent: Thursday, October 06, 2011 4:58 PM > To: nanog at nanog.org > Subject: Not operational, but related to the attendees in Philly > > I'm getting a rash of emails (as are some of my colleagues at work that are attending in Philly) from vendors that act like they know me, and just want to "have a drink and catch up while in Philly". > > Just me, or are others seeing an increase in spam from vendors that will be there? > > -b > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From johnl at iecc.com Fri Oct 7 01:02:48 2011 From: johnl at iecc.com (John Levine) Date: 7 Oct 2011 06:02:48 -0000 Subject: Telus mail server admin In-Reply-To: <4DEA063ACE629740877D59B74D6FB26424039E79E9@exchange.citydryden.local> Message-ID: <20111007060248.19924.qmail@joyce.lan> >DISCLAIMER: This communication and any files transmitted with it may >contain information that is privileged or confidential and is intended >to be for the use of the individual (s) or entity named above. This >material may contain confidential or personal information which may be >subject to the provisions of the Municipal Freedom of Information & >Protection of Privacy Act. If you are not the intended recipient of this >communication and any files transmitted with it, any use, review, >retransmission, distribution, dissemination, copying, printing, or other >use of, or taking of any action in reliance upon this communication, is >strictly prohibited. If you have received this e-mail in error, please >contact the sender and delete the original and any copy of this e-mail, >and any printout thereof, immediately. Finally, the recipient should >check this e-mail and any attachments for the presence of viruses. The >Dryden Police Services Board and the Corporation of the City of Dryden >accepts no liability for any damage caused by any virus transmitted by >this email. Wow. I was thinking about answering the question, but now I don't dare. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: I spent ten years as an elected official with no disclaimer in my e-mail, and lived! From MGauvin at dryden.ca Fri Oct 7 05:02:02 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Fri, 7 Oct 2011 05:02:02 -0500 Subject: Telus mail server admin In-Reply-To: <20111007060248.19924.qmail@joyce.lan> References: <4DEA063ACE629740877D59B74D6FB26424039E79E9@exchange.citydryden.local> <20111007060248.19924.qmail@joyce.lan> Message-ID: <4DEA063ACE629740877D59B74D6FB2642403C7CE15@exchange.citydryden.local> Sorry if that came off harsh but per Telus business support there are no mail admins at Telus. -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Friday, October 07, 2011 1:03 AM To: nanog at nanog.org Subject: Re: Telus mail server admin >DISCLAIMER: This communication and any files transmitted with it may >contain information that is privileged or confidential and is intended >to be for the use of the individual (s) or entity named above. This >material may contain confidential or personal information which may be >subject to the provisions of the Municipal Freedom of Information & >Protection of Privacy Act. If you are not the intended recipient of this >communication and any files transmitted with it, any use, review, >retransmission, distribution, dissemination, copying, printing, or other >use of, or taking of any action in reliance upon this communication, is >strictly prohibited. If you have received this e-mail in error, please >contact the sender and delete the original and any copy of this e-mail, >and any printout thereof, immediately. Finally, the recipient should >check this e-mail and any attachments for the presence of viruses. The >Dryden Police Services Board and the Corporation of the City of Dryden >accepts no liability for any damage caused by any virus transmitted by >this email. Wow. I was thinking about answering the question, but now I don't dare. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: I spent ten years as an elected official with no disclaimer in my e-mail, and lived! From steti at monmouth.com Fri Oct 7 07:14:57 2011 From: steti at monmouth.com (Steve Teti) Date: Fri, 07 Oct 2011 08:14:57 -0400 Subject: Yahoo mail admin Message-ID: <4E8EED41.8080907@monmouth.com> Is there a Yahoo mail admin on the list who could help me? We had a problem with the DNS for our domain a couple of days ago (somehow authoritative nameservers were changed at Network Solutions). Some Yahoo users are still unable to send mail to users @monmouth.com, and some Yahoo users are sending fine. The problem is definitely affecting Verizon/Yahoo mail users but may be affecting others as well. I have a ticket open but it doesn't seem to be going anywhere. Thanks, Steve From paul at paulgraydon.co.uk Fri Oct 7 10:26:41 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 07 Oct 2011 05:26:41 -1000 Subject: Telus mail server admin In-Reply-To: <20111007060248.19924.qmail@joyce.lan> References: <20111007060248.19924.qmail@joyce.lan> Message-ID: <4E8F1A31.5090907@paulgraydon.co.uk> On 10/6/2011 8:02 PM, John Levine wrote: >> DISCLAIMER:... > Wow. I was thinking about answering the question, but now I don't dare. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > PS: I spent ten years as an elected official with no disclaimer in my > e-mail, and lived! That's nice for you, but some of us are stuck with a corporate policy that requires us to use such disclaimers, or face disciplinary actions. The legality and practicality might be questionable but short of quitting and finding other employment over something utterly trivial, what can you do if protests fall on deaf ears? Paul From joelja at bogus.com Fri Oct 7 10:30:41 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 07 Oct 2011 08:30:41 -0700 Subject: Telus mail server admin In-Reply-To: <4E8F1A31.5090907@paulgraydon.co.uk> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> Message-ID: <4E8F1B21.40803@bogus.com> On 10/7/11 08:26 , Paul Graydon wrote: > On 10/6/2011 8:02 PM, John Levine wrote: >>> DISCLAIMER:... >> Wow. I was thinking about answering the question, but now I don't dare. >> >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. http://jl.ly >> >> PS: I spent ten years as an elected official with no disclaimer in my >> e-mail, and lived! > That's nice for you, but some of us are stuck with a corporate policy > that requires us to use such disclaimers, or face disciplinary actions. > The legality and practicality might be questionable but short of > quitting and finding other employment over something utterly trivial, > what can you do if protests fall on deaf ears? Subscribe from your personal account. > Paul > From nathan at atlasnetworks.us Fri Oct 7 10:31:31 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 7 Oct 2011 15:31:31 +0000 Subject: Telus mail server admin In-Reply-To: <4E8F1B21.40803@bogus.com> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B59E54F@ex-mb-1.corp.atlasnetworks.us> > Subscribe from your personal account. +1 From paul at paulgraydon.co.uk Fri Oct 7 10:40:39 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 07 Oct 2011 05:40:39 -1000 Subject: Telus mail server admin In-Reply-To: <4E8F1B21.40803@bogus.com> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> Message-ID: <4E8F1D77.5080008@paulgraydon.co.uk> On 10/7/2011 5:30 AM, Joel jaeggli wrote: > On 10/7/11 08:26 , Paul Graydon wrote: >> On 10/6/2011 8:02 PM, John Levine wrote: >>>> DISCLAIMER:... >>> Wow. I was thinking about answering the question, but now I don't dare. >>> >>> Regards, >>> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >>> Dummies", >>> Please consider the environment before reading this e-mail. http://jl.ly >>> >>> PS: I spent ten years as an elected official with no disclaimer in my >>> e-mail, and lived! >> That's nice for you, but some of us are stuck with a corporate policy >> that requires us to use such disclaimers, or face disciplinary actions. >> The legality and practicality might be questionable but short of >> quitting and finding other employment over something utterly trivial, >> what can you do if protests fall on deaf ears? > Subscribe from your personal account. > Which I do. But note the original complaint was not about using ridiculously long disclaimers on a mailing list, it was about the ridiculously long disclaimer, full stop. Paul From mitch at mtanenbaum.us Fri Oct 7 11:17:27 2011 From: mitch at mtanenbaum.us (mitch tanenbaum) Date: Fri, 7 Oct 2011 10:17:27 -0600 Subject: Issue with Sprint Wireless Message-ID: <000c01cc850c$9c98e7b0$d5cab710$@mtanenbaum.us> Hi We are developing an android app that moves a fair amount (in the 1-2 digit megs) of data up and down over an application specific encrypted pipe (basically a custom VPN). We see great performance when we use wifi (of course) and very reasonable performance on Verizon Wireless. However, on Sprint, we are seeing consistently poor performance, no matter what phone we use. These results are independent of date, time and location, so it APPEARS to be Sprint wireless related. Eventually, everything does go through but it takes 5x to 10x the time it takes on Verizon Wireless. Has anyone had any experience, good or bad, they can relate off list? I don't *think* this is an outage, just the way the Sprint Wireless network works. If there is a Sprint Wireless engineer on the list that could contact me off list, that would be greatly appreciated. Mitch Tanenbaum iPhase3 Corp mitch at iphase3.com From bhmccie at gmail.com Fri Oct 7 11:18:05 2011 From: bhmccie at gmail.com (-Hammer-) Date: Fri, 07 Oct 2011 11:18:05 -0500 Subject: Telus mail server admin In-Reply-To: <4E8F1D77.5080008@paulgraydon.co.uk> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> <4E8F1D77.5080008@paulgraydon.co.uk> Message-ID: <4E8F263D.5080507@gmail.com> Girls. You're both pretty. Really. Move on. -Hammer- "I was a normal American nerd" -Jack Herer On 10/07/2011 10:40 AM, Paul Graydon wrote: > On 10/7/2011 5:30 AM, Joel jaeggli wrote: >> On 10/7/11 08:26 , Paul Graydon wrote: >>> On 10/6/2011 8:02 PM, John Levine wrote: >>>>> DISCLAIMER:... >>>> Wow. I was thinking about answering the question, but now I don't >>>> dare. >>>> >>>> Regards, >>>> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >>>> Dummies", >>>> Please consider the environment before reading this e-mail. >>>> http://jl.ly >>>> >>>> PS: I spent ten years as an elected official with no disclaimer in my >>>> e-mail, and lived! >>> That's nice for you, but some of us are stuck with a corporate policy >>> that requires us to use such disclaimers, or face disciplinary actions. >>> The legality and practicality might be questionable but short of >>> quitting and finding other employment over something utterly trivial, >>> what can you do if protests fall on deaf ears? >> Subscribe from your personal account. >> > Which I do. But note the original complaint was not about using > ridiculously long disclaimers on a mailing list, it was about the > ridiculously long disclaimer, full stop. > > Paul > From clapidus at gmail.com Fri Oct 7 11:20:48 2011 From: clapidus at gmail.com (Claudio Lapidus) Date: Fri, 7 Oct 2011 13:20:48 -0300 Subject: DPI deployment use case In-Reply-To: References: Message-ID: Hello, On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert wrote: > I've seen tyrannical governments use Bluecoat's to crack down on their > own population(*). > Was this the sort of use-case you were looking for? :) > Ummm, not really... :) Actually, we've been faced with proposals to build services based on traffic classification, like e.g. "access our own webmail and all social networking sites, but not skype and video" or the capability to do exact metering based on net traffic time or volume, as well as being able to redirect the customer to various captive portals using HTTP redirect directly from the DPI box, and such. What I'm interested to know, is if someone has actually had some success with service offerings like these, or if it can be used to implement some other kind of value-added service in the network access provider field. I am fully aware of the net-neutrality implications this might have, but anyway, putting that aside for a moment, I would like to explore the possibilities that this technology brings in. thanks again, cl. From paul4004 at gmail.com Fri Oct 7 11:44:45 2011 From: paul4004 at gmail.com (PC) Date: Fri, 7 Oct 2011 10:44:45 -0600 Subject: DPI deployment use case In-Reply-To: References: Message-ID: I've seen these used for two purposes over the years: 1) Repressive nation states. 2) ISPs/Universities who want to "shape" their bandwidth to prevent certain traffic types from consuming everything. 3) Integrated with enhanced caching solutions to serve content locally and save bandwidth (Web cache). Use case #2 is becoming less and less common ISP industry wide. More and more consumptive activities are switching away from quasi-legitimate "throttle it and see if anyone complains" type activities (bittorrent/Peer2Peer), and more and more towards legitiamte, high consumption, HTTP based traffic, where subscribers would have a fit. Net neutrality rules in some countries are limiting this behavior further (such as Skype blocking). Furthermore, industry wide pay-as-you-use and unlimited access with bandwidth caps is becoming more prevalent among wired and wireless SPs. Your use case is not beyond the possibility of full DPI, but a transparent proxy box of some nature would be sufficient for most of that. Usage limits on the other hand is often easier done via your AAA accounting/radius solution, including policing/shaping/cutting users off/billing for overages. Ohh, and these boxes often make pretty pictures, graphs, and reports. On Fri, Oct 7, 2011 at 10:20 AM, Claudio Lapidus wrote: > Hello, > > On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert > wrote: > > > I've seen tyrannical governments use Bluecoat's to crack down on their > > own population(*). > > Was this the sort of use-case you were looking for? :) > > > Ummm, not really... :) > > Actually, we've been faced with proposals to build services based on > traffic > classification, like e.g. "access our own webmail and all social networking > sites, but not skype and video" or the capability to do exact metering > based > on net traffic time or volume, as well as being able to redirect the > customer to various captive portals using HTTP redirect directly from the > DPI box, and such. > > What I'm interested to know, is if someone has actually had some success > with service offerings like these, or if it can be used to implement some > other kind of value-added service in the network access provider field. > > I am fully aware of the net-neutrality implications this might have, but > anyway, putting that aside for a moment, I would like to explore the > possibilities that this technology brings in. > > thanks again, > cl. > From Valdis.Kletnieks at vt.edu Fri Oct 7 12:00:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Oct 2011 13:00:29 -0400 Subject: Telus mail server admin In-Reply-To: Your message of "Fri, 07 Oct 2011 05:40:39 -1000." <4E8F1D77.5080008@paulgraydon.co.uk> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> <4E8F1D77.5080008@paulgraydon.co.uk> Message-ID: <16434.1318006829@turing-police.cc.vt.edu> On Fri, 07 Oct 2011 05:40:39 -1000, Paul Graydon said: > Which I do. But note the original complaint was not about using > ridiculously long disclaimers on a mailing list, it was about the > ridiculously long disclaimer, full stop. If your corporate policy insists on huge disclaimers regarding confidential information on e-mails sent to public maling lists, it's busticated, pure and simple. And unless somebody can cite actual statute or case law where such a blanket disclaimer made an *actual difference*, the policy *in general* is busticated. Yes, I know that it *does* matter for *some specific* content. But the only case law I know of was one judge who (in an unfortunately non-precidential way) said the fact that a company felt the need to put a blanket disclaimer on all the e-mail was doing itself a dis-favor, because it tended to indicate that the company had no clue or control over what content was in fact privileged or confidential. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bclark at spectraaccess.com Fri Oct 7 12:19:11 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 07 Oct 2011 13:19:11 -0400 Subject: Issue with Sprint Wireless In-Reply-To: <000c01cc850c$9c98e7b0$d5cab710$@mtanenbaum.us> References: <000c01cc850c$9c98e7b0$d5cab710$@mtanenbaum.us> Message-ID: <4E8F348F.4000702@spectraaccess.com> Every cell tower is different, every region is different, good performance in one region on one carrier, maybe the exact opposite in another region on that same carrier. That's quite a bit of data (assuming 1-2mbps...not sure what "digit megs" are) you're trying push through a cell network especially 3G. Is it possible your Verizon testing is on Verizon's 4G network while Sprint's is 3G? Bret On 10/07/2011 12:17 PM, mitch tanenbaum wrote: > Hi > > > > We are developing an android app that moves a fair amount (in the 1-2 digit > megs) of data up and down over an application specific encrypted pipe > (basically a custom VPN). We see great performance when we use wifi (of > course) and very reasonable performance on Verizon Wireless. However, on > Sprint, we are seeing consistently poor performance, no matter what phone we > use. These results are independent of date, time and location, so it > APPEARS to be Sprint wireless related. Eventually, everything does go > through but it takes 5x to 10x the time it takes on Verizon Wireless. > > > > Has anyone had any experience, good or bad, they can relate off list? I > don't *think* this is an outage, just the way the Sprint Wireless network > works. If there is a Sprint Wireless engineer on the list that could > contact me off list, that would be greatly appreciated. > > > > Mitch Tanenbaum > > iPhase3 Corp > > mitch at iphase3.com > > > From rsk at gsp.org Fri Oct 7 12:43:00 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 7 Oct 2011 13:43:00 -0400 Subject: Telus mail server admin In-Reply-To: <16434.1318006829@turing-police.cc.vt.edu> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> <4E8F1D77.5080008@paulgraydon.co.uk> <16434.1318006829@turing-police.cc.vt.edu> Message-ID: <20111007174300.GA11435@gsp.org> I'd like to see it made list policy that anyone posting with such an appended threat be given exactly what they're demanding -- i.e., unsubscribed immediately and permanently. Please see: Stupid E-mail Disclaimers and the Stupid Users that Use Them http://attrition.org/security/rants/z/disclaimers.html and Don't Send Bogus Legalistic Boilerplate http://www.river.com/users/share/etiquette/#legalistic I'd also like to point out that this is the 3rd request for mail system assistance that's shown up here today (so far); all of these should have been sent to "mailop" instead. ---rsk From Valdis.Kletnieks at vt.edu Fri Oct 7 13:00:20 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Oct 2011 14:00:20 -0400 Subject: Telus mail server admin In-Reply-To: Your message of "Fri, 07 Oct 2011 13:43:00 EDT." <20111007174300.GA11435@gsp.org> References: <20111007060248.19924.qmail@joyce.lan> <4E8F1A31.5090907@paulgraydon.co.uk> <4E8F1B21.40803@bogus.com> <4E8F1D77.5080008@paulgraydon.co.uk> <16434.1318006829@turing-police.cc.vt.edu> <20111007174300.GA11435@gsp.org> Message-ID: <18717.1318010420@turing-police.cc.vt.edu> On Fri, 07 Oct 2011 13:43:00 EDT, Rich Kulawiec said: > I'd like to see it made list policy that anyone posting with such an > appended threat be given exactly what they're demanding -- i.e., > unsubscribed immediately and permanently. Every once in a while, I reply back and remind the person with the disclaimer that just hitting delete doesn't *actually* get rid of the message, and ask if their organization is willing to reimburse us for the costs of *securely* erasing the offending message off our inbound mail gateway, the AV/spam scanners, the central mail routing hub, the mailbox store, and the backups of all of those systems. (And let me tell you - dissapearing a specific piece of data off an NSR Legato backup without losing all the other data on the backup is *really* hard. Trust me on this one. ;) For some reason, they almost never reply in the affirmative. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joly at punkcast.com Fri Oct 7 13:11:56 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 7 Oct 2011 14:11:56 -0400 Subject: Botnets buying up IPv4 address space In-Reply-To: <20111007173150.GA12261@vortex.com> References: <20111007173150.GA12261@vortex.com> Message-ID: I'd welcome comments as to solutions to this. Or is it just scaremongering? j ---------- Forwarded message ---------- From: Lauren Weinstein Date: Fri, Oct 7, 2011 at 1:31 PM Botnets buying up IPv4 address space http://j.mp/nMJ5Lr (Threat Post) "Now, in one effort to get around these systems, some attackers are taking advantage of the lack of IPV4 space by either purchasing or renting blocks of IP space with good reputations that have been built up over the course of several years. A number of legitimate trading and auction sites have appeared as the IPV4 space became scarcer, and the attackers have gotten involved as well, getting their hands on known good IP blocks and using them for C&C or hosting malware." - - - --Lauren-- NNSquad Moderator -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From lowen at pari.edu Fri Oct 7 13:28:00 2011 From: lowen at pari.edu (Lamar Owen) Date: Fri, 7 Oct 2011 14:28:00 -0400 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: Message-ID: <201110071428.00727.lowen@pari.edu> On Friday, September 30, 2011 05:54:38 PM steve pirk [egrep] wrote: > I seem to recollect back the 1999 or 2000 times that I was unable to > register a domain name that was 24 characters long. Shortly after that, I > heard that the character limit had been increased to like 128 characters, > and we were able to register the name. > > Can anyone offer some input, or is this a memory of a bad dream? > ;-] At least as of 2008, you could go 45 characters, not counting the TLD: ++++++++++++++++++ $ whois pneumonoultramicroscopicsilicovolcanoconiosis.com [Querying whois.verisign-grs.com] [Redirected to whois.above.com] [Querying whois.above.com] [whois.above.com] The Registry database contains ONLY .COM, .NET, .EDU domains and Registrars.Registration Service Provided By: ABOVE.COM, Pty. Ltd. Contact: +613.95897946 Domain Name: PNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS.COM Registrant: Above.com Domain Privacy 8 East concourse Beaumaris VIC 3193 AU pneumonoultramicroscopicsilicovolcanoconiosis.com at privacy.above.com Tel. +61.395897946 Fax. Creation date: 2008-02-20 Expiration Date: 2012-02-20 ... $ ping www.pneumonoultramicroscopicsilicovolcanoconiosis.com PING www.pneumonoultramicroscopicsilicovolcanoconiosis.com (69.43.161.151) 56(84) bytes of data. 64 bytes from 69.43.161.151: icmp_req=1 ttl=50 time=85.9 ms 64 bytes from 69.43.161.151: icmp_req=3 ttl=50 time=85.7 ms 64 bytes from 69.43.161.151: icmp_req=4 ttl=50 time=85.8 ms 64 bytes from 69.43.161.151: icmp_req=5 ttl=50 time=85.6 ms ^C --- www.pneumonoultramicroscopicsilicovolcanoconiosis.com ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4002ms rtt min/avg/max/mdev = 85.618/85.815/85.984/0.132 ms +++++++++++++++++++++ FWIW. From arturo.servin at gmail.com Fri Oct 7 13:31:29 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 7 Oct 2011 15:31:29 -0300 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> Message-ID: <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> What do you mean with "purchasing or renting IPv4". Last time that I check it was not possible in the RIR world. If you mean "hijacking" unused IPv4 space, that's another history. .as On 7 Oct 2011, at 15:11, Joly MacFie wrote: > I'd welcome comments as to solutions to this. Or is it just scaremongering? > > j > > ---------- Forwarded message ---------- > From: Lauren Weinstein > Date: Fri, Oct 7, 2011 at 1:31 PM > > Botnets buying up IPv4 address space > > http://j.mp/nMJ5Lr (Threat Post) > > "Now, in one effort to get around these systems, some attackers are > taking advantage of the lack of IPV4 space by either purchasing or > renting blocks of IP space with good reputations that have been built > up over the course of several years. A number of legitimate trading > and auction sites have appeared as the IPV4 space became scarcer, and > the attackers have gotten involved as well, getting their hands on > known good IP blocks and using them for C&C or hosting malware." > > - - - > > --Lauren-- > NNSquad Moderator > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - From drc at virtualized.org Fri Oct 7 13:35:26 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Oct 2011 11:35:26 -0700 Subject: Botnets buying up IPv4 address space In-Reply-To: <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> Message-ID: <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> On Oct 7, 2011, at 11:31 AM, Arturo Servin wrote: > What do you mean with "purchasing or renting IPv4". > > Last time that I check it was not possible in the RIR world. Seriously? http://www.networkworld.com/community/blog/microsoft-pays-nortel-75-million-ipv4-address The next phases are anger, bargaining, depression, and finally acceptance. Regards, -drc From joelja at bogus.com Fri Oct 7 13:38:45 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 07 Oct 2011 11:38:45 -0700 Subject: Botnets buying up IPv4 address space In-Reply-To: <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> Message-ID: <4E8F4735.7030506@bogus.com> On 10/7/11 11:31 , Arturo Servin wrote: > > What do you mean with "purchasing or renting IPv4". > > Last time that I check it was not possible in the RIR world. If you're not a legitimate business why would you bother with commonly accepted policy? > If you mean "hijacking" unused IPv4 space, that's another history. the post fails entirely to cite actual examples, then goes off into the weeds on domain name reputation. > .as > > On 7 Oct 2011, at 15:11, Joly MacFie wrote: > >> I'd welcome comments as to solutions to this. Or is it just scaremongering? >> >> j >> >> ---------- Forwarded message ---------- >> From: Lauren Weinstein >> Date: Fri, Oct 7, 2011 at 1:31 PM >> >> Botnets buying up IPv4 address space >> >> http://j.mp/nMJ5Lr (Threat Post) >> >> "Now, in one effort to get around these systems, some attackers are >> taking advantage of the lack of IPV4 space by either purchasing or >> renting blocks of IP space with good reputations that have been built >> up over the course of several years. A number of legitimate trading >> and auction sites have appeared as the IPV4 space became scarcer, and >> the attackers have gotten involved as well, getting their hands on >> known good IP blocks and using them for C&C or hosting malware." >> >> - - - >> >> --Lauren-- >> NNSquad Moderator >> >> >> >> -- >> --------------------------------------------------------------- >> Joly MacFie 218 565 9365 Skype:punkcast >> WWWhatsup NYC - http://wwwhatsup.com >> http://pinstand.com - http://punkcast.com >> VP (Admin) - ISOC-NY - http://isoc-ny.org >> -------------------------------------------------------------- >> - > > From arturo.servin at gmail.com Fri Oct 7 13:59:06 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 7 Oct 2011 15:59:06 -0300 Subject: Botnets buying up IPv4 address space In-Reply-To: <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> Message-ID: <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> Yes, I forgot that one. ARIN and APNIC allows it, LACNIC will when it reaches the last /12 (so now is not possible). RIPE NCC and Afrinic do not have a policy yet AFAIK. -as On 7 Oct 2011, at 15:35, David Conrad wrote: > On Oct 7, 2011, at 11:31 AM, Arturo Servin wrote: >> What do you mean with "purchasing or renting IPv4". >> >> Last time that I check it was not possible in the RIR world. > > Seriously? > > http://www.networkworld.com/community/blog/microsoft-pays-nortel-75-million-ipv4-address > > The next phases are anger, bargaining, depression, and finally acceptance. > > Regards, > -drc > From bensons at queuefull.net Fri Oct 7 14:03:25 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 7 Oct 2011 14:03:25 -0500 Subject: Botnets buying up IPv4 address space In-Reply-To: <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> Message-ID: <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> On Oct 7, 2011, at 1:31 PM, Arturo Servin wrote: > What do you mean with "purchasing or renting IPv4". > > Last time that I check it was not possible in the RIR world. Nevertheless, it is possible in the real world. > On 7 Oct 2011, at 15:11, Joly MacFie wrote: > >> I'd welcome comments as to solutions to this. Or is it just scaremongering? >> ... >> Botnets buying up IPv4 address space >> >> http://j.mp/nMJ5Lr (Threat Post) Domain names, IP addresses, network connectivity, etc - all of these are resources that people can acquire, (mis)use, and replace. The fact that reputation systems often conflate people and their (impermanent) resources is unfortunate, and is the source of much operational pain. I don't see anything new in the article, and would classify parts of it as scaremongering. (e.g. the criticism of IPv6) Cheers, -Benson From arturo.servin at gmail.com Fri Oct 7 14:10:40 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 7 Oct 2011 16:10:40 -0300 Subject: Botnets buying up IPv4 address space In-Reply-To: <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> Message-ID: <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> I agree with Benson. In fact, for this "problem" I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. -as On 7 Oct 2011, at 16:03, Benson Schliesser wrote: > I don't see anything new in the article, and would classify parts of it as scaremongering. (e.g. the criticism of IPv6) From morrowc.lists at gmail.com Fri Oct 7 14:15:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 7 Oct 2011 15:15:34 -0400 Subject: Botnets buying up IPv4 address space In-Reply-To: <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> Message-ID: On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin wrote: > > ? ? ? ?I agree with Benson. > > ? ? ? ?In fact, for this "problem" I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. isn't this a short-lived problem then? From richard.barnes at gmail.com Fri Oct 7 14:23:55 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 7 Oct 2011 15:23:55 -0400 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> Message-ID: If not short-lived, then at least self-limiting. --Richard On Fri, Oct 7, 2011 at 3:15 PM, Christopher Morrow wrote: > On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin wrote: >> >> ? ? ? ?I agree with Benson. >> >> ? ? ? ?In fact, for this "problem" I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. > > isn't this a short-lived problem then? > > From morrowc.lists at gmail.com Fri Oct 7 14:31:14 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 7 Oct 2011 15:31:14 -0400 Subject: DPI deployment use case In-Reply-To: References: Message-ID: On Fri, Oct 7, 2011 at 12:44 PM, PC wrote: > Your use case is not beyond the possibility of full DPI, but a transparent > proxy box of some nature would be sufficient for most of that. ?Usage limits > on the other hand is often easier done via your AAA accounting/radius > solution, including policing/shaping/cutting users off/billing for overages. > > Ohh, and these boxes often make pretty pictures, graphs, and reports. one wonders at the cost of these sorts of solutions relative to just link upgrades as well... for some deployments +1gbps capable boxes in redundant configs are far more expensive as compared with just upgrading 1gbps -> 10gbps ... From drc at virtualized.org Fri Oct 7 14:31:44 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Oct 2011 12:31:44 -0700 Subject: Botnets buying up IPv4 address space In-Reply-To: <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> Message-ID: Arturo, On Oct 7, 2011, at 12:10 PM, Arturo Servin wrote: > In fact, for this "problem" I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. I suspect it is relevant to IPv4 because IPv6 has so little penetration. It probably doesn't matter if you have a good reputation on IPv6... Regards, -drc From bill at herrin.us Fri Oct 7 14:32:43 2011 From: bill at herrin.us (William Herrin) Date: Fri, 7 Oct 2011 15:32:43 -0400 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> Message-ID: On Fri, Oct 7, 2011 at 2:11 PM, Joly MacFie wrote: >> Botnets buying up IPv4 address space >> >> http://j.mp/nMJ5Lr (Threat Post) > > I'd welcome comments as to solutions to this. Or is it just scaremongering? Joly, The author has drawn a relationship between a lot of unrelated things. Hackers and spammers "rent" IP addresses all the time, and have done so for two decades. It's called, "Here's my money for colo hosting service and I need some IP addresses to go along with it." Nothing has changed as a result of IPv4 depletion. Botnets are hacked machines. They come with their own IP addresses scattered about the globe and don't require any particular source. No relation to IPv4 depletion and only tangentially related to the "bulletproof hosting" that supplies IP addresses for the C&C servers. As for auctioning IP blocks, my experience is that hackers don't bother. If they want IP addresses beyond what the colo provider offers, they steal them: find a block of addresses not routed on the public Internet and forge LoAs they present to their ISP. They're going to lose them anyway, so why bother paying money? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Fri Oct 7 14:50:01 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 7 Oct 2011 15:50:01 -0400 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> Message-ID: On Fri, Oct 7, 2011 at 3:32 PM, William Herrin wrote: > As for auctioning IP blocks, my experience is that hackers don't > bother. If they want IP addresses beyond what the colo provider > offers, they steal them: find a block of addresses not routed on the > public Internet and forge LoAs they present to their ISP. They're > going to lose them anyway, so why bother paying money? ala: 146.20.0.0 ? From cscora at apnic.net Fri Oct 7 14:54:40 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Oct 2011 05:54:40 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201110071954.p97Jser2015250@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Oct, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 376147 Prefixes after maximum aggregation: 169003 Deaggregation factor: 2.23 Unique aggregates announced to Internet: 185518 Total ASes present in the Internet Routing Table: 38980 Prefixes per ASN: 9.65 Origin-only ASes present in the Internet Routing Table: 32290 Origin ASes announcing only one prefix: 15494 Transit ASes present in the Internet Routing Table: 5213 Transit-only ASes present in the Internet Routing Table: 134 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1658 Unregistered ASNs in the Routing Table: 841 Number of 32-bit ASNs allocated by the RIRs: 1832 Number of 32-bit ASNs visible in the Routing Table: 1477 Prefixes from 32-bit ASNs in the Routing Table: 3383 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space: 95 Number of addresses announced to Internet: 2483550208 Equivalent to 148 /8s, 7 /16s and 248 /24s Percentage of available address space announced: 67.0 Percentage of allocated address space announced: 67.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.5 Total number of prefixes smaller than registry allocations: 157509 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 94479 Total APNIC prefixes after maximum aggregation: 30812 APNIC Deaggregation factor: 3.07 Prefixes being announced from the APNIC address blocks: 90937 Unique aggregates announced from the APNIC address blocks: 38010 APNIC Region origin ASes present in the Internet Routing Table: 4569 APNIC Prefixes per ASN: 19.90 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 702 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 90 Number of APNIC addresses announced to Internet: 628447584 Equivalent to 37 /8s, 117 /16s and 89 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 144302 Total ARIN prefixes after maximum aggregation: 74084 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 116427 Unique aggregates announced from the ARIN address blocks: 48007 ARIN Region origin ASes present in the Internet Routing Table: 14715 ARIN Prefixes per ASN: 7.91 ARIN Region origin ASes announcing only one prefix: 5670 ARIN Region transit ASes present in the Internet Routing Table: 1556 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 805354752 Equivalent to 48 /8s, 0 /16s and 189 /24s Percentage of available ARIN address space announced: 64.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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 90213 Total RIPE prefixes after maximum aggregation: 50506 RIPE Deaggregation factor: 1.79 Prefixes being announced from the RIPE address blocks: 82867 Unique aggregates announced from the RIPE address blocks: 54222 RIPE Region origin ASes present in the Internet Routing Table: 16019 RIPE Prefixes per ASN: 5.17 RIPE Region origin ASes announcing only one prefix: 7969 RIPE Region transit ASes present in the Internet Routing Table: 2499 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1043 Number of RIPE addresses announced to Internet: 490533248 Equivalent to 29 /8s, 60 /16s and 241 /24s Percentage of available RIPE address space announced: 79.0 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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 35060 Total LACNIC prefixes after maximum aggregation: 7852 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 34492 Unique aggregates announced from the LACNIC address blocks: 18093 LACNIC Region origin ASes present in the Internet Routing Table: 1532 LACNIC Prefixes per ASN: 22.51 LACNIC Region origin ASes announcing only one prefix: 451 LACNIC Region transit ASes present in the Internet Routing Table: 280 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 329 Number of LACNIC addresses announced to Internet: 90288768 Equivalent to 5 /8s, 97 /16s and 178 /24s Percentage of available LACNIC address space announced: 59.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8536 Total AfriNIC prefixes after maximum aggregation: 2003 AfriNIC Deaggregation factor: 4.26 Prefixes being announced from the AfriNIC address blocks: 6622 Unique aggregates announced from the AfriNIC address blocks: 1978 AfriNIC Region origin ASes present in the Internet Routing Table: 487 AfriNIC Prefixes per ASN: 13.60 AfriNIC Region origin ASes announcing only one prefix: 155 AfriNIC Region transit ASes present in the Internet Routing Table: 104 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 3 Number of AfriNIC addresses announced to Internet: 27800320 Equivalent to 1 /8s, 168 /16s and 51 /24s Percentage of available AfriNIC address space announced: 41.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2493 11047 956 Korea Telecom (KIX) 17974 1963 519 33 PT TELEKOMUNIKASI INDONESIA 7545 1607 303 84 TPG Internet Pty Ltd 4755 1543 638 176 TATA Communications formerly 7552 1394 1064 7 Vietel Corporation 24560 1180 345 206 Bharti Airtel Ltd., Telemedia 9829 1165 989 28 BSNL National Internet Backbo 9583 1087 80 503 Sify Limited 4808 1074 2096 303 CNCGROUP IP network: China169 18101 951 165 142 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3553 3817 222 bellsouth.net, inc. 18566 1915 366 239 Covad Communications 7029 1897 1016 196 Windstream Communications Inc 1785 1830 680 121 PaeTec Communications, Inc. 4323 1626 1083 392 Time Warner Telecom 20115 1593 1541 636 Charter Communications 22773 1458 2907 100 Cox Communications, Inc. 19262 1394 4728 400 Verizon Global Networks 30036 1385 250 676 Mediacom Communications Corp 7018 1337 7049 875 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1412 352 13 Corbina telecom 6830 635 1890 410 UPC Distribution Services 34984 578 108 180 BILISIM TELEKOM 20940 543 183 417 Akamai Technologies European 3320 503 8169 385 Deutsche Telekom AG 12479 481 593 7 Uni2 Autonomous System 3292 480 2082 407 TDC Tele Danmark 8866 460 133 26 Bulgarian Telecommunication C 29049 424 31 55 AzerSat LLC. 8551 404 354 44 Bezeq International Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1680 310 154 TVCABLE BOGOTA 8151 1411 2839 344 UniNet S.A. de C.V. 28573 1363 1013 79 NET Servicos de Comunicao S.A 7303 1163 683 175 Telecom Argentina Stet-France 14420 756 59 87 CORPORACION NACIONAL DE TELEC 22047 579 322 17 VTR PUNTO NET S.A. 6503 575 450 69 AVANTEL, S.A. 27947 575 71 83 Telconet S.A 3816 536 232 95 Empresa Nacional de Telecomun 11172 521 85 94 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 814 146 36 LINKdotNET AS number 8452 723 445 11 TEDATA 15475 445 74 8 Nile Online 36992 298 415 19 Etisalat MISR 3741 278 938 230 The Internet Solution 15706 244 32 6 Sudatel Internet Exchange Aut 6713 242 519 14 Itissalat Al-MAGHRIB 12258 198 28 58 Vodacom Internet Company 33776 197 13 13 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3553 3817 222 bellsouth.net, inc. 4766 2493 11047 956 Korea Telecom (KIX) 17974 1963 519 33 PT TELEKOMUNIKASI INDONESIA 18566 1915 366 239 Covad Communications 7029 1897 1016 196 Windstream Communications Inc 1785 1830 680 121 PaeTec Communications, Inc. 10620 1680 310 154 TVCABLE BOGOTA 4323 1626 1083 392 Time Warner Telecom 7545 1607 303 84 TPG Internet Pty Ltd 20115 1593 1541 636 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1963 1930 PT TELEKOMUNIKASI INDONESIA 1785 1830 1709 PaeTec Communications, Inc. 7029 1897 1701 Windstream Communications Inc 18566 1915 1676 Covad Communications 4766 2493 1537 Korea Telecom (KIX) 10620 1680 1526 TVCABLE BOGOTA 7545 1607 1523 TPG Internet Pty Ltd 8402 1412 1399 Corbina telecom 7552 1394 1387 Vietel Corporation 4755 1543 1367 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.8.0/22 47926 Lutsche.net Ltd 128.0.12.0/22 47926 Lutsche.net Ltd 128.0.80.0/24 30977 JSC "Yugra-Telecom" 128.0.81.0/24 30977 JSC "Yugra-Telecom" 128.0.82.0/24 30977 JSC "Yugra-Telecom" 128.0.83.0/24 30977 JSC "Yugra-Telecom" 128.0.84.0/24 30977 JSC "Yugra-Telecom" 128.0.85.0/24 30977 JSC "Yugra-Telecom" 128.0.86.0/24 30977 JSC "Yugra-Telecom" 128.0.87.0/24 30977 JSC "Yugra-Telecom" Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.rand.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:19 /9:12 /10:27 /11:82 /12:235 /13:464 /14:806 /15:1422 /16:12001 /17:5999 /18:10038 /19:19859 /20:27183 /21:27239 /22:36807 /23:34975 /24:195647 /25:1112 /26:1319 /27:725 /28:167 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2190 3553 bellsouth.net, inc. 18566 1871 1915 Covad Communications 7029 1589 1897 Windstream Communications Inc 10620 1575 1680 TVCABLE BOGOTA 8402 1389 1412 Corbina telecom 30036 1347 1385 Mediacom Communications Corp 11492 1115 1153 Cable One 1785 1055 1830 PaeTec Communications, Inc. 7011 1048 1167 Citizens Utilities 22773 947 1458 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:386 2:473 4:15 5:1 6:3 8:356 12:1951 13:1 14:533 15:11 16:3 17:7 20:10 23:54 24:1691 27:965 31:582 32:65 33:4 34:2 36:4 38:751 40:108 41:2639 42:48 44:3 46:998 47:3 49:264 50:436 52:13 55:5 56:2 57:37 58:882 59:491 60:365 61:1176 62:1088 63:1933 64:4047 65:2303 66:4014 67:1962 68:1106 69:3196 70:836 71:378 72:1849 74:2488 75:364 76:341 77:884 78:868 79:478 80:1128 81:840 82:497 83:504 84:624 85:1118 86:405 87:873 88:353 89:1601 90:269 91:4158 92:528 93:1374 94:1306 95:1028 96:437 97:280 98:899 99:37 101:210 103:342 106:70 107:61 108:54 109:1041 110:668 111:795 112:322 113:482 114:573 115:697 116:874 117:712 118:893 119:1232 120:338 121:692 122:1606 123:1020 124:1365 125:1381 128:253 129:175 130:166 131:584 132:112 133:21 134:214 135:54 136:213 137:139 138:288 139:125 140:496 141:292 142:387 143:420 144:493 145:63 146:472 147:215 148:636 149:266 150:151 151:193 152:447 153:179 154:7 155:386 156:207 157:329 158:151 159:467 160:320 161:206 162:337 163:179 164:513 165:367 166:537 167:434 168:744 169:145 170:864 171:86 172:1 173:1671 174:658 175:408 176:266 177:287 178:1053 180:1103 181:37 182:630 183:210 184:368 185:1 186:1513 187:670 188:928 189:858 190:5193 192:5911 193:5021 194:3528 195:3105 196:1241 197:186 198:3623 199:4142 200:5517 201:1646 202:8575 203:8489 204:4295 205:2364 206:2675 207:2822 208:4036 209:3452 210:2691 211:1457 212:2061 213:1779 214:793 215:90 216:4919 217:1601 218:560 219:339 220:1241 221:513 222:342 223:285 End of report From randy at psg.com Fri Oct 7 15:57:56 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Oct 2011 05:57:56 +0900 Subject: DPI deployment use case In-Reply-To: References: Message-ID: > Actually, we've been faced with proposals to build services based on > traffic classification, like e.g. "access our own webmail and all > social networking sites, but not skype and video" you're on the wrong list. this list is about the internet. randy From randy at psg.com Fri Oct 7 15:59:03 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Oct 2011 05:59:03 +0900 Subject: Botnets buying up IPv4 address space In-Reply-To: <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> Message-ID: > What do you mean with "purchasing or renting IPv4". > Last time that I check it was not possible in the RIR world. maybe you should look again. it's a new century. randy From m.hallgren at free.fr Fri Oct 7 16:25:42 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 07 Oct 2011 23:25:42 +0200 Subject: DPI deployment use case In-Reply-To: References: Message-ID: <1318022742.2808.0.camel@home> Le samedi 08 octobre 2011 ? 05:57 +0900, Randy Bush a ?crit : > > Actually, we've been faced with proposals to build services based on > > traffic classification, like e.g. "access our own webmail and all > > social networking sites, but not skype and video" > > you're on the wrong list. this list is about the internet. good point; +1 mh > > randy > From cidr-report at potaroo.net Fri Oct 7 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Oct 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201110072200.p97M016d085857@wattle.apnic.net> BGP Update Report Interval: 29-Sep-11 -to- 06-Oct-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 58237 3.6% 59.3 -- BSNL-NIB National Internet Backbone 2 - AS17451 54858 3.4% 246.0 -- BIZNET-AS-AP BIZNET ISP 3 - AS6316 31539 1.9% 1051.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 4 - AS32528 25182 1.6% 6295.5 -- ABBOTT Abbot Labs 5 - AS19201 24511 1.5% 500.2 -- ETC - Eastex Telephone Cooperative, Inc. 6 - AS14420 24093 1.5% 46.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS5800 23673 1.5% 125.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS4755 23483 1.4% 15.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 9 - AS20940 21905 1.4% 300.1 -- AKAMAI-ASN1 Akamai Technologies European AS 10 - AS38040 20370 1.3% 1455.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - AS8402 20258 1.2% 14.6 -- CORBINA-AS OJSC "Vimpelcom" 12 - AS16625 17363 1.1% 510.7 -- AKAMAI-ASN1 Akamai Technologies European AS 13 - AS9498 14569 0.9% 148.7 -- BBIL-AP BHARTI Airtel Ltd. 14 - AS16916 14530 0.9% 1816.2 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 15 - AS30036 13866 0.8% 29.4 -- MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp 16 - AS17974 13529 0.8% 8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS17908 13199 0.8% 16.1 -- TCISL Tata Communications 18 - AS7552 12163 0.8% 9.0 -- VIETEL-AS-AP Vietel Corporation 19 - AS31148 9911 0.6% 25.0 -- FREENET-AS FreeNet ISP 20 - AS9649 9890 0.6% 186.6 -- MOPH-TH-AP Information Technology Office TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 25182 1.6% 6295.5 -- ABBOTT Abbot Labs 2 - AS17408 3476 0.2% 3476.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 3 - AS9562 9848 0.6% 2462.0 -- MSU-TH-AP Mahasarakham University 4 - AS16916 14530 0.9% 1816.2 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 5 - AS20098 1810 0.1% 1810.0 -- BCBS-AL - Blue Cross Blue Shield of Alabama 6 - AS28722 1729 0.1% 1729.0 -- ENERGETYKA-KALISKA-AS Energetyka Kaliska S.A. 7 - AS11028 1584 0.1% 1584.0 -- SETIATHOME - SETIATHOME 8 - AS38040 20370 1.3% 1455.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 9 - AS50660 1282 0.1% 1282.0 -- SSIF-CJ-AS SOCIETATE DE SERVICII DE INVESTITII FINANCIARE BROKER SA 10 - AS17425 7397 0.5% 1232.8 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 11 - AS50975 2276 0.1% 1138.0 -- AVX_AS AVX Czech republic s.r.o 12 - AS6316 31539 1.9% 1051.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 13 - AS10099 883 0.1% 883.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 14 - AS44025 759 0.1% 759.0 -- KAMTELEKOM-NET Kamtelekom Ltd. 15 - AS22793 729 0.0% 729.0 -- CASSOCORP - CASSO Corporation 16 - AS19725 654 0.0% 654.0 -- COHPWE - City Of Houston - Public Works 17 - AS55696 596 0.0% 596.0 -- SCOM-AS-ID Starcom Solusindo PT. 18 - AS56548 556 0.0% 556.0 -- CENTERMEDIALTD-AS CenterMedia Ltd. 19 - AS3 551 0.0% 597.0 -- ASKAOSCDN KAOS redes IP 20 - AS16625 17363 1.1% 510.7 -- AKAMAI-ASN1 Akamai Technologies European AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 206.80.93.0/24 14507 0.8% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 2 - 202.92.235.0/24 14167 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 3 - 130.36.34.0/24 12585 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 12585 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 66.248.96.0/21 10820 0.6% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 66.248.120.0/21 10746 0.6% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 66.248.104.0/21 9888 0.6% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 63.174.153.0/24 8466 0.5% AS19201 -- ETC - Eastex Telephone Cooperative, Inc. 9 - 63.174.152.0/24 8458 0.5% AS19201 -- ETC - Eastex Telephone Cooperative, Inc. 10 - 213.16.48.0/24 6131 0.3% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 11 - 180.180.255.0/24 4675 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 12 - 180.180.249.0/24 4033 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 13 - 180.180.253.0/24 3930 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 14 - 180.180.248.0/24 3850 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 15 - 180.180.250.0/24 3845 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 16 - 206.228.173.0/24 3684 0.2% AS19201 -- ETC - Eastex Telephone Cooperative, Inc. 17 - 63.174.148.0/24 3683 0.2% AS19201 -- ETC - Eastex Telephone Cooperative, Inc. 18 - 202.153.174.0/24 3476 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 19 - 95.100.128.0/20 3180 0.2% AS16625 -- AKAMAI-ASN1 Akamai Technologies European AS 20 - 95.100.144.0/20 3173 0.2% AS16625 -- AKAMAI-ASN1 Akamai Technologies European AS Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Oct 7 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Oct 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201110072200.p97M01kx085852@wattle.apnic.net> This report has been generated at Fri Oct 7 21:12:24 2011 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 30-09-11 377480 221922 01-10-11 377431 221793 02-10-11 377430 221822 03-10-11 377808 221722 04-10-11 377724 221790 05-10-11 377891 222102 06-10-11 378031 221892 07-10-11 378198 221924 AS Summary 39061 Number of ASes in routing system 16522 Number of ASes announcing only one prefix 3552 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108295136 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'). --- 07Oct11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 378306 221924 156382 41.3% All ASes AS6389 3552 225 3327 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 1915 380 1535 80.2% COVAD - Covad Communications Co. AS4766 2493 973 1520 61.0% KIXS-AS-KR Korea Telecom AS22773 1458 110 1348 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1541 232 1309 84.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1628 396 1232 75.7% TWTC - tw telecom holdings, inc. AS1785 1833 783 1050 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1369 325 1044 76.3% NET Servicos de Comunicao S.A. AS19262 1394 400 994 71.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1394 424 970 69.6% VIETEL-AS-AP Vietel Corporation AS10620 1680 773 907 54.0% Telmex Colombia S.A. AS7303 1164 321 843 72.4% Telecom Argentina S.A. AS18101 953 155 798 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1180 411 769 65.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1414 650 764 54.0% Uninet S.A. de C.V. AS4808 1074 335 739 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1385 681 704 50.8% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1608 932 676 42.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS14420 756 91 665 88.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3356 1102 450 652 59.2% LEVEL3 Level 3 Communications AS17974 1962 1312 650 33.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4804 707 89 618 87.4% MPX-AS Microplex PTY LTD AS8402 1406 792 614 43.7% CORBINA-AS OJSC "Vimpelcom" AS17676 674 70 604 89.6% GIGAINFRA Softbank BB Corp. AS20115 1593 989 604 37.9% CHARTER-NET-HKY-NC - Charter Communications AS22561 965 362 603 62.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1052 450 602 57.2% GBLX Global Crossing Ltd. AS22047 579 33 546 94.3% VTR BANDA ANCHA S.A. AS7011 1167 643 524 44.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 908 401 507 55.8% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 41906 14188 27718 66.1% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 128.65.144.0/21 AS12886 LEWTELNET LEWTelNet GmbH 128.65.208.0/20 AS34309 LINK11 Link11 GmbH 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 193.111.87.0/24 AS24812 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mysidia at gmail.com Fri Oct 7 18:08:37 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 7 Oct 2011 18:08:37 -0500 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> Message-ID: On Fri, Oct 7, 2011 at 1:11 PM, Joly MacFie wrote: > I'd welcome comments as to solutions to this. Or is it just scaremongering? Probably scaremongering... but it does raise an interesting thought. It provides another argument why RIRs don't need to abandon justified need as a mandatory criteria for transferring addresses to specified recipients out of fear that legacy and other holders will engage in "unofficial" sales and transfers that they intentionally fail to record via WHOIS. The legacy holder/unofficial transferror would be putting the reputation of their entire address block, and their other allocations at risk; if the buyer eventually hands some of the unofficial allocation to a spammer, either by accident, or intentionally, doesn't matter. The holder of addresses that unofficially transferred them, could have some major headaches, including service-affecting headaches to their network... just to sell spare IP addresses faster for a few extra bucks; when there is a legitimate process available that doesn't have that risk? > j -- -JH From steve at pirk.com Fri Oct 7 18:34:45 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Fri, 7 Oct 2011 16:34:45 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: <201110071428.00727.lowen@pari.edu> References: <201110071428.00727.lowen@pari.edu> Message-ID: I posted a story about a domain that was one character too long on Google+. A few old-school Disney Online people remembered it enough to comment/+1 it, and agreed that it did happen. This event has bothered me for years, because everyone seemed to think long names were always possible. I kept thinking I imagined the whole thing, but it did happen after all. Too funny. https://plus.google.com/114144561369449816821/posts/MvZYRvGmH5a or http://goo.gl/WHEP3 if you prefer a shortened url. --steve On Fri, Oct 7, 2011 at 11:28, Lamar Owen wrote: > On Friday, September 30, 2011 05:54:38 PM steve pirk [egrep] wrote: > > I seem to recollect back the 1999 or 2000 times that I was unable to > > register a domain name that was 24 characters long. Shortly after that, I > > heard that the character limit had been increased to like 128 characters, > > and we were able to register the name. > > > > Can anyone offer some input, or is this a memory of a bad dream? > > ;-] > > At least as of 2008, you could go 45 characters, not counting the TLD: > ++++++++++++++++++ > $ whois pneumonoultramicroscopicsilicovolcanoconiosis.com > [Querying whois.verisign-grs.com] > [Redirected to whois.above.com] > [Querying whois.above.com] > [whois.above.com] > The Registry database contains ONLY .COM, .NET, .EDU domains and > Registrars.Registration Service Provided By: ABOVE.COM, Pty. Ltd. > Contact: +613.95897946 > > Domain Name: PNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS.COM > > Registrant: > Above.com Domain Privacy > 8 East concourse > Beaumaris > VIC > 3193 > AU > pneumonoultramicroscopicsilicovolcanoconiosis.com at privacy.above.com > Tel. +61.395897946 > Fax. > > Creation date: 2008-02-20 > Expiration Date: 2012-02-20 > ... > $ ping www.pneumonoultramicroscopicsilicovolcanoconiosis.com > PING www.pneumonoultramicroscopicsilicovolcanoconiosis.com (69.43.161.151) > 56(84) bytes of data. > 64 bytes from 69.43.161.151: icmp_req=1 ttl=50 time=85.9 ms > 64 bytes from 69.43.161.151: icmp_req=3 ttl=50 time=85.7 ms > 64 bytes from 69.43.161.151: icmp_req=4 ttl=50 time=85.8 ms > 64 bytes from 69.43.161.151: icmp_req=5 ttl=50 time=85.6 ms > ^C > --- www.pneumonoultramicroscopicsilicovolcanoconiosis.com ping statistics > --- > 5 packets transmitted, 4 received, 20% packet loss, time 4002ms > rtt min/avg/max/mdev = 85.618/85.815/85.984/0.132 ms > +++++++++++++++++++++ > > FWIW. > > -- steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From mysidia at gmail.com Fri Oct 7 18:39:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 7 Oct 2011 18:39:49 -0500 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> Message-ID: On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin wrote: > I remember tales from when there was an eight character limit. ?But that was > back when you didn't have to pay for them and they assigned you a class-c > block automatically. ?Of course it took six weeks to register because there > was only one person running the registry. You may be referring to a limitation of a certain OS regarding a hostname; or some network's policy. But the DNS protocol itself never had a limit of 8 characters. When we are talking about the contents of "A" record names, I would refer you to http://www.rfc-editor.org/rfc/rfc2181.txt "RFC 2181 Clarifications to the DNS Specification R. Elz, R. Bush [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " " Elz & Bush Standards Track [Page 12] ... Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose. ... 11. Name syntax " The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. " -- -JH From steve at pirk.com Fri Oct 7 18:45:53 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Fri, 7 Oct 2011 16:45:53 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> Message-ID: It turns out it was an artificial limitation on Network Solution's part. Being the only registrar at the time, it was pretty much internet wide at that point, contrary to the RFC spec. What was so funny was that someone got Internic/Network Solutions to up the limit. Apparently just to save some money on reprinting movie posters... ok, so they would have had to change some trailers... ;-] On Fri, Oct 7, 2011 at 16:39, Jimmy Hess wrote: > On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin wrote: > > I remember tales from when there was an eight character limit. But that > was > > back when you didn't have to pay for them and they assigned you a class-c > > block automatically. Of course it took six weeks to register because > there > > was only one person running the registry. > > You may be referring to a limitation of a certain OS regarding a > hostname; or some network's policy. > But the DNS protocol itself never had a limit of 8 characters. > When we are talking about the contents of "A" record names, > > I would refer you to > http://www.rfc-editor.org/rfc/rfc2181.txt > "RFC 2181 > Clarifications to the DNS Specification R. Elz, R. Bush > [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) > (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) > (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " > > " > Elz & Bush Standards Track [Page 12] > ... > Occasionally it is assumed that the Domain Name System serves only > the purpose of mapping Internet host names to data, and mapping > Internet addresses to host names. This is not correct, the DNS is a > general (if somewhat limited) hierarchical database, and can store > almost any kind of data, for almost any purpose. > ... > 11. Name syntax > " > The length of any one label is limited to between 1 and 63 octets. A > full domain > name is limited to 255 octets (including the separators). The zero > length full name is defined as representing the root of the DNS tree, > and is typically written and displayed as ".". Those restrictions > aside, any binary string whatever can be used as the label of any > resource record. > " > > -- > -JH > -- steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From bensons at queuefull.net Fri Oct 7 18:47:19 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 7 Oct 2011 18:47:19 -0500 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> Message-ID: <43D21289-264D-4945-AD5C-6061B35B06DF@queuefull.net> The important outcome is that transfers are documented. Making it easier for sellers to update Whois (so it points to the buyer) will encourage documentation. If "needs justification" is ever a disincentive to update Whois, then it will discourage documentation. Granted, a seller that doesn't update Whois should be more worried about the reputation of the buyer. But regardless, it is incorrect to assume that "needs justification" will prevent bad actors from acquiring address blocks. Even bad actors can justify their need, and some of them might even (*gasp*) lie about it in order to get what they want. The result would look like a normal transfer (with justified need, a Whois update, etc) and yet would result in a bad actor becoming an address holder. Cheers, -Benson On Oct 7, 2011, at 6:08 PM, Jimmy Hess wrote: > On Fri, Oct 7, 2011 at 1:11 PM, Joly MacFie wrote: >> I'd welcome comments as to solutions to this. Or is it just scaremongering? > Probably scaremongering... but it does raise an interesting thought. > > It provides another argument why RIRs don't need to abandon justified > need as a mandatory > criteria for transferring addresses to specified recipients out of > fear that legacy and other > holders will engage in "unofficial" sales and transfers that they > intentionally fail to record via WHOIS. > > The legacy holder/unofficial transferror would be putting the > reputation of their entire address block, > and their other allocations at risk; if the buyer eventually hands > some of the unofficial allocation > to a spammer, either by accident, or intentionally, doesn't matter. > > The holder of addresses that unofficially transferred them, could have > some major headaches, > including service-affecting headaches to their network... just to > sell spare IP addresses faster for > a few extra bucks; when there is a legitimate process available > that doesn't have that risk? > >> j > -- > -JH > From drc at virtualized.org Fri Oct 7 18:49:34 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Oct 2011 16:49:34 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> Message-ID: > You may be referring to a limitation of a certain OS regarding a hostname; or some network's policy. No. See http://www.ietf.org/rfc/rfc810.txt "ASSUMPTIONS 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), and the minus sign (-) and period (.). ..." This defined a policy that was imposed by "The NIC" of the time. I believe the policy was relaxed somewhat after the DNS protocol was specified which allowed domain names to be longer than the NIC's policy, and the resulting confusion necessitated the clarification in 2181. Regards, -drc From mysidia at gmail.com Fri Oct 7 18:57:45 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 7 Oct 2011 18:57:45 -0500 Subject: Botnets buying up IPv4 address space In-Reply-To: <43D21289-264D-4945-AD5C-6061B35B06DF@queuefull.net> References: <20111007173150.GA12261@vortex.com> <43D21289-264D-4945-AD5C-6061B35B06DF@queuefull.net> Message-ID: On Fri, Oct 7, 2011 at 6:47 PM, Benson Schliesser wrote: > Granted, a seller that doesn't update Whois should be more worried about the reputation of the buyer. But regardless, it is incorrect to assume that "needs justification" will prevent bad actors from acquiring address blocks. Even bad actors can justify their need, and some of them might even (*gasp*) lie about it in order to get what they want. The result would look like a normal transfer (with justified need, a Whois update, etc) and yet would result in a bad actor becoming an address holder. > Yes.... I am completely conceded to the fact that some bad actors will get all the addresses they want and more, in massive numbers. And continue to manage to get new addresses to play with, conveniently, as soon as their existing ones are blacklisted. I believe they already get all the addresses they want inexpensively, through lying to others or through illicit routing advertisements, and IPv4 exhaustion will make it harder/more expensive for the bad actors to "legitimately" get addresses that "look ok"; from the point of view of actually receiving the assignment, or the bad actor announcing address space "nobody will notice". Address exhaustion simply ultimately means there are a lot fewer addresses for bad actors to play; and they will be competing for scarce IP addresses against legitimate businesses, resulting in higher costs for bad actors attempting to utilize legitimate channels. My suggestion is that the right solution is not to try to prevent bad actors from getting addresses, but that the solution is for the bad actors to get de-peered. > Cheers, > -Benson -- -JH From dschuemann at gmail.com Fri Oct 7 19:14:44 2011 From: dschuemann at gmail.com (Dustin Schuemann) Date: Fri, 7 Oct 2011 20:14:44 -0400 Subject: Comcast Admin Message-ID: Is there a comcast admin on this list. It looks like any traffic we try to send through your network that is tagged with a dscp value of af 41 is being dropped. Please contact me off list. From owen at delong.com Fri Oct 7 20:15:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Oct 2011 18:15:30 -0700 Subject: Botnets buying up IPv4 address space In-Reply-To: <43D21289-264D-4945-AD5C-6061B35B06DF@queuefull.net> References: <20111007173150.GA12261@vortex.com> <43D21289-264D-4945-AD5C-6061B35B06DF@queuefull.net> Message-ID: On Oct 7, 2011, at 4:47 PM, Benson Schliesser wrote: > The important outcome is that transfers are documented. Making it easier for sellers to update Whois (so it points to the buyer) will encourage documentation. If "needs justification" is ever a disincentive to update Whois, then it will discourage documentation. > > Granted, a seller that doesn't update Whois should be more worried about the reputation of the buyer. But regardless, it is incorrect to assume that "needs justification" will prevent bad actors from acquiring address blocks. Even bad actors can justify their need, and some of them might even (*gasp*) lie about it in order to get what they want. The result would look like a normal transfer (with justified need, a Whois update, etc) and yet would result in a bad actor becoming an address holder. > True, however, the existence of bad actors encourages documentation even if one needs to comply with needs basis, which has many other benefits to the community. Documentation is NOT the highest single purpose of ARIN and eliminating community developed policy in favor of some mythical incentive towards documentation. Indeed, there is actually no evidence to support the theory that organizations that transfer outside of needs basis would choose to document those transfers through ARIN even if that requirement were removed. Likely if we removed needs basis, we would see the same level of undocumented transfers, but, with the added detriments of speculative address hoarding, higher artificial valuations of integers, etc. Owen > Cheers, > -Benson > > > On Oct 7, 2011, at 6:08 PM, Jimmy Hess wrote: > >> On Fri, Oct 7, 2011 at 1:11 PM, Joly MacFie wrote: >>> I'd welcome comments as to solutions to this. Or is it just scaremongering? >> Probably scaremongering... but it does raise an interesting thought. >> >> It provides another argument why RIRs don't need to abandon justified >> need as a mandatory >> criteria for transferring addresses to specified recipients out of >> fear that legacy and other >> holders will engage in "unofficial" sales and transfers that they >> intentionally fail to record via WHOIS. >> >> The legacy holder/unofficial transferror would be putting the >> reputation of their entire address block, >> and their other allocations at risk; if the buyer eventually hands >> some of the unofficial allocation >> to a spammer, either by accident, or intentionally, doesn't matter. >> >> The holder of addresses that unofficially transferred them, could have >> some major headaches, >> including service-affecting headaches to their network... just to >> sell spare IP addresses faster for >> a few extra bucks; when there is a legitimate process available >> that doesn't have that risk? >> >>> j >> -- >> -JH >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Fri Oct 7 20:16:46 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Oct 2011 18:16:46 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> Message-ID: NSI was never the only registrar. They were just the only registrar for COM, ORG, NET, EDU, and possibly a few other TLDs, but, they were, for example, never the registrar for US or many other CCTLDs. Therefore, it was not internet wide, though I will admit that it did cover most of the widely known gTLDs. Owen On Oct 7, 2011, at 4:45 PM, steve pirk [egrep] wrote: > It turns out it was an artificial limitation on Network Solution's part. > Being the only registrar at the time, it was pretty much internet wide at > that point, contrary to the RFC spec. > > What was so funny was that someone got Internic/Network Solutions to up the > limit. Apparently just to save some money on reprinting movie posters... ok, > so they would have had to change some trailers... > ;-] > > On Fri, Oct 7, 2011 at 16:39, Jimmy Hess wrote: > >> On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin wrote: >>> I remember tales from when there was an eight character limit. But that >> was >>> back when you didn't have to pay for them and they assigned you a class-c >>> block automatically. Of course it took six weeks to register because >> there >>> was only one person running the registry. >> >> You may be referring to a limitation of a certain OS regarding a >> hostname; or some network's policy. >> But the DNS protocol itself never had a limit of 8 characters. >> When we are talking about the contents of "A" record names, >> >> I would refer you to >> http://www.rfc-editor.org/rfc/rfc2181.txt >> "RFC 2181 >> Clarifications to the DNS Specification R. Elz, R. Bush >> [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) >> (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) >> (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " >> >> " >> Elz & Bush Standards Track [Page 12] >> ... >> Occasionally it is assumed that the Domain Name System serves only >> the purpose of mapping Internet host names to data, and mapping >> Internet addresses to host names. This is not correct, the DNS is a >> general (if somewhat limited) hierarchical database, and can store >> almost any kind of data, for almost any purpose. >> ... >> 11. Name syntax >> " >> The length of any one label is limited to between 1 and 63 octets. A >> full domain >> name is limited to 255 octets (including the separators). The zero >> length full name is defined as representing the root of the DNS tree, >> and is typically written and displayed as ".". Those restrictions >> aside, any binary string whatever can be used as the label of any >> resource record. >> " >> >> -- >> -JH >> > > > > -- > steve pirk > refiamerica.org > "father... the sleeper has awakened..." paul atreides - dune > kexp.org member august '09 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jra at baylink.com Fri Oct 7 21:30:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Oct 2011 22:30:52 -0400 (EDT) Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: Message-ID: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "steve pirk [egrep]" > What was so funny was that someone got Internic/Network Solutions to up the > limit. Apparently just to save some money on reprinting movie posters... ok, > so they would have had to change some trailers... > ;-] "3com.com" Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From joe at nethead.com Fri Oct 7 21:41:34 2011 From: joe at nethead.com (Joe Hamelin) Date: Fri, 7 Oct 2011 19:41:34 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> References: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Oct 7, 2011 at 7:30 PM, Jay Ashworth wrote: ----- Original Message ----- > "3com.com" I recall that 3M was originally mmm.com because they wouldn't allow a number to start a domain. /me runs whois mmm.com Yep, Created on..............: 1988-10-31. but wait, 3m.com Created on..............: 1988-05-27. So was the digit as first octet a limitation with some OS or software (BIND, sendmail, gopher?) or do I have brain-fade? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jra at baylink.com Fri Oct 7 21:43:29 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Oct 2011 22:43:29 -0400 (EDT) Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: Message-ID: <5147687.4372.1318041809880.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Hamelin" > Subject: Re: Were A record domain names ever limited to 23 characters? > On Fri, Oct 7, 2011 at 7:30 PM, Jay Ashworth wrote: > ----- Original Message ----- > > "3com.com" > > I recall that 3M was originally mmm.com because they wouldn't allow a > number to start a domain. > > /me runs whois mmm.com > > Yep, Created on..............: 1988-10-31. > > but wait, 3m.com Created on..............: 1988-05-27. > > So was the digit as first octet a limitation with some OS or software > (BIND, sendmail, gopher?) or do I have brain-fade? I would have bet good green Murrican Money that RFC 1034/5 required that it not start with a number, but I'll have to go look. No, I seem to remember pretty clearly it was administrative. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Fri Oct 7 22:25:37 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Oct 2011 20:25:37 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> Message-ID: <5C17472F-7FD2-4199-9937-A05EE57818E0@delong.com> Yes, this was because some very old (current at the time, however) implementations of gethostbyname(3) were implemented in such a way that if the first character they saw returned isdigit()==TRUE, then, they would assume that they had been passed an IP address and would attempt to encode the string as an IP address rather than looking it up in /etc/hosts or DNS. Owen On Oct 7, 2011, at 7:41 PM, Joe Hamelin wrote: > On Fri, Oct 7, 2011 at 7:30 PM, Jay Ashworth wrote: > ----- Original Message ----- >> "3com.com" > > I recall that 3M was originally mmm.com because they wouldn't allow a number > to start a domain. > > /me runs whois mmm.com > > Yep, Created on..............: 1988-10-31. > > but wait, 3m.com Created on..............: 1988-05-27. > > So was the digit as first octet a limitation with some OS or software (BIND, > sendmail, gopher?) or do I have brain-fade? > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From joe at nethead.com Fri Oct 7 22:49:25 2011 From: joe at nethead.com (Joe Hamelin) Date: Fri, 7 Oct 2011 20:49:25 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: <5C17472F-7FD2-4199-9937-A05EE57818E0@delong.com> References: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> <5C17472F-7FD2-4199-9937-A05EE57818E0@delong.com> Message-ID: On Fri, Oct 7, 2011 at 8:25 PM, Owen DeLong wrote: >Yes, this was because some very old (current at the time, however) >implementations of gethostbyname(3) were implemented in such a way that if >the first character they saw returned isdigit()==TRUE, then, >they would assume that they had been passed an IP address >and would attempt to encode the string as an IP address rather >than looking it up in /etc/hosts or DNS. Now I'm going to have to look at the current gethostbyname(3) and see what happens if we ever get a tld that is a decimal number under 255. Yet another reason for IPv6. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From johnl at iecc.com Fri Oct 7 23:58:09 2011 From: johnl at iecc.com (John Levine) Date: 8 Oct 2011 04:58:09 -0000 Subject: Telus mail server admin In-Reply-To: <4E8F1A31.5090907@paulgraydon.co.uk> Message-ID: <20111008045809.81449.qmail@joyce.lan> >That's nice for you, but some of us are stuck with a corporate policy >that requires us to use such disclaimers, or face disciplinary actions. Not to seem unsympathetic or anything, but it's not my problem if your management are idiots. Sometimes when I get a message with particularly obnoxious boilerplate threats I write back and tell them that I'm unable to answer their question since I don't accept their purported contract. And, of course, "just ignore the boilerplate" is out of the question, since if they don't have authority to remove the threat, they surely don't have authority to waive it. R's, John From randy at psg.com Sat Oct 8 00:58:02 2011 From: randy at psg.com (Randy Bush) Date: Sat, 08 Oct 2011 14:58:02 +0900 Subject: Telus mail server admin In-Reply-To: <20111008045809.81449.qmail@joyce.lan> References: <4E8F1A31.5090907@paulgraydon.co.uk> <20111008045809.81449.qmail@joyce.lan> Message-ID: >> That's nice for you, but some of us are stuck with a corporate policy >> that requires us to use such disclaimers, or face disciplinary actions. > > Not to seem unsympathetic or anything, but it's not my problem if your > management are idiots. > > Sometimes when I get a message with particularly obnoxious boilerplate > threats I write back and tell them that I'm unable to answer their > question since I don't accept their purported contract. And, of > course, "just ignore the boilerplate" is out of the question, since if > they don't have authority to remove the threat, they surely don't have > authority to waive it. From david at davidswafford.com Sat Oct 8 06:56:26 2011 From: david at davidswafford.com (David Swafford) Date: Sat, 8 Oct 2011 07:56:26 -0400 Subject: Config files? In-Reply-To: References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> Message-ID: Hey Tim, We recently bought the NCM tool by SolarWinds as well. We've had it for two months, and I personally am quite happy with it. We had Cisco's CiscoWorks product for the last 5-6 years but ditched it because of it never quite works consistently. The thing to be aware of for config auditing, like with NCM's reports, is that in some environments config is ALWAYS changing. I'm in a small enterprise setup with a very dynamic datacenter and it is not abnormal to have a few hundred changes across a week with the number of server moves/rebuilds/expansions going on in our place. So in our case, we are primarily using NCM for pushing configs, and using the alerting of changes mostly to do spot checks on the fellow team-members. Since there are so many changes, it is nice to have visibility to make sure that appropriate standards are being met. David. On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy wrote: > Hey all! > > > > I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. ?I have some experience in networking but nothing like what is mostly talked about on here. ?I just love the talks you experts have and researching the tools you all mention. ?I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday! > > > > I'm trying to put a baseline policy together for all my network equipment and I have a few questions: > > > > 1. ?Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere? > > 2. ?Are config file change alerts necessary for the security of network equipment? ?We have just purchased the SolarWinds suite. > > 3. ?Should we obfuscate our Private addresses on our Network Diagram? ?What is the common practice? > > 4. ?How can I get a grip on my ACLs or is it even possible? ?How do you all maintain them without going insane! > > > > If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction. > > > > Thanks in advance! > > > > TG > From isabeldias1 at yahoo.com Sat Oct 8 08:12:41 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Sat, 8 Oct 2011 06:12:41 -0700 (PDT) Subject: Config files? In-Reply-To: References: <22043673.4090.1317742680227.JavaMail.root@benjamin.baylink.com> <8DFDB99A-1BF5-4DCE-A8B9-F164B3D38D88@firsthand.net> Message-ID: <1318079561.99834.YahooMailNeo@web121613.mail.ne1.yahoo.com> Hi Tim, How long have you been on that position? IT Security Manager ? are you self-employed or running your own limited company? ? what areas of knowledge are you mostly interested in? where about are you based? what do you think the role of an IT Security Manager is about? ? ? ? From: David Swafford To: "Green, Timothy" Cc: NANOG Sent: Saturday, October 8, 2011 12:56 PM Subject: Re: Config files? Hey Tim, We recently bought the NCM tool by SolarWinds as well.? We've had it for two months, and I personally am quite happy with it.? We had Cisco's CiscoWorks product for the last 5-6 years but ditched it because of it never quite works consistently.? The thing to be aware of for config auditing, like with NCM's reports, is that in some environments config is ALWAYS changing.? I'm in a small enterprise setup with a very dynamic datacenter and it is not abnormal to have a few hundred changes across a week with the number of server moves/rebuilds/expansions going on in our place.? So in our case, we are primarily using NCM for pushing configs, and using the alerting of changes mostly to do spot checks on the fellow team-members.? Since there are so many changes, it is nice to have visibility to make sure that appropriate standards are being met. David. On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy wrote: > Hey all! > > > > I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. ?I have some experience in networking but nothing like what is mostly talked about on here. ?I just love the talks you experts have and researching the tools you all mention. ?I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday! > > > > I'm trying to put a baseline policy together for all my network equipment and I have a few questions: > > > > 1. ?Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere? > > 2. ?Are config file change alerts necessary for the security of network equipment? ?We have just purchased the SolarWinds suite. > > 3. ?Should we obfuscate our Private addresses on our Network Diagram? ?What is the common practice? > > 4. ?How can I get a grip on my ACLs or is it even possible? ?How do you all maintain them without going insane! > > > > If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction. > > > > Thanks in advance! > > > > TG > From reichert at numachi.com Sat Oct 8 09:59:23 2011 From: reichert at numachi.com (Brian Reichert) Date: Sat, 8 Oct 2011 10:59:23 -0400 Subject: Telus mail server admin In-Reply-To: <20111008045809.81449.qmail@joyce.lan> References: <4E8F1A31.5090907@paulgraydon.co.uk> <20111008045809.81449.qmail@joyce.lan> Message-ID: <20111008145923.GL64351@numachi.com> On Sat, Oct 08, 2011 at 04:58:09AM -0000, John Levine wrote: > >That's nice for you, but some of us are stuck with a corporate policy > >that requires us to use such disclaimers, or face disciplinary actions. > > Not to seem unsympathetic or anything, but it's not my problem if your > management are idiots. I, for one, never use a corporate account to access mailing lists. My career has spanned many jobs, and I prefer to have a contiguous footprint that _I_ control... > R's, > John -- Brian Reichert BSD admin/developer at large From fw at deneb.enyo.de Sat Oct 8 11:14:55 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 08 Oct 2011 18:14:55 +0200 Subject: Botnets buying up IPv4 address space In-Reply-To: (Christopher Morrow's message of "Fri, 7 Oct 2011 15:15:34 -0400") References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> Message-ID: <87fwj3wjcw.fsf@mid.deneb.enyo.de> * Christopher Morrow: > On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin wrote: >> >> ? ? ? ?I agree with Benson. >> >> ? ? ? ?In fact, for this "problem" I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. > > isn't this a short-lived problem then? IPv4 addresses will never run out in a strict sense of the word, it will just become increasingly more difficult to reassign IPv4 address space to those who need it. From mysidia at gmail.com Sat Oct 8 11:35:52 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 8 Oct 2011 11:35:52 -0500 Subject: Botnets buying up IPv4 address space In-Reply-To: <87fwj3wjcw.fsf@mid.deneb.enyo.de> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> <87fwj3wjcw.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Oct 8, 2011 at 11:14 AM, Florian Weimer wrote: > IPv4 addresses will never run out in a strict sense of the word, it > will just become increasingly more difficult to reassign IPv4 address > space to those who need it. And hopefully... the greater the address space "pressure" or contention there is for IPv4 address resources, the more strongly organizations will feel compelled towards swapping over to IPv6 :) -- -JH From aroman at ziplink.net Sat Oct 8 22:26:05 2011 From: aroman at ziplink.net (Alex Romanauskas) Date: Sat, 8 Oct 2011 23:26:05 -0400 Subject: NeuStar locality .us domains. Message-ID: I know it's not very common these days but I am a big fan of the ..us domain structure as it was setup 25+ years ago. Having been in the ISP industry for more than half that time I have also dealt with 100's of these registrations although maybe only 25 in the last year. Guess I have been lucky since all of them were with previously delegated localities. So today I go to register a domain for a friend, in what I consider to be a large enough city to have at least been delegated in the past (Lowell, MA) but of course it is currently assigned to NeuStar. I send in the request anyways, figuring there will just be some additional paperwork. This is the response I receive. ..... The US Department of Commerce has specifically stated that only certain 4th level domains can be registered until further notice. The DoC has only allowed us to register fourth level domain names beginning with "borough", "ci." for city, "co." for county, "twp." or "town" for township, or "vil." for village. ..... I have had a couple back and forths with there support department. Waiting for a response coming during the work week. Does anyone know the actual status of the locality .us structure? Are they trying to push people to the .us pay domains? Isn't NeuStar up for renewal on their last 1 year extension? -- Alex Romanauskas ZipLink / GNAPs From millnert at gmail.com Sun Oct 9 07:10:09 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 9 Oct 2011 14:10:09 +0200 Subject: Botnets buying up IPv4 address space In-Reply-To: <87fwj3wjcw.fsf@mid.deneb.enyo.de> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> <87fwj3wjcw.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Oct 8, 2011 at 6:14 PM, Florian Weimer wrote: > IPv4 addresses will never run out in a strict sense of the word, it > will just become increasingly more difficult to reassign IPv4 address > space to those who need it. If you by difficult mean expensive, then I agree. Regards, Martin From millnert at gmail.com Sun Oct 9 07:16:25 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 9 Oct 2011 14:16:25 +0200 Subject: Botnets buying up IPv4 address space In-Reply-To: <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> Message-ID: Arturo, On Fri, Oct 7, 2011 at 8:59 PM, Arturo Servin wrote: > ? ? ? ?ARIN and APNIC allows it, LACNIC will when it reaches the last /12 (so now is not possible). RIPE NCC and Afrinic do not have a policy yet AFAIK. RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*. https://www.ripe.net/lir-services/resource-management/listing Regards, Martin From arturo.servin at gmail.com Sun Oct 9 08:51:28 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 9 Oct 2011 11:51:28 -0200 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> Message-ID: Thanks, I didn't know that one. I followed the link to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" and seems a good and simple approach. Regards, .as On 9 Oct 2011, at 10:16, Martin Millnert wrote: > Arturo, > > On Fri, Oct 7, 2011 at 8:59 PM, Arturo Servin wrote: >> ARIN and APNIC allows it, LACNIC will when it reaches the last /12 (so now is not possible). RIPE NCC and Afrinic do not have a policy yet AFAIK. > > RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*. > https://www.ripe.net/lir-services/resource-management/listing > > Regards, > Martin From dougm at nist.gov Sun Oct 9 11:19:48 2011 From: dougm at nist.gov (Montgomery, Douglas) Date: Sun, 9 Oct 2011 12:19:48 -0400 Subject: Announcing BGP Secure Router Extension (BGP-SRx) Prototype Implementation Message-ID: Announcing BGP Secure Router Extension (BGP-SRx) Prototype Implementation IETF SIDR working group is developing standards for BGP origin validation and AS path validation to strengthen the inter-domain routing infrastructure. At the IETF 80 in March 2011, NIST made an introductory presentation on a prototyping effort called BGP Secure Router Extension (BGP-SRx). SRx is an open source reference implementation and research platform for investigating emerging BGP security extensions and supporting protocols. BGP-SRx has three parts: SRx Server, SRx API, and Quagga SRx (integrates SRx API into Quagga router). The current focus in the BGP-SRx prototype is on origin validation, although it is designed to be be extended to path validation in the future (some stub functionality is already included in this version). The current release implements: The RPKI/Router Protocol and a variety of BGP policies for enforcing Route Origin Authorizations (ROAs) conveyed from RPKI validating caches. Also included in the release are test client/server test harnesses for RPKI/Router and WireShark modules for debugging. For more information on BGP-SRx, and to download the prototype and tools, see: http://www-x.antd.nist.gov/bgpsrx/ For those wanting an easy way to experiment with BGP-SRx, in June we made an announcement about the BRITE system (BGPSEC/RPKI Interoperability Test & Evaluation): http://mailman.nanog.org/pipermail/nanog/2011-June/038063.html You can use BRITE (http://brite.antd.nist.gov/) to run BGP-SRx (or any other implementation) through aseries of test scripts that exercise numerous interesting scenarios for BGP ROA processing under different policy assumptions. We will make a presentation at NANOG-53 on Monday (9/10/11) in the ISP Security BoF where we will briefly explain the functionalities of both BGP-SRx and BRITE and also give demos. Please attend the BoF if you are interested to learn more. Comments and feedback about SRx and BRITE are welcome. See the project page For details. dougm -- Doug Montgomery ? Mgr. Internet & Scalable Systems Research / ITL / NIST From johnl at iecc.com Sun Oct 9 14:53:37 2011 From: johnl at iecc.com (John Levine) Date: 9 Oct 2011 19:53:37 -0000 Subject: NeuStar locality .us domains. In-Reply-To: Message-ID: <20111009195337.10339.qmail@joyce.lan> As far as I can tell, locality domains with live registrars can continue doing whatever we've been doing, and existing 4LDs from the pre-Neustar days still work, but they are not delegating any more of them. My ancient iecc.cambridge.ma.us still gets tons of spam (handy for filter tuning), and I'm still authoritative for domains like these: http://www.watkins-glen.ny.us/ http://www.interlaken.ny.us/ http://www.seneca.ny.us/ http://www.schuyler.ny.us/ R's, John From joelja at bogus.com Sun Oct 9 20:09:34 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 09 Oct 2011 18:09:34 -0700 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <2F65C566-6628-468A-9BA1-089E84C060DE@queuefull.net> <82A2ECDC-13EC-48CF-896B-4C387DEE5512@gmail.com> <87fwj3wjcw.fsf@mid.deneb.enyo.de> Message-ID: <4E9245CE.1080608@bogus.com> On 10/9/11 05:10 , Martin Millnert wrote: > On Sat, Oct 8, 2011 at 6:14 PM, Florian Weimer wrote: >> IPv4 addresses will never run out in a strict sense of the word, it >> will just become increasingly more difficult to reassign IPv4 address >> space to those who need it. > > If you by difficult mean expensive, then I agree. there are several kinds of transactional friction, some are easily denominated in dollars, > Regards, > Martin > From tore.anderson at redpill-linpro.com Mon Oct 10 01:23:20 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 10 Oct 2011 08:23:20 +0200 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> Message-ID: <4E928F58.8040402@redpill-linpro.com> * Martin Millnert > RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*. I wonder if that one was listed by mistake. The prefix in question, 128.0.16.0/20, was assigned to NetWave Ltd. by the NCC last Tuesday. If it isn't a mistake, I wonder how they justified obtaining the prefix in the first place. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From kristen.eisenberg at yahoo.com Mon Oct 10 05:43:02 2011 From: kristen.eisenberg at yahoo.com (Kristen Eisenberg) Date: Mon, 10 Oct 2011 03:43:02 -0700 (PDT) Subject: Amazon diagnosis Message-ID: <1318243382.40556.YahooMailNeo@web122308.mail.ne1.yahoo.com> Sure they can, but as a thought exercise fully 2n redundancy is difficult on a small scale for anything web facing. I've seen a very simple implementation for a website requiring 5 9's that consumed over $50k in equipment, and this wasn't even geographically diverse. I have to believe that scaling up the concept of "doing it right" results in exponential cost increases. To illustrate the problem, I would give you the first step in the thought exercise: first find two datacenters with diverse carriers, that aren't on the same regional power grid (As we've learned in the (iirc) 2003 power outage, New York and DC won't work, nor will Ohio, so you need redundant teams to cover a very remote site). Kristen Eisenberg Billige Fl?ge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Fl?ge vergleichen From randy at psg.com Mon Oct 10 07:28:38 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 08:28:38 -0400 Subject: meeting network Message-ID: perhaps as an educational exercise in network troubleshooting whoever is operating the meeting network could explain what the frack is wrong with the meeting network, how it is being debugged, and what they have learned about the cause of the suckage. randy From nick at foobar.org Mon Oct 10 07:46:54 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Oct 2011 13:46:54 +0100 Subject: meeting network In-Reply-To: References: Message-ID: <4E92E93E.5070109@foobar.org> On 10/10/2011 13:28, Randy Bush wrote: > perhaps as an educational exercise in network troubleshooting whoever is > operating the meeting network could explain what the frack is wrong with > the meeting network, how it is being debugged, and what they have > learned about the cause of the suckage. if it's wifi that's causing the trouble, the usual causes are: - insufficient density of APs for the number of clients - APs configured with TX too high (should be set as low as possible) - APs configured to accept dot11b <= 9 megs - APs configured to use auto channel selection - stupid broken clients screaming at high volume across the room to APs which are impossibly far away There is a more fundamental problem, though: wifi was not designed with crazyass density in mind. Bring back UTP? Nick From rdobbins at arbor.net Mon Oct 10 08:01:40 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 10 Oct 2011 13:01:40 +0000 Subject: meeting network In-Reply-To: <4E92E93E.5070109@foobar.org> References: <4E92E93E.5070109@foobar.org> Message-ID: <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> On Oct 10, 2011, at 7:46 PM, Nick Hilliard wrote: > if it's wifi that's causing the trouble, the usual causes are: Don't forget RFI and various forms of spoofing used for MITM. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From morrowc.lists at gmail.com Mon Oct 10 08:50:48 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Oct 2011 09:50:48 -0400 Subject: meeting network In-Reply-To: <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: On Mon, Oct 10, 2011 at 9:01 AM, Dobbins, Roland wrote: > On Oct 10, 2011, at 7:46 PM, Nick Hilliard wrote: > >> if it's wifi that's causing the trouble, the usual causes are: is the complaint the hotel ROOM wireless? or the meeting-room? I noticed the nanog-a-secure bounce me 2x, so I moved back to ipsec-tunnel on nanog-a.. in the past nanog (plain) has been more 'stable' for me in general (and all you mac users can happily fight over -a!) As to the hotel room wifi... apparently when you have 490 rooms in the hotel (full) and only provision your internal NAT space as a /23 ... things work 'fine' most days. When a networking conference comes to visit with 3+ devices requiring IP in each room... the whole hotel network stops :( Last night the display systems in the lobby and the hotel registration machines were all broken :( The hotel's network people (in NYC) are supposedly 'on a fix', who knows... (is expanding the nat subnet THAT hard?) -chris From randy at psg.com Mon Oct 10 08:54:32 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 09:54:32 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: >>> if it's wifi that's causing the trouble, the usual causes are: > is the complaint the hotel ROOM wireless? or the meeting-room? meeting net, a-secure and a. really bad during the night, but still bouncing up until 08:30 when i turned laptop off to participate in breakfast. and conjecturbation as to what the problem was is amusing at best. i asked for actual diagnosis from whover is running the net. randy From richard.barnes at gmail.com Mon Oct 10 08:56:54 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 10 Oct 2011 09:56:54 -0400 Subject: meeting network In-Reply-To: <4E92E93E.5070109@foobar.org> References: <4E92E93E.5070109@foobar.org> Message-ID: Problem for me at least has not been the MAC layer (either hotel room or meeting room), it was that the DHCP server was not responding. Ironically, I could still see everyone's Bonjour and SMB service advertisements. --Richard On Mon, Oct 10, 2011 at 8:46 AM, Nick Hilliard wrote: > On 10/10/2011 13:28, Randy Bush wrote: >> perhaps as an educational exercise in network troubleshooting whoever is >> operating the meeting network could explain what the frack is wrong with >> the meeting network, how it is being debugged, and what they have >> learned about the cause of the suckage. > > if it's wifi that's causing the trouble, the usual causes are: > > - insufficient density of APs for the number of clients > - APs configured with TX too high (should be set as low as possible) > - APs configured to accept dot11b <= 9 megs > - APs configured to use auto channel selection > - stupid broken clients screaming at high volume across the room to APs > which are impossibly far away > > There is a more fundamental problem, though: ?wifi was not designed with > crazyass density in mind. > > Bring back UTP? > > Nick > > From jared at puck.nether.net Mon Oct 10 07:57:40 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 Oct 2011 08:57:40 -0400 Subject: meeting network In-Reply-To: <4E92E93E.5070109@foobar.org> References: <4E92E93E.5070109@foobar.org> Message-ID: <7E034EAE-D707-486E-B889-3B9FD7AFE781@puck.nether.net> On Oct 10, 2011, at 8:46 AM, Nick Hilliard wrote: > On 10/10/2011 13:28, Randy Bush wrote: >> perhaps as an educational exercise in network troubleshooting whoever is >> operating the meeting network could explain what the frack is wrong with >> the meeting network, how it is being debugged, and what they have >> learned about the cause of the suckage. > > if it's wifi that's causing the trouble, the usual causes are: > > - insufficient density of APs for the number of clients > - APs configured with TX too high (should be set as low as possible) > - APs configured to accept dot11b <= 9 megs > - APs configured to use auto channel selection > - stupid broken clients screaming at high volume across the room to APs > which are impossibly far away > > There is a more fundamental problem, though: wifi was not designed with > crazyass density in mind. I'm not seeing the problem, but have heard one other person say they are having trouble. Perhaps some details of the problem you are seeing would help diagnose the troubles as there are many of us who are not seeing it. I am using the 'NANOG-a' network without trouble. - Jared From nick at foobar.org Mon Oct 10 08:59:57 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Oct 2011 14:59:57 +0100 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <4E92FA5D.1000104@foobar.org> On 10/10/2011 14:50, Christopher Morrow wrote: > hotel registration machines were all broken :( The hotel's network > people (in NYC) are supposedly 'on a fix', who knows... (is expanding > the nat subnet THAT hard?) Sigh, if only there were people somewhere near the hotel who knew how to configure this sort of stuff... Nick From owen at delong.com Mon Oct 10 09:00:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Oct 2011 07:00:43 -0700 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: On Oct 10, 2011, at 6:50 AM, Christopher Morrow wrote: > On Mon, Oct 10, 2011 at 9:01 AM, Dobbins, Roland wrote: >> On Oct 10, 2011, at 7:46 PM, Nick Hilliard wrote: >> >>> if it's wifi that's causing the trouble, the usual causes are: > > is the complaint the hotel ROOM wireless? or the meeting-room? I > noticed the nanog-a-secure bounce me 2x, so I moved back to > ipsec-tunnel on nanog-a.. in the past nanog (plain) has been more > 'stable' for me in general (and all you mac users can happily fight > over -a!) > > As to the hotel room wifi... apparently when you have 490 rooms in the > hotel (full) and only provision your internal NAT space as a /23 ... > things work 'fine' most days. When a networking conference comes to > visit with 3+ devices requiring IP in each room... the whole hotel > network stops :( Last night the display systems in the lobby and the > hotel registration machines were all broken :( The hotel's network > people (in NYC) are supposedly 'on a fix', who knows... (is expanding > the nat subnet THAT hard?) > > -chris It would be wise for NANOG to approach future venues and specifically discuss these things with the hotel IT departments in question ahead of time so that they have some remote chance of being prepared. Owen From rcarpen at network1.net Mon Oct 10 09:20:22 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Oct 2011 10:20:22 -0400 (EDT) Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: On the hotel network, I have also seen some issues beyond getting an address. I can usually trace just fine, but applications, specifically web is extremely slow, or non responsive. The hotel appears to be shoving all traffic through a squid proxy, which does not appear to be big enough to handle the traffic. I have gotten various error messages from squid. I would think that the contract with the hotel for the conference would include the specific requirements for the network. Is that not the case? -Randy On Oct 10, 2011, at 10:01, Owen DeLong wrote: > > On Oct 10, 2011, at 6:50 AM, Christopher Morrow wrote: > >> On Mon, Oct 10, 2011 at 9:01 AM, Dobbins, Roland wrote: >>> On Oct 10, 2011, at 7:46 PM, Nick Hilliard wrote: >>> >>>> if it's wifi that's causing the trouble, the usual causes are: >> >> is the complaint the hotel ROOM wireless? or the meeting-room? I >> noticed the nanog-a-secure bounce me 2x, so I moved back to >> ipsec-tunnel on nanog-a.. in the past nanog (plain) has been more >> 'stable' for me in general (and all you mac users can happily fight >> over -a!) >> >> As to the hotel room wifi... apparently when you have 490 rooms in the >> hotel (full) and only provision your internal NAT space as a /23 ... >> things work 'fine' most days. When a networking conference comes to >> visit with 3+ devices requiring IP in each room... the whole hotel >> network stops :( Last night the display systems in the lobby and the >> hotel registration machines were all broken :( The hotel's network >> people (in NYC) are supposedly 'on a fix', who knows... (is expanding >> the nat subnet THAT hard?) >> >> -chris > > It would be wise for NANOG to approach future venues and specifically discuss these things with the hotel IT departments in question ahead of time so that they have some remote chance of being prepared. > > Owen > > > From randy at psg.com Mon Oct 10 09:44:12 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 10:44:12 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: > I would think that the contract with the hotel for the conference > would include the specific requirements for the network. Is that not > the case? underlying problems o no hotel believe that we'll actually be significantly high use. they simply can not conceive of it. ietf, apricot, ... have seen this time and time again o the hotel does not manage the network, so you have two comms hops to anyone who can do anything. and anyway, they are not going to provision more bandwidth but the problems of which i spoke were the meeting network. which we do supposedly control. randy From randy at psg.com Mon Oct 10 09:51:13 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 10:51:13 -0400 Subject: slides Message-ID: i can not seem to see slides for this morning on http://www.nanog.org/meetings/nanog53/agenda.html what am i doing wrongly? randy From michael at rancid.berkeley.edu Mon Oct 10 09:52:17 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 10 Oct 2011 07:52:17 -0700 (PDT) Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: On Mon, 10 Oct 2011, Randy Bush wrote: >>>> if it's wifi that's causing the trouble, the usual causes are: >> is the complaint the hotel ROOM wireless? or the meeting-room? > > meeting net, a-secure and a. really bad during the night, but still > bouncing up until 08:30 when i turned laptop off to participate in > breakfast. > > and conjecturbation as to what the problem was is amusing at best. i > asked for actual diagnosis from whover is running the net. I am noticing far worse performance and reliability with IPv6 as opposed to IPv4. For a good 10 minutes until just now there was *no* IPv6 routing even to the first hop, but IPv4 was still "working." Now things are merely slow, not broken. I also got bounced a few times from -secure and -a and when I got back I couldn't get an address (IPv4 or IPv6) for some time. Conjecturbation: They're using an old proteon router and someone is exhausting its arp and ndp caches. michael From randy at psg.com Mon Oct 10 09:53:57 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 10:53:57 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: > Conjecturbation: They're using an old proteon router and someone is > exhausting its arp and ndp caches. i wanna picture! From richard.barnes at gmail.com Mon Oct 10 10:01:06 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 10 Oct 2011 11:01:06 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: VPN traffic was also slow / bursty. So I guess there's some capacity issues as well as layer 7 cruft. On Oct 10, 2011 10:20 AM, "Randy Carpenter" wrote: On the hotel network, I have also seen some issues beyond getting an address. I can usually trace just fine, but applications, specifically web is extremely slow, or non responsive. The hotel appears to be shoving all traffic through a squid proxy, which does not appear to be big enough to handle the traffic. I have gotten various error messages from squid. I would think that the contract with the hotel for the conference would include the specific requirements for the network. Is that not the case? -Randy On Oct 10, 2011, at 10:01, Owen DeLong wrote: > > On Oct 10, 2011, at 6:50 AM, ... From tkapela at gmail.com Mon Oct 10 10:01:36 2011 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 10 Oct 2011 11:01:36 -0400 Subject: nanog53 network status Message-ID: Attendees, At present, we're aware of several issues affecting access to the NANOG attendee network -- in short, they include: -Apparent 'lumping' of iDevices, picking 11b/g channels of "1" and "6" (while channel 11 AP's sid idly by); adjusting additional AP's power and channel configuration to perturb this sub-optimal client selection logic. -AP's were permitting all frame bitrates (1 through 54 mbit encodings); these have been adjusted to include 5.5 mbits (cck, b) and 12 mbits (ofdm, g) encodings or greater (this reduces transmission duty cycles, frees up airtime, reduces contention, and hopefully performs better). -DHCP timer was set at 600 seconds; I'm informed that the lease time was increased to 3600 seconds at ~10:30AM PST today. Please relay any outstanding issues my way--I'll route to Verilan, which is handling the network and wireless support for the meeting. Best, -Tk From jmkeller at houseofzen.org Mon Oct 10 10:01:54 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Mon, 10 Oct 2011 11:01:54 -0400 Subject: Enterprise WiFi list recommendations? Message-ID: <4E9308E2.8090301@houseofzen.org> All, I'm looking for some mailing list recommendations for wifi operations community, any commendations? Thanks in advance. -- --- James M Keller From wesley.george at twcable.com Mon Oct 10 10:02:18 2011 From: wesley.george at twcable.com (George, Wes) Date: Mon, 10 Oct 2011 11:02:18 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <34E4F50CAFA10349A41E0756550084FB11D940A9@PRVPEXVS04.corp.twcable.com> o no hotel believe that we'll actually be significantly high use. they simply can not conceive of it. ietf, apricot, ... have seen this time and time again WEG] this is a problem that is quite solvable via the careful application of real data from past events I assume most of these conferences can track number of unique devices seen (by MAC address) peak and total, show peak and average network usage BW graphs, etc. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jmkeller at houseofzen.org Mon Oct 10 10:04:07 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Mon, 10 Oct 2011 11:04:07 -0400 Subject: Enterprise WiFi list recommendations? In-Reply-To: <4E9308E2.8090301@houseofzen.org> References: <4E9308E2.8090301@houseofzen.org> Message-ID: <4E930967.3010909@houseofzen.org> On 10/10/2011 11:01 AM, James M Keller wrote: > All, > > I'm looking for some mailing list recommendations for wifi operations > community, any commendations? > > Thanks in advance. > Besides a proofreader :) -- --- James M Keller From Valdis.Kletnieks at vt.edu Mon Oct 10 10:10:07 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Oct 2011 11:10:07 -0400 Subject: meeting network In-Reply-To: Your message of "Mon, 10 Oct 2011 10:44:12 EDT." References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <13165.1318259407@turing-police.cc.vt.edu> On Mon, 10 Oct 2011 10:44:12 EDT, Randy Bush said: > o no hotel believe that we'll actually be significantly high use. > they simply can not conceive of it. ietf, apricot, ... have > seen this time and time again To be fair, that's not a hotel-only problem. We've seen that problem within the IT industry. Actual discussion with a vendor who wanted to analyze our logs so they could size a solution: "Send us a day's worth of logs" "OK" ... "We said a *day's* worth, not a *week*". "That *was* a day" "Wow, that logfile was huge, we didn't think anybody actually did that much traffic a day..." The sad part was that the vendor in question *really* should have known better, we're pretty sure they targeted their solution at many sites bigger than us. Or maybe the other sites are bigger, but we pound the bejeebers out of stuff. I dunno. -------------- 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 Mon Oct 10 10:11:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 10 Oct 2011 11:11:15 -0400 Subject: Enterprise WiFi list recommendations? In-Reply-To: Your message of "Mon, 10 Oct 2011 11:04:07 EDT." <4E930967.3010909@houseofzen.org> References: <4E9308E2.8090301@houseofzen.org> <4E930967.3010909@houseofzen.org> Message-ID: <13230.1318259475@turing-police.cc.vt.edu> On Mon, 10 Oct 2011 11:04:07 EDT, James M Keller said: > On 10/10/2011 11:01 AM, James M Keller wrote: > > All, > > > > I'm looking for some mailing list recommendations for wifi operations > > community, any commendations? > > > > Thanks in advance. > > > Besides a proofreader :) No, commendations are in order, if a list has proven to be exemplary in quality. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ryanczak at gmail.com Mon Oct 10 10:28:03 2011 From: ryanczak at gmail.com (Matt Ryanczak) Date: Mon, 10 Oct 2011 11:28:03 -0400 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <4E930F03.7060108@gmail.com> On 10/10/11 10:20 AM, Randy Carpenter wrote: > I would think that the contract with the hotel for the conference would include the specific requirements for the network. Is that not the case? My experiences planning and operating ARIN meeting networks taught me that it is difficult if not impossible to get a hotel make any changes to in room based wireless or wired networking. Often times they have contracts with third parties and don't actually have any control over how the network operates or issues such as capacity. This can also include an inability to disable access points or otherwise limit the ability of the contracted service provider to provide access to rooms. In room access is always something that we looked at when judging potential venues but the poor state of most in room Internet access infrastructure and the realities of existing business relationships made this a nice to have rather than a hard requirement. From arturo.servin at gmail.com Mon Oct 10 10:59:10 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 10 Oct 2011 13:59:10 -0200 Subject: DPI deployment use case In-Reply-To: References: Message-ID: <4BA0B1DD-93D2-41CA-AECA-BACBD9E75A2E@gmail.com> I imagine that those proposals are not from users ? I would add "tyrannical" telcos cracking down on their own customers. -as On 7 Oct 2011, at 14:20, Claudio Lapidus wrote: > Hello, > > On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert wrote: > >> I've seen tyrannical governments use Bluecoat's to crack down on their >> own population(*). >> Was this the sort of use-case you were looking for? :) >> > Ummm, not really... :) > > Actually, we've been faced with proposals to build services based on traffic > classification, like e.g. "access our own webmail and all social networking > sites, but not skype and video" or the capability to do exact metering based > on net traffic time or volume, as well as being able to redirect the > customer to various captive portals using HTTP redirect directly from the > DPI box, and such. From tom at dyn.com Mon Oct 10 11:24:25 2011 From: tom at dyn.com (Tom Daly) Date: Mon, 10 Oct 2011 12:24:25 -0400 (EDT) Subject: slides In-Reply-To: Message-ID: <618af8fa-7538-4e1d-8397-f27abbd09338@dhcp-220-185.meetings.nanog.org> Randy, Posting delay. Fixed. Tom ----- Original Message ----- > From: "Randy Bush" > To: "North American Network Operators' Group" > Sent: Monday, October 10, 2011 10:51:13 AM > Subject: slides > > i can not seem to see slides for this morning on > http://www.nanog.org/meetings/nanog53/agenda.html > > what am i doing wrongly? > > randy > > From nick at foobar.org Mon Oct 10 11:43:35 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Oct 2011 17:43:35 +0100 Subject: nanog53 network status In-Reply-To: References: Message-ID: <4E9320B7.7080407@foobar.org> On 10/10/2011 16:01, Anton Kapela wrote: > Please relay any outstanding issues my way--I'll route to Verilan, > which is handling the network and wireless support for the meeting. If Verilan has the ability to limit client power settings, these should also be reduced as far as possible. Some drivers ignore these hints, because the software driver authors know that MOAR POWER means better connectivity, right?. Verilan may find that completely disabling a tiny number of badly-behaved clients can dramatically improve quality of service for everyone else. Nick From frnkblk at iname.com Mon Oct 10 12:12:27 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 10 Oct 2011 12:12:27 -0500 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <001201cc876f$c9307ee0$5b917ca0$@iname.com> Then the RFP for the meeting needs to be more specific with some basic SLAs that result in a smaller bill if not met. Frank -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, October 10, 2011 9:44 AM To: Randy Carpenter Cc: North American Network Operators' Group Subject: Re: meeting network > I would think that the contract with the hotel for the conference > would include the specific requirements for the network. Is that not > the case? underlying problems o no hotel believe that we'll actually be significantly high use. they simply can not conceive of it. ietf, apricot, ... have seen this time and time again o the hotel does not manage the network, so you have two comms hops to anyone who can do anything. and anyway, they are not going to provision more bandwidth but the problems of which i spoke were the meeting network. which we do supposedly control. randy From frnkblk at iname.com Mon Oct 10 12:14:15 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 10 Oct 2011 12:14:15 -0500 Subject: Enterprise WiFi list recommendations? In-Reply-To: <4E9308E2.8090301@houseofzen.org> References: <4E9308E2.8090301@houseofzen.org> Message-ID: <001f01cc8770$09d961f0$1d8c25d0$@iname.com> In the EDU world go to EDUCAUSE' WIRELESS-LAN listserv -- archives are online. Frank -----Original Message----- From: James M Keller [mailto:jmkeller at houseofzen.org] Sent: Monday, October 10, 2011 10:02 AM To: nanog at nanog.org Subject: Enterprise WiFi list recommendations? All, I'm looking for some mailing list recommendations for wifi operations community, any commendations? Thanks in advance. -- --- James M Keller From jared at puck.nether.net Mon Oct 10 12:20:37 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 Oct 2011 13:20:37 -0400 Subject: meeting network In-Reply-To: <001201cc876f$c9307ee0$5b917ca0$@iname.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <001201cc876f$c9307ee0$5b917ca0$@iname.com> Message-ID: In my historical knowledge of this: there are only so many venues that can have 500-650 people and fit. Jared Mauch On Oct 10, 2011, at 1:12 PM, "Frank Bulk" wrote: > Then the RFP for the meeting needs to be more specific with some basic SLAs > that result in a smaller bill if not met. > > Frank > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, October 10, 2011 9:44 AM > To: Randy Carpenter > Cc: North American Network Operators' Group > Subject: Re: meeting network > >> I would think that the contract with the hotel for the conference >> would include the specific requirements for the network. Is that not >> the case? > > underlying problems > > o no hotel believe that we'll actually be significantly high use. > they simply can not conceive of it. ietf, apricot, ... have > seen this time and time again > > o the hotel does not manage the network, so you have two comms hops > to anyone who can do anything. and anyway, they are not going to > provision more bandwidth > > but the problems of which i spoke were the meeting network. which we > do supposedly control. > > randy > > > From rcarpen at network1.net Mon Oct 10 12:29:13 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Oct 2011 13:29:13 -0400 (EDT) Subject: meeting network In-Reply-To: Message-ID: I have been at other conference that have triple or more participants, and it has never been anything close to the issues we are having at this hotel. Slightly slower performance is expected. Completely not working is not. -Randy ----- Original Message ----- > In my historical knowledge of this: there are only so many venues > that can have 500-650 people and fit. > > Jared Mauch > > On Oct 10, 2011, at 1:12 PM, "Frank Bulk" wrote: > > > Then the RFP for the meeting needs to be more specific with some > > basic SLAs > > that result in a smaller bill if not met. > > > > Frank > > > > -----Original Message----- > > From: Randy Bush [mailto:randy at psg.com] > > Sent: Monday, October 10, 2011 9:44 AM > > To: Randy Carpenter > > Cc: North American Network Operators' Group > > Subject: Re: meeting network > > > >> I would think that the contract with the hotel for the conference > >> would include the specific requirements for the network. Is that > >> not > >> the case? > > > > underlying problems > > > > o no hotel believe that we'll actually be significantly high use. > > they simply can not conceive of it. ietf, apricot, ... have > > seen this time and time again > > > > o the hotel does not manage the network, so you have two comms > > hops > > to anyone who can do anything. and anyway, they are not going > > to > > provision more bandwidth > > > > but the problems of which i spoke were the meeting network. which > > we > > do supposedly control. > > > > randy > > > > > > > > From nweis at verilan.com Mon Oct 10 12:54:58 2011 From: nweis at verilan.com (Noah Weis) Date: Mon, 10 Oct 2011 13:54:58 -0400 Subject: nanog53 network status In-Reply-To: <4E9320B7.7080407@foobar.org> References: <4E9320B7.7080407@foobar.org> Message-ID: Nick, we actually do limit the client power settings, by default, for the very reasons you mention. Noah On Mon, Oct 10, 2011 at 12:43 PM, Nick Hilliard wrote: > On 10/10/2011 16:01, Anton Kapela wrote: > > Please relay any outstanding issues my way--I'll route to Verilan, > > which is handling the network and wireless support for the meeting. > > If Verilan has the ability to limit client power settings, these should > also be reduced as far as possible. Some drivers ignore these hints, > because the software driver authors know that MOAR POWER means better > connectivity, right?. Verilan may find that completely disabling a tiny > number of badly-behaved clients can dramatically improve quality of service > for everyone else. > > Nick > > > -- Noah K. Weis Verilan, Inc. m: +1-503-902-2491 From morrowc.lists at gmail.com Mon Oct 10 12:58:04 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Oct 2011 13:58:04 -0400 Subject: meeting network In-Reply-To: References: Message-ID: On Mon, Oct 10, 2011 at 1:29 PM, Randy Carpenter wrote: > > I have been at other conference that have triple or more participants, and it has never been anything close to the issues we are having at this hotel. Slightly slower performance is expected. Completely not working is not. hotel or meeting ? (which network are we talking about now?) From jcdill.lists at gmail.com Mon Oct 10 13:07:55 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 10 Oct 2011 11:07:55 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <23307697.4362.1318041052104.JavaMail.root@benjamin.baylink.com> Message-ID: <4E93347B.4000104@gmail.com> On 07/10/11 7:41 PM, Joe Hamelin wrote: > On Fri, Oct 7, 2011 at 7:30 PM, Jay Ashworth wrote: > ----- Original Message ----- >> "3com.com" > I recall that 3M was originally mmm.com because they wouldn't allow a number > to start a domain. > > /me runs whois mmm.com > > Yep, Created on..............: 1988-10-31. > > but wait, 3m.com Created on..............: 1988-05-27. > > So was the digit as first octet a limitation with some OS or software (BIND, > sendmail, gopher?) or do I have brain-fade? http://www.ietf.org/rfc/rfc810.txt ASSUMPTIONS 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), and the minus sign (-) and period (.). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be a letter. From randy at psg.com Mon Oct 10 13:19:15 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 14:19:15 -0400 Subject: slides In-Reply-To: <618af8fa-7538-4e1d-8397-f27abbd09338@dhcp-220-185.meetings.nanog.org> References: <618af8fa-7538-4e1d-8397-f27abbd09338@dhcp-220-185.meetings.nanog.org> Message-ID: thanks! From rcarpen at network1.net Mon Oct 10 13:21:54 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Oct 2011 14:21:54 -0400 (EDT) Subject: meeting network In-Reply-To: Message-ID: <071fd0bf-6688-4d6f-870e-c90dd830de14@zimbra.network1.net> Sorry, talking about the hotel network now. -Randy ----- Original Message ----- > On Mon, Oct 10, 2011 at 1:29 PM, Randy Carpenter > wrote: > > > > I have been at other conference that have triple or more > > participants, and it has never been anything close to the issues > > we are having at this hotel. Slightly slower performance is > > expected. Completely not working is not. > > hotel or meeting ? (which network are we talking about now?) > > From owen at delong.com Mon Oct 10 13:23:29 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Oct 2011 11:23:29 -0700 Subject: meeting network In-Reply-To: References: Message-ID: <2CD7C74B-92F2-46D8-8CDC-FD75B0960130@delong.com> +1 On Oct 10, 2011, at 10:29 AM, Randy Carpenter wrote: > > I have been at other conference that have triple or more participants, and it has never been anything close to the issues we are having at this hotel. Slightly slower performance is expected. Completely not working is not. > > -Randy > > ----- Original Message ----- >> In my historical knowledge of this: there are only so many venues >> that can have 500-650 people and fit. >> >> Jared Mauch >> >> On Oct 10, 2011, at 1:12 PM, "Frank Bulk" wrote: >> >>> Then the RFP for the meeting needs to be more specific with some >>> basic SLAs >>> that result in a smaller bill if not met. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Randy Bush [mailto:randy at psg.com] >>> Sent: Monday, October 10, 2011 9:44 AM >>> To: Randy Carpenter >>> Cc: North American Network Operators' Group >>> Subject: Re: meeting network >>> >>>> I would think that the contract with the hotel for the conference >>>> would include the specific requirements for the network. Is that >>>> not >>>> the case? >>> >>> underlying problems >>> >>> o no hotel believe that we'll actually be significantly high use. >>> they simply can not conceive of it. ietf, apricot, ... have >>> seen this time and time again >>> >>> o the hotel does not manage the network, so you have two comms >>> hops >>> to anyone who can do anything. and anyway, they are not going >>> to >>> provision more bandwidth >>> >>> but the problems of which i spoke were the meeting network. which >>> we >>> do supposedly control. >>> >>> randy >>> >>> >>> >> >> From mpetach at netflight.com Mon Oct 10 13:29:12 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Oct 2011 11:29:12 -0700 Subject: 2011.10.10 NANOG53 day 1 morning session notes Message-ID: I tried to take my usual notes from the video stream, but the quality of the stream was really bad; it kept pausing for 10 seconds, then jumping ahead on the audio, so there's big gaps that just didn't exist. :( I'm hoping the post-lunch stream will be better behaved. Posting the notes anyway, in case there's people who couldn't even get the choppy stream. Morning session notes are at http://kestrel3.netflight.com/2011.10.10-nanog53-morning-session.txt Matt From jcdill.lists at gmail.com Mon Oct 10 13:36:08 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 10 Oct 2011 11:36:08 -0700 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <4E933B18.8010501@gmail.com> On 10/10/11 7:00 AM, Owen DeLong wrote: > It would be wise for NANOG to approach future venues and specifically discuss these things with the hotel IT departments in question ahead of time so that they have some remote chance of being prepared. I tried this approach many years ago, for a Blogher conference. The hotel's IT people were uncooperative, and incompetent, and they lied both about their network design and their equipment capabilities. I have since learned that this is par for the course. IMHO the only way to solve this problem is with big $$$ penalties in the contract, big enough that the incompetent IT people realize their jobs are on the line and relinquish control so experts can get access and set-up things properly. Also note - the conference or hotel's IT people will always claim they have "done this before with no problems" even when they haven't. jc From nweis at verilan.com Mon Oct 10 13:39:32 2011 From: nweis at verilan.com (Noah Weis) Date: Mon, 10 Oct 2011 14:39:32 -0400 Subject: nanog53 network status In-Reply-To: References: <4E9320B7.7080407@foobar.org> Message-ID: More on network status: We identified a link between 2 switches that was having intermittent physical errors just a bit ago. The offending copper bits have been thrown to the depths of hell. There were several access points in the center of Millenium Hall that were fed via this link and, as such, most likely contributed to some of the issues people were seeing this morning. Should anyone need to speak with any of the network team for any reason at all, we are located in Parlor 1 on the 3rd floor. Cheers, Noah -- Noah K. Weis Verilan, Inc. m: +1-503-902-2491 From charles at knownelement.com Mon Oct 10 15:12:04 2011 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 10 Oct 2011 15:12:04 -0500 Subject: Enterprise WiFi list recommendations? In-Reply-To: <4E930967.3010909@houseofzen.org> References: <4E9308E2.8090301@houseofzen.org> <4E930967.3010909@houseofzen.org> Message-ID: <4E935194.3050007@knownelement.com> On 10/10/2011 10:04 AM, James M Keller wrote: > On 10/10/2011 11:01 AM, James M Keller wrote: >> All, >> >> I'm looking for some mailing list recommendations for wifi operations >> community, any commendations? Checkout wispa.org Let us know what you decide to subscribe to. From jmenerick at netsuite.com Mon Oct 10 15:13:49 2011 From: jmenerick at netsuite.com (Menerick, John) Date: Mon, 10 Oct 2011 13:13:49 -0700 Subject: meeting network In-Reply-To: <4E933B18.8010501@gmail.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> , <4E933B18.8010501@gmail.com> Message-ID: <10CD0A2672F6814A988052F37D8D6755064D4A8C27@corpmail2007.corp.netledger.com> "....Also note - the conference or hotel's IT people will always claim they have "done this before with no problems" even when they haven't....." Sounds like a true sales person :) - John Menerick ________________________________________ From: JC Dill [jcdill.lists at gmail.com] Sent: Monday, October 10, 2011 11:36 AM Cc: North American Network Operators' Group Subject: Re: meeting network On 10/10/11 7:00 AM, Owen DeLong wrote: > It would be wise for NANOG to approach future venues and specifically discuss these things with the hotel IT departments in question ahead of time so that they have some remote chance of being prepared. I tried this approach many years ago, for a Blogher conference. The hotel's IT people were uncooperative, and incompetent, and they lied both about their network design and their equipment capabilities. I have since learned that this is par for the course. IMHO the only way to solve this problem is with big $$$ penalties in the contract, big enough that the incompetent IT people realize their jobs are on the line and relinquish control so experts can get access and set-up things properly. Also note - the conference or hotel's IT people will always claim they have "done this before with no problems" even when they haven't. jc NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service. From network.ipdog at gmail.com Mon Oct 10 15:21:41 2011 From: network.ipdog at gmail.com (Network IP Dog) Date: Mon, 10 Oct 2011 13:21:41 -0700 Subject: Enterprise Wi-Fi list recommendations? In-Reply-To: <4E935194.3050007@knownelement.com> References: <4E9308E2.8090301@houseofzen.org> <4E930967.3010909@houseofzen.org> <4E935194.3050007@knownelement.com> Message-ID: <4e9353d6.013e440a.6b73.fffff2a8@mx.google.com> MERAKI... http://www.meraki.com E = 4:32 & Cheers!!! -----Original Message----- From: Charles N Wyble [mailto:charles at knownelement.com] Sent: Monday, October 10, 2011 1:12 PM To: nanog at nanog.org Subject: Re: Enterprise WiFi list recommendations? On 10/10/2011 10:04 AM, James M Keller wrote: > On 10/10/2011 11:01 AM, James M Keller wrote: >> All, >> >> I'm looking for some mailing list recommendations for wifi operations >> community, any commendations? Checkout wispa.org Let us know what you decide to subscribe to. From betty at newnog.org Mon Oct 10 15:33:26 2011 From: betty at newnog.org (Betty Burke) Date: Mon, 10 Oct 2011 16:33:26 -0400 Subject: [NANOG-announce] NANOG 53 Survey Message-ID: Hi Everyone: Again, for those who are viewing or attending, welcome to NANOG 53. The in person attendance and the NANOG Program continue to be simply outstanding! I encourage everyone to take note of the new NANOG Survey tool. You will find a Survey links on the agenda page for many of the presentations and breaks. Your feed-back in important to the NANOG Program Committee, as well as the operational staff of NANOG. Also, please visit http://www.nanog.org/ibin/c5i?mid=8&rid=49&gid=0&k1=459, also noted on the NANOG 53 meeting page, the General Meeting Survey with an additional NOGLab Survey. We have Sponsors who have once again provided an incentive gift. Please visit the General Meeting and NOGLab surveys, share your opinions, and as a reward are eligible for the survey drawing. Gifts will be awarded on Tuesday and Wednesday mornings! If you have any questions or concerns with the process, please send them to nanog-support at nanog.org. All very best! Betty -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 Direct (510) 492-4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From mpetach at netflight.com Mon Oct 10 16:03:37 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Oct 2011 14:03:37 -0700 Subject: 2011.10.10 NANOG53 Monday afternoon session notes Message-ID: Many thanks to whomever fixed the stream; post lunchtime, things worked much, much better!!! I jotted down some notes from the afternoon sessions, before the video stream was shut off for the day; notes are posted at http://kestrel3.netflight.com/2011.10.10-nanog53-afternoon-session.txt Have fun at the socials tonight! Matt From steve at pirk.com Mon Oct 10 16:12:40 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Mon, 10 Oct 2011 14:12:40 -0700 Subject: Y'all know Google is offering public DNS services now? Message-ID: I saw this in a post from Travis Wise of Google yesterday. Pretty cool for those users who do not want to use their ISP's name servers, or just want to have dns resolve quickly from anywhere in the world. In either case, I think it is cool ;-] http://code.google.com/speed/public-dns/ Here is the original post - Yes, this one is public... oops! https://plus.google.com/111937447827665620879/posts/27S6QB8j1Ry Nice easy numbers to remember too. 8.8.8.8 and 8.8.4.4 -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From nweis at verilan.com Mon Oct 10 16:43:12 2011 From: nweis at verilan.com (Noah Weis) Date: Mon, 10 Oct 2011 17:43:12 -0400 Subject: new guest room SSID for NANOG Message-ID: All, The hotel is in the process of deploying an SSID throughout the guest room network that terminates to the NANOG external router, rather than the hotel's gateway. The SSID is NANOG-guest. They stated it will take a couple of hours to be fully operational in the guest room space. As always, please let me know if you have any questions. Cheers, Noah -- Noah K. Weis Verilan, Inc. m: +1-503-902-2491 From tom at ninjabadger.net Mon Oct 10 16:44:47 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 10 Oct 2011 22:44:47 +0100 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: Message-ID: <1318283087.4049.1.camel@teh-desktop> On Mon, 2011-10-10 at 14:12 -0700, steve pirk [egrep] wrote: > I saw this in a post from Travis Wise of Google yesterday. Pretty cool > for > those users who do not want to use their ISP's name servers, or just > want to > have dns resolve quickly from anywhere in the world. In either case, I > think > it is cool ;-] > > http://code.google.com/speed/public-dns/ Welcome to 2 years ago[1]... Y'all. :-/ [1] http://www.wired.com/threatlevel/2009/12/geez-google-wants-to-take-over-dns-too/ From scott at doc.net.au Mon Oct 10 16:45:28 2011 From: scott at doc.net.au (Scott Howard) Date: Mon, 10 Oct 2011 14:45:28 -0700 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: Message-ID: This service has been discussed several times in the ~2 years since it was first released (including topics such as why it's bad for CDNs) The archives would be a good place to start... Scott. On Mon, Oct 10, 2011 at 2:12 PM, steve pirk [egrep] wrote: > I saw this in a post from Travis Wise of Google yesterday. Pretty cool for > those users who do not want to use their ISP's name servers, or just want > to > have dns resolve quickly from anywhere in the world. In either case, I > think > it is cool ;-] > > http://code.google.com/speed/public-dns/ > > Here is the original post - Yes, this one is public... oops! > https://plus.google.com/111937447827665620879/posts/27S6QB8j1Ry > > Nice easy numbers to remember too. 8.8.8.8 and 8.8.4.4 > > -- > steve pirk > yensid > "father... the sleeper has awakened..." paul atreides - dune > kexp.org member august '09 > From toddunder at gmail.com Mon Oct 10 16:47:33 2011 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 10 Oct 2011 17:47:33 -0400 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: Message-ID: not bad for CDNs anymore: http://arstechnica.com/telecom/news/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup.ars t On Mon, Oct 10, 2011 at 5:45 PM, Scott Howard wrote: > This service has been discussed several times in the ~2 years since it was > first released (including topics such as why it's bad for CDNs) > > The archives would be a good place to start... > > ?Scott. > > > > On Mon, Oct 10, 2011 at 2:12 PM, steve pirk [egrep] wrote: > >> I saw this in a post from Travis Wise of Google yesterday. Pretty cool for >> those users who do not want to use their ISP's name servers, or just want >> to >> have dns resolve quickly from anywhere in the world. In either case, I >> think >> it is cool ;-] >> >> http://code.google.com/speed/public-dns/ >> >> Here is the original post - Yes, this one is public... oops! >> https://plus.google.com/111937447827665620879/posts/27S6QB8j1Ry >> >> Nice easy numbers to remember too. 8.8.8.8 and 8.8.4.4 >> >> -- >> steve pirk >> yensid >> "father... the sleeper has awakened..." paul atreides - dune >> kexp.org member august '09 >> > From tvhawaii at shaka.com Mon Oct 10 17:10:48 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 10 Oct 2011 12:10:48 -1000 Subject: Y'all know Google is offering public DNS services now? References: Message-ID: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Todd Underwood wrote: > not bad for CDNs anymore: > > http://arstechnica.com/telecom/news/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup.ars > > t Fwiw, ol' Steve Gibson has written a small (167KB), .exe, "DNS Benchmark". It's easy to add 8.8.8.8 and 8.8.8.4 (or any nameserver) to the .ini file from within the program . http://www.grc.com/dns/benchmark.htm --Michael From morrowc.lists at gmail.com Mon Oct 10 17:16:26 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Oct 2011 18:16:26 -0400 Subject: new guest room SSID for NANOG In-Reply-To: References: Message-ID: On Mon, Oct 10, 2011 at 5:43 PM, Noah Weis wrote: > All, > > The hotel is in the process of deploying an SSID throughout the guest room > network that terminates to the NANOG external router, rather than the > hotel's gateway. > > The SSID is NANOG-guest. > > They stated it will take a couple of hours to be fully operational in the > guest room space. Thanks! From frnkblk at iname.com Mon Oct 10 17:41:38 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 10 Oct 2011 17:41:38 -0500 Subject: meeting network In-Reply-To: <4E933B18.8010501@gmail.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> Message-ID: <002b01cc879d$c5f2f130$51d8d390$@iname.com> Holding the last 10% of the meeting room payment seems like a good start for any venue. But as others have indicated, the market may be too small for free-market principles to be fully effective. Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Monday, October 10, 2011 1:36 PM Cc: North American Network Operators' Group Subject: Re: meeting network On 10/10/11 7:00 AM, Owen DeLong wrote: > It would be wise for NANOG to approach future venues and specifically discuss these things with the hotel IT departments in question ahead of time so that they have some remote chance of being prepared. I tried this approach many years ago, for a Blogher conference. The hotel's IT people were uncooperative, and incompetent, and they lied both about their network design and their equipment capabilities. I have since learned that this is par for the course. IMHO the only way to solve this problem is with big $$$ penalties in the contract, big enough that the incompetent IT people realize their jobs are on the line and relinquish control so experts can get access and set-up things properly. Also note - the conference or hotel's IT people will always claim they have "done this before with no problems" even when they haven't. jc From tom+nanog at oneshoeco.com Mon Oct 10 17:42:14 2011 From: tom+nanog at oneshoeco.com (Tom Lanyon) Date: Tue, 11 Oct 2011 09:12:14 +1030 Subject: SP / Enterprise design (dis)similarities Message-ID: Hi all, Looking for some advice or experience in a small enterprise / hosting provider context. There's plenty of BCP information around for SPs in the network design realm, and I'm curious how much of this applies to enterprises too. Commonly advised items like: * pull-up statics created on core devices, not network border devices * using iBGP to carry customer prefixes, not an IGP * announcing defaults over iBGP or IGP In some cases I imagine it may be simpler to have all BGP finish at the network border devices and not have to worry about running both IGP and iBGP sessions inwards to the core and/or aggregation devices. I understand the limitations of putting our Internet prefixes in an IGP, but for a hosting provider style network where everything is ethernet connected and within data centres there's much less route flapping to deal with (there's no bouncing DSL lines, for example). In the case that there is both iBGP and IGP running internally, is there any reason to choose one or the other to originate a default route to our aggregation/access layers? At some point I imagine it's going to be redistributed into the IGP (or re-originated in the IGP), so would think it would be best to just always run the default in the IGP to keep things consistent. Finally - are there any reasons to avoid running next-hop-self on ibgp sessions? The upside is we get to avoid distributing all of our transit/peer upstream point to point links into the rest of the network. Again, I understand this may be undesirable from a SP perspective, but when our 'clients' are all a bunch of internal servers it makes sense to keep iBGP/IGP as clean as possible... Thanks, Tom From alex at corp.nac.net Mon Oct 10 17:44:50 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Mon, 10 Oct 2011 18:44:50 -0400 Subject: meeting network In-Reply-To: <002b01cc879d$c5f2f130$51d8d390$@iname.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB808D15B1708@EXCHMBX.hq.nac.net> Years ago, on my own, when I used to attend, I used to call the venue about a month in advance and explain to them what was about to happen. Sort of a warning, per say. I explained, in detail, who NANOG was comprised of (I often would use the term "operators of the internet"). I explained even if they think they have seen this before, they haven't. Some listened. Some didn't. This would be something I would be willing to volunteer my time with - discussions with, and negotiations with, venues. It's all in the approach. > Holding the last 10% of the meeting room payment seems like a good > start for any venue. > > But as others have indicated, the market may be too small for free- > market principles to be fully effective. > > > I tried this approach many years ago, for a Blogher conference. The > hotel's IT people were uncooperative, and incompetent, and they lied > both about their network design and their equipment capabilities. I > have since learned that this is par for the course. IMHO the only way > to solve this problem is with big $$$ penalties in the contract, big > enough that the incompetent IT people realize their jobs are on the > line > and relinquish control so experts can get access and set-up things > properly. > > Also note - the conference or hotel's IT people will always claim they > have "done this before with no problems" even when they haven't. > > jc From jcurran at istaff.org Mon Oct 10 18:09:01 2011 From: jcurran at istaff.org (John Curran) Date: Mon, 10 Oct 2011 19:09:01 -0400 Subject: new guest room SSID for NANOG In-Reply-To: References: Message-ID: Noah - Very nice... I also notice it's IPv6 enabled. :-) Thanks! /John On Oct 10, 2011, at 5:43 PM, Noah Weis wrote: > All, > > The hotel is in the process of deploying an SSID throughout the guest room > network that terminates to the NANOG external router, rather than the > hotel's gateway. > > The SSID is NANOG-guest. > > They stated it will take a couple of hours to be fully operational in the > guest room space. > > As always, please let me know if you have any questions. > > Cheers, > > Noah > > -- > > Noah K. Weis > Verilan, Inc. > m: +1-503-902-2491 From ethan at cs.washington.edu Mon Oct 10 18:48:29 2011 From: ethan at cs.washington.edu (Ethan Katz-Bassett) Date: Mon, 10 Oct 2011 16:48:29 -0700 Subject: Announcement of University of Washington routing study In-Reply-To: References: Message-ID: Hi NANOG, We finished the original study. Since we have been getting some interesting results and nobody has raised any issues, I'd like to continue it for the time being. We will be limiting our announcements to 184.164.240.0/20 (and its sub-prefixes, though generally only up to 184.164.248.0/23), though other researchers may be using other parts of the /19. Please feel free to contact me directly with any questions. Cheers, Ethan Katz-Bassett http://www.cs.washington.edu/homes/ethan/ University of Washington On Thu, Aug 18, 2011 at 4:32 PM, Ethan Katz-Bassett wrote: > > > Hi NANOG, > > > From August 24 to October 4, the University of Washington and Georgia Tech > will conduct an Internet routing study using AS-PATH poisoning. The study > will *only* affect the Georgia Tech experimental prefix 184.164.224.0/19(and its sub-prefixes). The prefix serves *no active users/services* so the > study should not affect any production prefixes or users. We plan to insert > AS numbers into our announcements to route around some networks. We will > always start AS-PATHs with our own ASN 47065. We will limit ourselves to at > most 10 announcement changes per hour (and generally will change the > announcement for a given sub-prefix at most every 90 minutes). > > > This experiment is almost identical to one that Georgia Tech conducted in > June and July without problems or complaints > (http://mailman.nanog.org/pipermail/nanog/2011-June/037527.html), so we do > not anticipate any issues. Others have done similar studies in the past > (e.g., Randy Bush et al.: > http://www.psg.com/~olaf/measurements/as3130/visibility.pdf). > If, for any reason, you want us not to include your ASN in announcements for > our prefix, please opt-out at any time before August 24 at: > http://www.surveymonkey.com/s/9P2TD7T . A few ASes opted out of the > previous Georgia Tech study, and we will continue to honor those opt-outs. > > > Please feel free to contact me directly with any questions. > > > Cheers, > > Ethan Katz-Bassett > > http://www.cs.washington.edu/homes/ethan/ > > University of Washington > From rcarpen at network1.net Mon Oct 10 19:12:57 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Oct 2011 20:12:57 -0400 (EDT) Subject: new guest room SSID for NANOG In-Reply-To: Message-ID: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> Very nice. I wonder if this is an option we could try to use in future meetings. It makes sense, really, since we already have decent connectivity for the conference areas, and we wouldn't be destroying the hotel's outside connection (only their WiFi ;-) ) -Randy ----- Original Message ----- > Noah - > > Very nice... I also notice it's IPv6 enabled. :-) > > Thanks! > /John > > On Oct 10, 2011, at 5:43 PM, Noah Weis wrote: > > > All, > > > > The hotel is in the process of deploying an SSID throughout the > > guest room > > network that terminates to the NANOG external router, rather than > > the > > hotel's gateway. > > > > The SSID is NANOG-guest. > > > > They stated it will take a couple of hours to be fully operational > > in the > > guest room space. > > > > As always, please let me know if you have any questions. > > > > Cheers, > > > > Noah > > > > -- > > > > Noah K. Weis > > Verilan, Inc. > > m: +1-503-902-2491 > > > > From jcurran at istaff.org Mon Oct 10 19:38:16 2011 From: jcurran at istaff.org (John Curran) Date: Mon, 10 Oct 2011 20:38:16 -0400 Subject: new guest room SSID for NANOG In-Reply-To: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> References: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> Message-ID: <4F5CBCEE-28C7-48DA-94A6-9C5E962B594C@istaff.org> On Oct 10, 2011, at 8:12 PM, Randy Carpenter wrote: > Very nice. I wonder if this is an option we could try to use in future meetings. It makes sense, really, since we already have decent connectivity for the conference areas, and we wouldn't be destroying the hotel's outside connection (only their WiFi ;-) ) With enough leverage in the contracting process, you may be able to get them to agree to allow such (particularly since it can be next to impossible to get a configuration clueful person involved early in the process...) Whether they can actually deliver (i.e. do they have any control over their own wireless network, any onsite staff that actually knows networking, etc.) plus the potential liability that results from changing that configuration is entirely another matter. Nearly every hotel you contract with for the first time results in a different scenario, but I agree it is worth keeping in mind for the hotels that have competent on-site access since diverting the hotel room traffic for conference attendees improves performance for everyone. /John From bmanning at vacation.karoshi.com Mon Oct 10 19:50:44 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 11 Oct 2011 00:50:44 +0000 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> Message-ID: <20111011005044.GC4867@vacation.karoshi.com.> back in the day, abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ.ca.us. existed to test the length of DNS label. circa 1992 ^b.com also existed (yes, we considered ^p) the heady days of DNS evolution! /bill On Fri, Oct 07, 2011 at 06:16:46PM -0700, Owen DeLong wrote: > NSI was never the only registrar. They were just the only registrar > for COM, ORG, NET, EDU, and possibly a few other TLDs, but, > they were, for example, never the registrar for US or many other > CCTLDs. > > Therefore, it was not internet wide, though I will admit that it did > cover most of the widely known gTLDs. > > Owen > > On Oct 7, 2011, at 4:45 PM, steve pirk [egrep] wrote: > > > It turns out it was an artificial limitation on Network Solution's part. > > Being the only registrar at the time, it was pretty much internet wide at > > that point, contrary to the RFC spec. > > > > What was so funny was that someone got Internic/Network Solutions to up the > > limit. Apparently just to save some money on reprinting movie posters... ok, > > so they would have had to change some trailers... > > ;-] > > > > On Fri, Oct 7, 2011 at 16:39, Jimmy Hess wrote: > > > >> On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin wrote: > >>> I remember tales from when there was an eight character limit. But that > >> was > >>> back when you didn't have to pay for them and they assigned you a class-c > >>> block automatically. Of course it took six weeks to register because > >> there > >>> was only one person running the registry. > >> > >> You may be referring to a limitation of a certain OS regarding a > >> hostname; or some network's policy. > >> But the DNS protocol itself never had a limit of 8 characters. > >> When we are talking about the contents of "A" record names, > >> > >> I would refer you to > >> http://www.rfc-editor.org/rfc/rfc2181.txt > >> "RFC 2181 > >> Clarifications to the DNS Specification R. Elz, R. Bush > >> [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) > >> (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) > >> (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " > >> > >> " > >> Elz & Bush Standards Track [Page 12] > >> ... > >> Occasionally it is assumed that the Domain Name System serves only > >> the purpose of mapping Internet host names to data, and mapping > >> Internet addresses to host names. This is not correct, the DNS is a > >> general (if somewhat limited) hierarchical database, and can store > >> almost any kind of data, for almost any purpose. > >> ... > >> 11. Name syntax > >> " > >> The length of any one label is limited to between 1 and 63 octets. A > >> full domain > >> name is limited to 255 octets (including the separators). The zero > >> length full name is defined as representing the root of the DNS tree, > >> and is typically written and displayed as ".". Those restrictions > >> aside, any binary string whatever can be used as the label of any > >> resource record. > >> " > >> > >> -- > >> -JH > >> > > > > > > > > -- > > steve pirk > > refiamerica.org > > "father... the sleeper has awakened..." paul atreides - dune > > kexp.org member august '09 > From randy at psg.com Mon Oct 10 20:00:39 2011 From: randy at psg.com (Randy Bush) Date: Mon, 10 Oct 2011 21:00:39 -0400 Subject: new guest room SSID for NANOG In-Reply-To: References: Message-ID: great idea. next, it would be nice to be able to get a dhcp address from it randy From llynch at civil-tongue.net Mon Oct 10 20:01:17 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Mon, 10 Oct 2011 18:01:17 -0700 (PDT) Subject: new guest room SSID for NANOG Message-ID: On Mon, 10 Oct 2011, John Curran wrote: > On Oct 10, 2011, at 8:12 PM, Randy Carpenter wrote: > >> Very nice. I wonder if this is an option we could try to use in future >> meetings. It makes sense, really, since we already have decent connectivity >> for the conference areas, and we wouldn't be destroying the hotel's outside >> connection (only their WiFi ;-) ) > > > With enough leverage in the contracting process, you may be able to > get them to agree to allow such (particularly since it can be next > to impossible to get a configuration clueful person involved early > in the process...) > > Whether they can actually deliver (i.e. do they have any control > over their own wireless network, any onsite staff that actually > knows networking, etc.) plus the potential liability that results > from changing that configuration is entirely another matter. > > Nearly every hotel you contract with for the first time results in > a different scenario, but I agree it is worth keeping in mind for > the hotels that have competent on-site access since diverting the > hotel room traffic for conference attendees improves performance > for everyone. There was a reason the IETF kept going back to Minneapolis for meetings and it wasn't just the wild rice porridge at Hell's Kitchen. The Hilton there was extremely geek friendly and allowed us to take over both show floor and room networks. Great venue for network... - Lucy > /John > > From jra at baylink.com Mon Oct 10 20:22:55 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Oct 2011 21:22:55 -0400 (EDT) Subject: meeting network In-Reply-To: Message-ID: <23663436.4602.1318296175314.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > As to the hotel room wifi... apparently when you have 490 rooms in the > hotel (full) and only provision your internal NAT space as a /23 ... > things work 'fine' most days. When a networking conference comes to > visit with 3+ devices requiring IP in each room... the whole hotel > network stops :( Last night the display systems in the lobby and the > hotel registration machines were all broken :( The hotel's network > people (in NYC) are supposedly 'on a fix', who knows... (is expanding > the nat subnet THAT hard?) So who comes to a conference like this without a crossband router running WRT in repeater mode, with 11a on the back side? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Oct 10 20:24:53 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Oct 2011 21:24:53 -0400 (EDT) Subject: meeting network In-Reply-To: Message-ID: <9312265.4604.1318296293210.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > It would be wise for NANOG to approach future venues and specifically > discuss these things with the hotel IT departments in question ahead > of time so that they have some remote chance of being prepared. It is nearly never "the hotel's IT department", in any sizable property; they've generally farmed it out to someone who Does That, and they often haven't even any Bog Red Switches to push when things break. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From steve at pirk.com Mon Oct 10 20:27:35 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Mon, 10 Oct 2011 18:27:35 -0700 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Message-ID: Wow, consider me educated on old news. LOL I imagine it is new to many of the users on the new service they launched. I completely forgot that Nanog would probably be the first to comment and chime in when it first became available. Thanks for the information. I will definitely research the CDN issues. Back to school steve...Why did I Awesome link Todd - Why did I think that the resolving server would already know "where network path wise" the request came from. Let me post this as a comment and ask how the CDN endpoint routing is working. Better yet, change the dns on my router, and Netflix on the Google TV should let me know how well it is streaming. --steve On Mon, Oct 10, 2011 at 15:10, Michael Painter wrote: > Todd Underwood wrote: > >> not bad for CDNs anymore: >> >> http://arstechnica.com/**telecom/news/2011/08/opendns-** >> and-google-working-with-cdns-**on-dns-speedup.ars >> >> t >> > > Fwiw, ol' Steve Gibson has written a small (167KB), .exe, "DNS Benchmark". > It's easy to add 8.8.8.8 and 8.8.8.4 (or any nameserver) to the .ini file > from within the program . > http://www.grc.com/dns/**benchmark.htm > --Michael > > > -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 - Google+ pirk.com From jra at baylink.com Mon Oct 10 20:31:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Oct 2011 21:31:31 -0400 (EDT) Subject: nanog53 network status In-Reply-To: Message-ID: <17322961.4606.1318296691199.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Noah Weis" > We identified a link between 2 switches that was having intermittent > physical errors just a bit ago. The offending copper bits have been thrown > to the depths of hell. There were several access points in the center of > Millenium Hall that were fed via this link and, as such, most likely > contributed to some of the issues people were seeing this morning. Suggestion: you (and everyone else who's ever in your position at a Large Networking Conference) should *run a netops blog, and make sure it's well publicized in the week leading up to the conference -- and at registration*. Or, even, run a Twitter account to which people can subscribe from their cellphones via SMS, on which you announce problems and fixes. Communications, *way* ahead of the curve, ameliorates the impact of this sort of problems remarkably. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jco at direwolf.com Mon Oct 10 21:21:32 2011 From: jco at direwolf.com (John Orthoefer) Date: Mon, 10 Oct 2011 22:21:32 -0400 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: <1318283087.4049.1.camel@teh-desktop> References: <1318283087.4049.1.camel@teh-desktop> Message-ID: <329D8A77-CE98-438D-BD89-B3B20112FE88@direwolf.com> I see those guys at BBNPlanet is trying to compete with them using 4.2.2.1, .2, and .3. johno On Oct 10, 2011, at 5:44 PM, Tom Hill wrote: > On Mon, 2011-10-10 at 14:12 -0700, steve pirk [egrep] wrote: >> I saw this in a post from Travis Wise of Google yesterday. Pretty cool >> for >> those users who do not want to use their ISP's name servers, or just >> want to >> have dns resolve quickly from anywhere in the world. In either case, I >> think >> it is cool ;-] >> >> http://code.google.com/speed/public-dns/ > > Welcome to 2 years ago[1]... Y'all. > > :-/ > > [1] http://www.wired.com/threatlevel/2009/12/geez-google-wants-to-take-over-dns-too/ > > From jra at baylink.com Mon Oct 10 21:28:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Oct 2011 22:28:39 -0400 (EDT) Subject: Fwd: [Wikitech-l] WMF Staff Announcement - Welcome Leslie Carr! In-Reply-To: Message-ID: <3397509.4620.1318300119936.JavaMail.root@benjamin.baylink.com> I thought you guys might be vaguely amused by this reply on the Wikimedia tech mailing list to the announcement of Leslie Carr's move to the organization from Twitter: ----- Forwarded Message ----- > From: "Ashar Voultoiz" > To: wikitech-l at lists.wikimedia.org > Sent: Monday, October 10, 2011 2:19:19 PM > Subject: Re: [Wikitech-l] WMF Staff Announcement - Welcome Leslie Carr! > On 10/10/11 18:52, CT Woo wrote: > > Technical Operations department is pleased to announce another new fabulous > > staff member to its team. Please join us to welcome Leslie Carr, our > > Network Operations Engineer, starting today, 10/10/11. She is based > > in San Francisco office. > > leslie at life# configure exclusive > delete bgp group Employer peer-as 13414 > set bgp group Employer peer-as 14907 > leslie at life# commit > > Welcome! > > -- > Ashar Voultoiz Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Oct 10 21:35:17 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Oct 2011 22:35:17 -0400 (EDT) Subject: Y'all know Google is offering public DNS services now? In-Reply-To: <329D8A77-CE98-438D-BD89-B3B20112FE88@direwolf.com> Message-ID: <5143459.4622.1318300517693.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Orthoefer" > I see those guys at BBNPlanet is trying to compete with them using > 4.2.2.1, .2, and .3. C'mon, John; no trolling. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From lists at beatmixed.com Mon Oct 10 22:14:37 2011 From: lists at beatmixed.com (Matt Hite) Date: Mon, 10 Oct 2011 20:14:37 -0700 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: On Mon, Oct 10, 2011 at 3:42 PM, Tom Lanyon wrote: > Finally - are there any reasons to avoid running next-hop-self on ibgp sessions? ?The upside is we get to avoid distributing all of our transit/peer upstream point to point links into the rest of the network. ?Again, I understand this may be undesirable from a SP perspective, but when our 'clients' are all a bunch of internal servers it makes sense to keep iBGP/IGP as clean as possible... Route reflectors in the mix? Next-hop-self not so useful there... -M From owen at delong.com Mon Oct 10 22:33:28 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Oct 2011 20:33:28 -0700 Subject: new guest room SSID for NANOG In-Reply-To: References: Message-ID: On Oct 10, 2011, at 3:16 PM, Christopher Morrow wrote: > On Mon, Oct 10, 2011 at 5:43 PM, Noah Weis wrote: >> All, >> >> The hotel is in the process of deploying an SSID throughout the guest room >> network that terminates to the NANOG external router, rather than the >> hotel's gateway. >> >> The SSID is NANOG-guest. >> >> They stated it will take a couple of hours to be fully operational in the >> guest room space. > > Thanks! Yay!! IPv6 in my room! WOOT! Owen From owen at delong.com Mon Oct 10 22:36:37 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Oct 2011 20:36:37 -0700 Subject: meeting network In-Reply-To: <002b01cc879d$c5f2f130$51d8d390$@iname.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> Message-ID: <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> I don't think it is. I think that you can negotiate and I will point out that the hotel here has wanted our business enough that they have now scrambled to make life significantly better. You can also bet I'll be demanding that they credit my $54 that I put on the in-room access be credited to my bill even though ARIN would pay it. I routinely do this when the conference network (or the in-room network) sucks and it's provided by the hotel. I have yet to have one refuse my refund request. Owen On Oct 10, 2011, at 3:41 PM, Frank Bulk wrote: > Holding the last 10% of the meeting room payment seems like a good start for > any venue. > > But as others have indicated, the market may be too small for free-market > principles to be fully effective. > > Frank > > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Monday, October 10, 2011 1:36 PM > Cc: North American Network Operators' Group > Subject: Re: meeting network > > On 10/10/11 7:00 AM, Owen DeLong wrote: >> It would be wise for NANOG to approach future venues and specifically > discuss these things with the hotel IT departments in question ahead of time > so that they have some remote chance of being prepared. > > I tried this approach many years ago, for a Blogher conference. The > hotel's IT people were uncooperative, and incompetent, and they lied > both about their network design and their equipment capabilities. I > have since learned that this is par for the course. IMHO the only way > to solve this problem is with big $$$ penalties in the contract, big > enough that the incompetent IT people realize their jobs are on the line > and relinquish control so experts can get access and set-up things properly. > > Also note - the conference or hotel's IT people will always claim they > have "done this before with no problems" even when they haven't. > > jc > > > > > > From morrowc.lists at gmail.com Mon Oct 10 23:25:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Oct 2011 00:25:34 -0400 Subject: meeting network In-Reply-To: <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> Message-ID: On Mon, Oct 10, 2011 at 11:36 PM, Owen DeLong wrote: > I don't think it is. I think that you can negotiate and I will point out that the hotel > here has wanted our business enough that they have now scrambled to make > life significantly better. You can also bet I'll be demanding that they credit my > $54 that I put on the in-room access be credited to my bill even though ARIN would > pay it. > I think the in-room wireless is actually supposed to already be creditted back at exit... From joelja at bogus.com Mon Oct 10 23:44:59 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 10 Oct 2011 21:44:59 -0700 Subject: new guest room SSID for NANOG In-Reply-To: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> References: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> Message-ID: <4E93C9CB.2080705@bogus.com> On 10/10/11 17:12 , Randy Carpenter wrote: > > Very nice. I wonder if this is an option we could try to use in > future meetings. It makes sense, really, since we already have decent > connectivity for the conference areas, and we wouldn't be destroying > the hotel's outside connection (only their WiFi ;-) ) having negotiated or attempted to negotiate this as part of a number of hotel contracts, I'd note that while nice to have this is not always possible, so while I'd put it on the list, if it becomes a deal-breaker it would substantially reduce the number of available venues or result in payment of significant considerations to the hotel for the lost revenue from non-nanog guests to the hotel, for whom internet is generally an upsell unless included in their rate. > > -Randy > > > ----- Original Message ----- >> Noah - >> >> Very nice... I also notice it's IPv6 enabled. :-) >> >> Thanks! /John >> >> On Oct 10, 2011, at 5:43 PM, Noah Weis wrote: >> >>> All, >>> >>> The hotel is in the process of deploying an SSID throughout the >>> guest room network that terminates to the NANOG external router, >>> rather than the hotel's gateway. >>> >>> The SSID is NANOG-guest. >>> >>> They stated it will take a couple of hours to be fully >>> operational in the guest room space. >>> >>> As always, please let me know if you have any questions. >>> >>> Cheers, >>> >>> Noah >>> >>> -- >>> >>> Noah K. Weis Verilan, Inc. m: +1-503-902-2491 >> >> >> >> > From joelja at bogus.com Tue Oct 11 00:09:34 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 10 Oct 2011 22:09:34 -0700 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> Message-ID: <4E93CF8E.3010804@bogus.com> On 10/10/11 21:25 , Christopher Morrow wrote: > On Mon, Oct 10, 2011 at 11:36 PM, Owen DeLong wrote: >> I don't think it is. I think that you can negotiate and I will point out that the hotel >> here has wanted our business enough that they have now scrambled to make >> life significantly better. You can also bet I'll be demanding that they credit my >> $54 that I put on the in-room access be credited to my bill even though ARIN would >> pay it. >> > > I think the in-room wireless is actually supposed to already be > creditted back at exit... nanog generally in the past attempted to negotiate it as part of the room block. that does not apply however to the other hotel guests. who are just as hosed when the nomadix blows up. From keegan.holley at sungard.com Tue Oct 11 00:12:13 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 11 Oct 2011 01:12:13 -0400 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: 2011/10/10 Tom Lanyon > Hi all, > > Looking for some advice or experience in a small enterprise / hosting > provider context. > > There's plenty of BCP information around for SPs in the network design > realm, and I'm curious how much of this applies to enterprises too. > Commonly advised items like: > * pull-up statics created on core devices, not network border > devices > * using iBGP to carry customer prefixes, not an IGP > * announcing defaults over iBGP or IGP > > It depends on the size of the enterprise as well as the service provider. > In some cases I imagine it may be simpler to have all BGP finish at the > network border devices and not have to worry about running both IGP and iBGP > sessions inwards to the core and/or aggregation devices. In alot of cases iBGP is easier than an IGP if you have a large number of routes or a large number of routers. In others it's easier to accept only a default from the SP and maybe a local table. This is highly subjective as well. > I understand the limitations of putting our Internet prefixes in an IGP, > but for a hosting provider style network where everything is ethernet > connected and within data centres there's much less route flapping to deal > with (there's no bouncing DSL lines, for example). > This depends as well. There are pleanty of hosting customers that want a full or partial table which means you'll have to run BGP. There are all sorts of other limitations with and IGP as well. > > In the case that there is both iBGP and IGP running internally, is there > any reason to choose one or the other to originate a default route to our > aggregation/access layers? At some point I imagine it's going to be > redistributed into the IGP (or re-originated in the IGP), so would think it > would be best to just always run the default in the IGP to keep things > consistent. > The more route aggregation the larger the potential for loops. Then again this is subjective as well. In general BGP isn't something to be avoided at all costs even at a small scale. It's much easier to scale a topology that is iBGP based than to try to move to an iBGP setup after it has grow too large for the IGP. > > Finally - are there any reasons to avoid running next-hop-self on ibgp > sessions? I would go the other way and ask if there is any reason to advertise all the next-hop address into the IGP? > The upside is we get to avoid distributing all of our transit/peer upstream > point to point links into the rest of the network. Again, I understand this > may be undesirable from a SP perspective, but when our 'clients' are all a > bunch of internal servers it makes sense to keep iBGP/IGP as clean as > possible... > The definition of clean is also subjective. There are many who would run the IGP only for loopbacks and /30's and force everything into BGP even at small scale. BGP makes it easier to control the routing relationships between companies and pretty much removes the need for redistribution. There are trade-offs though, such as load-balancing. It really depends on your environment though and the preference of your engineering team. In general there isn't really a such thing as SP vs. Enterprise. For example I've know of a large bank with an internal MPLS topology and about 8 public AS's used just to segregate traffic by country of origin. By most definitions this is an enterprise network although a very large one. On the other hand I've seen a service provider who's network consisted of 4 M10i's and a firewall in someone else's colo facility. You have to look at which protocols and services you need to make your network work as well as the ability to scale. That should dictate your design more than an imaginary line between SP and enterprise. > > From morrowc.lists at gmail.com Tue Oct 11 00:17:00 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Oct 2011 01:17:00 -0400 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley wrote: > The definition of clean is also subjective. ?There are many who would run > the IGP only for loopbacks and /30's and force everything into BGP even at > small scale. ?BGP makes it easier to control the routing relationships > between companies and pretty much removes the need for redistribution. > There are trade-offs though, such as load-balancing. just loadbalance toward the next-hop, no? From scott at doc.net.au Tue Oct 11 00:19:40 2011 From: scott at doc.net.au (Scott Howard) Date: Mon, 10 Oct 2011 22:19:40 -0700 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Message-ID: On Mon, Oct 10, 2011 at 6:27 PM, steve pirk [egrep] wrote: > Awesome link Todd - Why did I think that the resolving server would already > know "where network path wise" the request came from. Let me post this as a > comment and ask how the CDN endpoint routing is working. > I would guess, using this - http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00 Note the authors (two from Google), and the initial release date (not actually shown in the that version as far as I can see, but it was around the same time Google announced their public DNS servers). Scott. From keegan.holley at sungard.com Tue Oct 11 00:19:38 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 11 Oct 2011 01:19:38 -0400 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: 2011/10/11 Christopher Morrow > On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley > wrote: > > The definition of clean is also subjective. There are many who would run > > the IGP only for loopbacks and /30's and force everything into BGP even > at > > small scale. BGP makes it easier to control the routing relationships > > between companies and pretty much removes the need for redistribution. > > There are trade-offs though, such as load-balancing. > > just loadbalance toward the next-hop, no? > It depends on the IGP, whether the paths have exactly the same metric and whether or not you need to run MPLS. From joelja at bogus.com Tue Oct 11 00:32:52 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 10 Oct 2011 22:32:52 -0700 Subject: meeting network In-Reply-To: References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> Message-ID: <4E93D504.6050103@bogus.com> On 10/10/11 07:00 , Owen DeLong wrote: > It would be wise for NANOG to approach future venues and specifically > discuss these things with the hotel IT departments in question ahead > of time so that they have some remote chance of being prepared. The hotel IT department is the guy who runs the as400 that gets reservations from corprate, and runs the POS terminals. the room-net is by-in-large run by a third party such as lodgenet. > Owen > > > From morrowc.lists at gmail.com Tue Oct 11 01:02:17 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Oct 2011 02:02:17 -0400 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: On Tue, Oct 11, 2011 at 1:19 AM, Keegan Holley wrote: > > > 2011/10/11 Christopher Morrow >> >> On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley >> wrote: >> > The definition of clean is also subjective. ?There are many who would >> > run >> > the IGP only for loopbacks and /30's and force everything into BGP even >> > at >> > small scale. ?BGP makes it easier to control the routing relationships >> > between companies and pretty much removes the need for redistribution. >> > There are trade-offs though, such as load-balancing. >> >> just loadbalance toward the next-hop, no? > > It depends on the IGP, whether the paths have exactly the same metric and > whether or not you need to run MPLS. sure. From randy at psg.com Tue Oct 11 01:03:01 2011 From: randy at psg.com (Randy Bush) Date: Tue, 11 Oct 2011 02:03:01 -0400 Subject: meeting network In-Reply-To: <4E93D504.6050103@bogus.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> Message-ID: > The hotel IT department is the guy who runs the as400 that gets > reservations from corprate, and runs the POS terminals. > > the room-net is by-in-large run by a third party such as lodgenet. here at the lovely and reasonably priced loews, the dhcp disaster in the rooms killed the front desk randy From morrowc.lists at gmail.com Tue Oct 11 01:04:00 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Oct 2011 02:04:00 -0400 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Message-ID: On Tue, Oct 11, 2011 at 1:19 AM, Scott Howard wrote: > the initial release date (not > actually shown in the that version as far as I can see, but it was around > the same time Google announced their public DNS servers). jan 27 2011, so says the doc header... From michiel at klaver.it Tue Oct 11 01:54:44 2011 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 11 Oct 2011 08:54:44 +0200 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Message-ID: <4E93E834.6070405@klaver.it> At 22-07-2011 20:59, Michael Painter wrote: > Fwiw, ol' Steve Gibson has written a small (167KB), .exe, "DNS Benchmark". > It's easy to add 8.8.8.8 and 8.8.8.4 (or any nameserver) to the .ini file > from within the program . > http://www.grc.com/dns/benchmark.htm > --Michael > There's also namebench, does a lot of more tests, and runs at Mac OSX and Linux too: http://code.google.com/p/namebench/ From achatz at forthnet.gr Tue Oct 11 02:13:08 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Tue, 11 Oct 2011 10:13:08 +0300 Subject: SP / Enterprise design (dis)similarities In-Reply-To: References: Message-ID: <4E93EC84.2040902@forthnet.gr> Tom Lanyon wrote on 11/10/2011 01:42: > > In the case that there is both iBGP and IGP running internally, is there any reason to choose one or the other to originate a default route to our aggregation/access layers? At some point I imagine it's going to be redistributed into the IGP (or re-originated in the IGP), so would think it would be best to just always run the default in the IGP to keep things consistent. > > > > Thanks, > Tom > > > We recently started migrating from "IGP for everything" to "BGP for customers, IGP for infrastructure". We have chosen to go with the default route in IGP, since we consider IGP strictly internal (no redistribution allowed anywhere) and something to be trusted more than BGP. -- Tassos From jcdill.lists at gmail.com Tue Oct 11 03:25:47 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 11 Oct 2011 01:25:47 -0700 Subject: meeting network In-Reply-To: <002b01cc879d$c5f2f130$51d8d390$@iname.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> Message-ID: <4E93FD8B.3080905@gmail.com> On 10/10/11 3:41 PM, Frank Bulk wrote: > Holding the last 10% of the meeting room payment seems like a good start for > any venue. It's worthless. It's like being single-homed on a line with an SLA that refunds some small percent of your service provider fee for extended outages - fat lot of good that does you when your line Goes Down. The hotel's IT department will assure them (and you) that they have the situation covered, and then when it goes down you get a whole whopping 10% discount, but in the meantime you Have No Network. To get their attention, to make sure they are really ready to provision the network capacity correctly (with adequate hardware, software, bandwidth, appropriate configs, etc.) the penalty needs to be something closer to "50% of all fees paid by the organization AND our attendees, for meeting rooms, food service, AND for lodging". Then when the network dies everyone gets 50% refunded. That will get the hotel management's attention and *possibly* help ensure that their IT department really DOES have the situation properly spec'd and provisioned to handle the traffic. jc From tvhawaii at shaka.com Tue Oct 11 03:58:18 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 10 Oct 2011 22:58:18 -1000 Subject: Y'all know Google is offering public DNS services now? References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> <4E93E834.6070405@klaver.it> Message-ID: <4FD28098A6404AF5BCFE44B2EC2FD69D@owner59e1f1502> Michiel Klaver wrote: > At 22-07-2011 20:59, Michael Painter wrote: >> Fwiw, ol' Steve Gibson has written a small (167KB), .exe, "DNS Benchmark". >> It's easy to add 8.8.8.8 and 8.8.8.4 (or any nameserver) to the .ini file >> from within the program . >> http://www.grc.com/dns/benchmark.htm >> --Michael >> > > There's also namebench, does a lot of more tests, and runs at Mac OSX and > Linux too: http://code.google.com/p/namebench/ More tests? Where's the result of the DNSSec checks? Its maintenance is suspect, since my ISP's (and most resolvers) returned something like: a.. www.anonymizer.com appears incorrect: 209.143.153.58 a.. isohunt.com appears incorrect: 208.95.172.130 a.. www.thesouthasian.org appears incorrect: sbsfe.geo.mf0.yahoodns.net a.. youporn.com appears incorrect: 173.192.24.120, 173.192.60.242, 173.192.60.245, 173.192.24.114, 173.192.24.115, 173.192.24.116, 173.192.24.117, 173.192.24.119 a.. www.stopkinderporno.com appears incorrect: 188.72.230.78 a.. wikileaks.org appears incorrect: 88.80.16.63 a.. www.lapsiporno.info appears incorrect: 89.166.50.123 a.. www.paypal.com is hijacked: 173.0.88.34, 173.0.84.2, 173.0.84.34, 173.0.88.2 a.. uddthailand.com appears incorrect: 184.173.208.195 a.. www.stormfront.org appears incorrect: 174.121.229.156 a.. motherless.com appears incorrect: 198.64.4.17, 198.64.4.16 a.. www.partypoker.com appears incorrect: ppdotcom.iivt.com a.. twitter.com appears incorrect: 199.59.149.198, 199.59.149.230, 199.59.148.10 Interesting choice of URLs. I wonder how many folks are wasting their time chasing this ominous sounding a.. www.paypal.com is hijacked: 173.0.88.34, 173.0.84.2, 173.0.84.34, 173.0.88.2 --Michael From michiel at klaver.it Tue Oct 11 04:31:22 2011 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 11 Oct 2011 11:31:22 +0200 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: <4FD28098A6404AF5BCFE44B2EC2FD69D@owner59e1f1502> References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> <4E93E834.6070405@klaver.it> <4FD28098A6404AF5BCFE44B2EC2FD69D@owner59e1f1502> Message-ID: <4E940CEA.8080207@klaver.it> At 11-10-2011 10:58, Michael Painter wrote: > Interesting choice of URLs. > > I wonder how many folks are wasting their time chasing this ominous sounding > a.. www.paypal.com is hijacked: 173.0.88.34, 173.0.84.2, 173.0.84.34, > 173.0.88.2 > > --Michael I guess you selected the Alexa top1000 as data-source, which contains this selection of URLs. The result of mis-matching IP addresses reports could be the result of geo-dns, serving different results to different parts of the world to match local CDN nodes. From owen at delong.com Tue Oct 11 07:19:05 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Oct 2011 05:19:05 -0700 Subject: new guest room SSID for NANOG In-Reply-To: <4E93C9CB.2080705@bogus.com> References: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> <4E93C9CB.2080705@bogus.com> Message-ID: <71B4425B-ABE7-4014-8625-04960031DC21@delong.com> On Oct 10, 2011, at 9:44 PM, Joel jaeggli wrote: > On 10/10/11 17:12 , Randy Carpenter wrote: >> >> Very nice. I wonder if this is an option we could try to use in >> future meetings. It makes sense, really, since we already have decent >> connectivity for the conference areas, and we wouldn't be destroying >> the hotel's outside connection (only their WiFi ;-) ) > > having negotiated or attempted to negotiate this as part of a number of > hotel contracts, I'd note that while nice to have this is not always > possible, so while I'd put it on the list, if it becomes a deal-breaker > it would substantially reduce the number of available venues or result > in payment of significant considerations to the hotel for the lost > revenue from non-nanog guests to the hotel, for whom internet is > generally an upsell unless included in their rate. > Should be pretty easy to convince the hotel that upselling NANOGers internet isn't going to result in revenue unless their network somehow miraculously handles the load. Instead, they can look forward to ~500 people wanting that charge reversed on checkout due to the hotel's inability to provide sufficient capacity. Owen >> >> -Randy >> >> >> ----- Original Message ----- >>> Noah - >>> >>> Very nice... I also notice it's IPv6 enabled. :-) >>> >>> Thanks! /John >>> >>> On Oct 10, 2011, at 5:43 PM, Noah Weis wrote: >>> >>>> All, >>>> >>>> The hotel is in the process of deploying an SSID throughout the >>>> guest room network that terminates to the NANOG external router, >>>> rather than the hotel's gateway. >>>> >>>> The SSID is NANOG-guest. >>>> >>>> They stated it will take a couple of hours to be fully >>>> operational in the guest room space. >>>> >>>> As always, please let me know if you have any questions. >>>> >>>> Cheers, >>>> >>>> Noah >>>> >>>> -- >>>> >>>> Noah K. Weis Verilan, Inc. m: +1-503-902-2491 >>> >>> >>> >>> >> > From owen at delong.com Tue Oct 11 07:22:43 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Oct 2011 05:22:43 -0700 Subject: meeting network In-Reply-To: <4E93D504.6050103@bogus.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> Message-ID: <04331113-3535-4022-BB60-16589EDD3257@delong.com> On Oct 10, 2011, at 10:32 PM, Joel jaeggli wrote: > On 10/10/11 07:00 , Owen DeLong wrote: > >> It would be wise for NANOG to approach future venues and specifically >> discuss these things with the hotel IT departments in question ahead >> of time so that they have some remote chance of being prepared. > > The hotel IT department is the guy who runs the as400 that gets > reservations from corprate, and runs the POS terminals. > > the room-net is by-in-large run by a third party such as lodgenet. > >> Owen >> >> >> In my experience, you start with the hotel IT department and they at least know who to talk to at LodgeNet/whoever in order to reach someone that can provide a useful response. Owen From jcurran at istaff.org Tue Oct 11 08:12:48 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 11 Oct 2011 09:12:48 -0400 Subject: meeting network In-Reply-To: <04331113-3535-4022-BB60-16589EDD3257@delong.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> <04331113-3535-4022-BB60-16589EDD3257@delong.com> Message-ID: <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> On Oct 11, 2011, at 8:22 AM, Owen DeLong wrote: > On Oct 10, 2011, at 10:32 PM, Joel jaeggli wrote: >> On 10/10/11 07:00 , Owen DeLong wrote: >> >>> It would be wise for NANOG to approach future venues and specifically >>> discuss these things with the hotel IT departments in question ahead >>> of time so that they have some remote chance of being prepared. >> >> The hotel IT department is the guy who runs the as400 that gets >> reservations from corprate, and runs the POS terminals. >> >> the room-net is by-in-large run by a third party such as lodgenet. >> > In my experience, you start with the hotel IT department and they at least know who to talk to at LodgeNet/whoever in order to reach someone that can provide a useful response. To be perfectly clear, the hotel IT department is a fine escalation point once you're close the actual event, and that they will bring in others as needed. This even works if you need to pull fiber into a facility for additional bandwidth, with the hotel IT/telecom team often getting involved months in advance. At the time of _contracting_ (more than 1 year in advance in many cases), the ability to pierce the sales veil of "Yes, we can do anything you need" and "It's no problem" can be quite difficult, even if one does an on-site visit and meets with the hotel IT team. They are trained to avoid raising any issues in the sales process, and prioritize any actual technical level engagement with their partners until well past contract. They often do not even have the ability to engage their partners except during an actual performance problem, so expecting them to get someone on the phone a year in advance of an event to commit to an unusual configuration may be quite limited (or even absent in the case of hotel chains whose wireless partner relationship is held by the hotel chain parent corporation.) I'm not saying that it is not worth trying; I just want folks to have a realistic understanding of how these arrangements are actually made. It is far better today then in the past, as there have been many conferences over the years where step 1 was pulling the coax or fiber through the hotel to establish their first-ever network infrastructure... :-) FYI, /John From ryanczak at gmail.com Tue Oct 11 09:01:07 2011 From: ryanczak at gmail.com (Matt Ryanczak) Date: Tue, 11 Oct 2011 10:01:07 -0400 Subject: new guest room SSID for NANOG In-Reply-To: <71B4425B-ABE7-4014-8625-04960031DC21@delong.com> References: <1acba345-0280-4c13-8119-329d8287a7da@zimbra.network1.net> <4E93C9CB.2080705@bogus.com> <71B4425B-ABE7-4014-8625-04960031DC21@delong.com> Message-ID: <4E944C23.4000109@gmail.com> On 10/11/11 8:19 AM, Owen DeLong wrote: > > Should be pretty easy to convince the hotel that upselling NANOGers > internet isn't going to result in revenue unless their network somehow > miraculously handles the load. > > Instead, they can look forward to ~500 people wanting that charge > reversed on checkout due to the hotel's inability to provide sufficient > capacity. As has been said in other parts of this thread NANOG typically negotiates to have in room internet removed from the attendees bill. Also +1 regarding what Joel and John have said regarding the business complexities surrounding making the conference network available in-room or otherwise manipulating the existing network infrastructure of the hotel. Its worth a try but sometimes it is just not practical to do this. From nick at foobar.org Tue Oct 11 09:48:23 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 Oct 2011 15:48:23 +0100 Subject: meeting network In-Reply-To: <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> <04331113-3535-4022-BB60-16589EDD3257@delong.com> <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> Message-ID: <4E945737.6080108@foobar.org> On 11/10/2011 14:12, John Curran wrote: > is far better today then in the past, as there have been many conferences > over the years where step 1 was pulling the coax or fiber through the > hotel to establish their first-ever network infrastructure... :-) There is nothing more dispiriting than "yeah sure, you can pull in that fibre cable, but only on condition that you remove it immediately after the [conference|meeting|whatever] is over. We already have the Internet". Then they point at the 2Mb DSL wifi AP and expect you to be impressed at their technology. Nick From dorn at hetzel.org Tue Oct 11 09:54:47 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Tue, 11 Oct 2011 10:54:47 -0400 Subject: meeting network In-Reply-To: <4E945737.6080108@foobar.org> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> <04331113-3535-4022-BB60-16589EDD3257@delong.com> <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> <4E945737.6080108@foobar.org> Message-ID: Maybe instead of upgrading the network of cities, we could convince Google to practice by upgrading the networks of a variety of hotels in locations that NANOG might find appealing :) On Tue, Oct 11, 2011 at 10:48 AM, Nick Hilliard wrote: > On 11/10/2011 14:12, John Curran wrote: > > is far better today then in the past, as there have been many conferences > > over the years where step 1 was pulling the coax or fiber through the > > hotel to establish their first-ever network infrastructure... :-) > > There is nothing more dispiriting than "yeah sure, you can pull in that > fibre cable, but only on condition that you remove it immediately after the > [conference|meeting|whatever] is over. We already have internet > Then they point at the 2Mb DSL wifi AP and expect you to be impressed at > their technology. > > Nick > > > From owen at delong.com Tue Oct 11 10:03:56 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Oct 2011 11:03:56 -0400 Subject: meeting network In-Reply-To: <4E945737.6080108@foobar.org> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> <04331113-3535-4022-BB60-16589EDD3257@delong.com> <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> <4E945737.6080108@foobar.org> Message-ID: Sent from my iPad On Oct 11, 2011, at 10:48, Nick Hilliard wrote: > On 11/10/2011 14:12, John Curran wrote: >> is far better today then in the past, as there have been many conferences >> over the years where step 1 was pulling the coax or fiber through the >> hotel to establish their first-ever network infrastructure... :-) > > There is nothing more dispiriting than "yeah sure, you can pull in that > fibre cable, but only on condition that you remove it immediately after the > [conference|meeting|whatever] is over. We already have the Internet". > > Then they point at the 2Mb DSL wifi AP and expect you to be impressed at > their technology. > > Nick > Yes there is... There's the time when they say "No, you can't pull in that fiber. Just use the internet and set up a VPN" then point to the 1Mbps DSL wifi AP... Owen From frnkblk at iname.com Tue Oct 11 12:10:39 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 11 Oct 2011 12:10:39 -0500 Subject: meeting network In-Reply-To: <4E93FD8B.3080905@gmail.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> <4E93FD8B.3080905@gmail.com> Message-ID: <003601cc8838$b385fab0$1a91f010$@iname.com> The hotel will never refund at that level. The only thing that works is not to pay them in the first place. No hotel is that desperate enough to fill rooms that they're willing to return 50% of everything if the connectivity is poor or fails. They'll let their competitors have that business. Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Tuesday, October 11, 2011 3:26 AM To: NANOG list Subject: Re: meeting network On 10/10/11 3:41 PM, Frank Bulk wrote: > Holding the last 10% of the meeting room payment seems like a good start for > any venue. It's worthless. It's like being single-homed on a line with an SLA that refunds some small percent of your service provider fee for extended outages - fat lot of good that does you when your line Goes Down. The hotel's IT department will assure them (and you) that they have the situation covered, and then when it goes down you get a whole whopping 10% discount, but in the meantime you Have No Network. To get their attention, to make sure they are really ready to provision the network capacity correctly (with adequate hardware, software, bandwidth, appropriate configs, etc.) the penalty needs to be something closer to "50% of all fees paid by the organization AND our attendees, for meeting rooms, food service, AND for lodging". Then when the network dies everyone gets 50% refunded. That will get the hotel management's attention and *possibly* help ensure that their IT department really DOES have the situation properly spec'd and provisioned to handle the traffic. jc From mpetach at netflight.com Tue Oct 11 12:13:29 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 11 Oct 2011 10:13:29 -0700 Subject: 2011.10.11 NANOG53 tuesday morning session notes Message-ID: Wow. People drank too much coffee this morning, they were talking at warp 10. Especially that Todd Underwood fellow; someone swap him out onto decaf next time. ^_^; Video stream worked much better today than yesterday, though VLC stream seemed to be running a bit odd, so I switched back to web stream instead. Notes from the morning session are posted at http://kestrel3.netflight.com/2011.10.11-nanog53-morning-session.txt in case they might be of use to people following along remotely. Thanks! Matt From cmadams at hiwaay.net Tue Oct 11 12:59:24 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 11 Oct 2011 12:59:24 -0500 Subject: meeting network In-Reply-To: <4E945737.6080108@foobar.org> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E93D504.6050103@bogus.com> <04331113-3535-4022-BB60-16589EDD3257@delong.com> <7C122A85-A39B-49D5-9984-4824F18B5143@istaff.org> <4E945737.6080108@foobar.org> Message-ID: <20111011175924.GA1122@hiwaay.net> Once upon a time, Nick Hilliard said: > There is nothing more dispiriting than "yeah sure, you can pull in that > fibre cable, but only on condition that you remove it immediately after the > [conference|meeting|whatever] is over. We already have the Internet". I would say the situation depends on the hotel and which person you talk to. I volunteer for one of the largest science fiction conventions, and we take over 5 convention hotels for the con. I set up networking for our staff department's operations last year in one hotel, and initially we couldn't get anywhere because it was iBAHN and demanding an auth code on a captive web portal. When we got somebody from the hotel to look, he went into a closet around the corner and moved the wire, and we were then on the hotel's "direct" network. He then noticed I was running Linux, and we chatted about different distributions, and while I was setting up my (probably not allowed) wireless router, he showed back up with a box of cat5 and some ends (he was going to run some additional wires around the room for us, but saw I was running an AP and said "you're good, aren't you" and went on). We also have fiber pulled between the 5 hotels for our video feed, and that stays in place from year to year. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jmkeller at houseofzen.org Tue Oct 11 13:01:14 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Tue, 11 Oct 2011 14:01:14 -0400 Subject: Enterprise Wi-Fi list recommendations? In-Reply-To: <4e9353d6.013e440a.6b73.fffff2a8@mx.google.com> References: <4E9308E2.8090301@houseofzen.org> <4E930967.3010909@houseofzen.org> <4E935194.3050007@knownelement.com> <4e9353d6.013e440a.6b73.fffff2a8@mx.google.com> Message-ID: <4E94846A.1060908@houseofzen.org> On 10/10/2011 4:21 PM, Network IP Dog wrote: > MERAKI... http://www.meraki.com > > > E = 4:32 & Cheers!!! > > > Just had a call from them oddly enough..... (via a white paper download, not scrapping nanog fortunatly...) I signed up for the wispa and wireless-lan lists mentioned in the thread, so we'll see how that goes. Thanks all for the on and off list replies. -- --- James M Keller From mksmith at adhost.com Tue Oct 11 13:47:05 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 11 Oct 2011 18:47:05 +0000 Subject: meeting network In-Reply-To: <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> <12A72E87-09CD-4480-B10C-BD5248BF5799@delong.com> Message-ID: Just an FYI - even though you approved the wireless charge, it's actually free. They pull the per-diem/week charge off your bill. That applies to all NANOG attendees. Mike On Oct 10, 2011, at 11:36 PM, Owen DeLong wrote: > I don't think it is. I think that you can negotiate and I will point out that the hotel > here has wanted our business enough that they have now scrambled to make > life significantly better. You can also bet I'll be demanding that they credit my > $54 that I put on the in-room access be credited to my bill even though ARIN would > pay it. > > I routinely do this when the conference network (or the in-room network) sucks and it's provided by the hotel. I have yet to have one refuse my refund request. > > Owen > > On Oct 10, 2011, at 3:41 PM, Frank Bulk wrote: > >> Holding the last 10% of the meeting room payment seems like a good start for >> any venue. >> >> But as others have indicated, the market may be too small for free-market >> principles to be fully effective. >> >> Frank >> >> -----Original Message----- >> From: JC Dill [mailto:jcdill.lists at gmail.com] >> Sent: Monday, October 10, 2011 1:36 PM >> Cc: North American Network Operators' Group >> Subject: Re: meeting network >> >> On 10/10/11 7:00 AM, Owen DeLong wrote: >>> It would be wise for NANOG to approach future venues and specifically >> discuss these things with the hotel IT departments in question ahead of time >> so that they have some remote chance of being prepared. >> >> I tried this approach many years ago, for a Blogher conference. The >> hotel's IT people were uncooperative, and incompetent, and they lied >> both about their network design and their equipment capabilities. I >> have since learned that this is par for the course. IMHO the only way >> to solve this problem is with big $$$ penalties in the contract, big >> enough that the incompetent IT people realize their jobs are on the line >> and relinquish control so experts can get access and set-up things properly. >> >> Also note - the conference or hotel's IT people will always claim they >> have "done this before with no problems" even when they haven't. >> >> jc >> >> >> >> >> >> > > -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From cgriffin at ufl.edu Tue Oct 11 13:50:28 2011 From: cgriffin at ufl.edu (Chris Griffin) Date: Tue, 11 Oct 2011 14:50:28 -0400 Subject: EP.net and Almond Oil Process LLC? Message-ID: <1318359028.25782.11.camel@empacher> Anyone know what the current status is with EP.net and their new owner/parent company Almond Oil Process LLC? Some on this list may use EP.net services and have noticed the happenings of late. We contracted with EP.net for exchange space when it was owned by Bill Manning. Apparently it was sold and since then things have gone downhill. We were trying to get a simple authority record changed to no avail despite dozens of contact attempts, and now it appears the ep.net domain is functionally gone, which is causing even more issues. Any hints or current contact information would be helpful. Calls/email to ARIN POCs currently go unanswered. Tnx Chris -- Chris Griffin cgriffin at ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 From scott at doc.net.au Tue Oct 11 14:03:41 2011 From: scott at doc.net.au (Scott Howard) Date: Tue, 11 Oct 2011 12:03:41 -0700 Subject: Y'all know Google is offering public DNS services now? In-Reply-To: References: <14E8819D6503450BAA8E627D0A48A529@owner59e1f1502> Message-ID: On Mon, Oct 10, 2011 at 11:04 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Tue, Oct 11, 2011 at 1:19 AM, Scott Howard wrote: > > the initial release date (not > > actually shown in the that version as far as I can see, but it was around > > the same time Google announced their public DNS servers). > > jan 27 2011, so says the doc header... > The original draft had a different name, and was released in Jan 2010. http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-00 Scott From dotis at mail-abuse.org Tue Oct 11 15:00:44 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 11 Oct 2011 13:00:44 -0700 Subject: Steve Jobs has died In-Reply-To: <4E8E6354.1090006@paulgraydon.co.uk> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> <20111007020258.GA41873@wakko.typo.org> <4E8E6354.1090006@paulgraydon.co.uk> Message-ID: <4E94A06C.70402@mail-abuse.org> On 10/6/11 7:26 PM, Paul Graydon wrote: > On 10/6/2011 4:02 PM, Wayne E Bouchard wrote: >> In some circles, he's being compared to Thomas Edison. Apply your own >> opinion there whether you feel that's accurate or not. I'll just state >> this: Both men were pasionate about what they did. They each changed >> the world and left it better than they found it. > It's probably not a bad analogy, like Ford and many other champions of > industry he didn't invent groundbreaking technology (Edison's only > invention was the phonograph IIRC, all else was improvements on > existing technology). They took what was already in existence and did > something amazing with it: made it accessible, be it through price, > ease of use or whatever. Steve demonstrated any number of times, when excellent hardware + software engineering + quality control is applied, even "commodity" products are able to provide good returns. In this view, the analogy holds when price alone is not considered. -Doug From randy at psg.com Tue Oct 11 16:02:53 2011 From: randy at psg.com (Randy Bush) Date: Tue, 11 Oct 2011 17:02:53 -0400 Subject: meeting network In-Reply-To: <003601cc8838$b385fab0$1a91f010$@iname.com> References: <4E92E93E.5070109@foobar.org> <43EECF70-5C6D-47F7-9156-F608BF1AE896@arbor.net> <4E933B18.8010501@gmail.com> <002b01cc879d$c5f2f130$51d8d390$@iname.com> <4E93FD8B.3080905@gmail.com> <003601cc8838$b385fab0$1a91f010$@iname.com> Message-ID: > The hotel will never refund at that level. ietf maastricht gave 100% refunds never say never From lowen at pari.edu Tue Oct 11 16:17:06 2011 From: lowen at pari.edu (Lamar Owen) Date: Tue, 11 Oct 2011 17:17:06 -0400 Subject: Steve Jobs has died In-Reply-To: <4E94A06C.70402@mail-abuse.org> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> Message-ID: <201110111717.07171.lowen@pari.edu> On Tuesday, October 11, 2011 04:00:44 PM Douglas Otis wrote: > On 10/6/11 7:26 PM, Paul Graydon wrote: > > On 10/6/2011 4:02 PM, Wayne E Bouchard wrote: > >> In some circles, he's being compared to Thomas Edison. > > It's probably not a bad analogy, like Ford and many other champions of > > industry he didn't invent groundbreaking technology > Steve demonstrated any number of times, when excellent hardware + > software engineering + quality control is applied, even "commodity" > products are able to provide good returns. In this view, the analogy > holds when price alone is not considered. And, like Edison, Mr. Jobs fiercely championed his own technologies over all others; just one example is in the field of electricity where Edison's DC lost the war to Tesla's AC. Time has yet to tell how well Mr. Jobs' walled garden devices and OS's do, finally. Edison would have loved today's intellectual property wars and software patents and their attendent trolls. And Edison would have been right at home with the concept of lock-in. Brilliant man, Edison was, and he did do a great deal for humanity in general. But historical facts are historical facts. Don't get me wrong; I have a great deal of respect for both men, even though I disagree with some of their ideologies and methods. And the phonograph really was pure brilliance. From steve at pirk.com Tue Oct 11 16:19:50 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Tue, 11 Oct 2011 14:19:50 -0700 Subject: Were A record domain names ever limited to 23 characters? In-Reply-To: <4e9394d2.c6482a0a.53da.ffffb1bfSMTPIN_ADDED@mx.google.com> References: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com> <4e9394d2.c6482a0a.53da.ffffb1bfSMTPIN_ADDED@mx.google.com> Message-ID: Hahahahaha! That is awesome. On Mon, Oct 10, 2011 at 17:50, wrote: > back in the day, > > abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ.ca.us. > > existed to test the length of DNS label. circa 1992 > > ^b.com also existed (yes, we considered ^p) > > > the heady days of DNS evolution! > > /bill > > > On Fri, Oct 07, 2011 at 06:16:46PM -0700, Owen DeLong wrote: > > NSI was never the only registrar. They were just the only registrar > > for COM, ORG, NET, EDU, and possibly a few other TLDs, but, > > they were, for example, never the registrar for US or many other > > CCTLDs. > > > > Therefore, it was not internet wide, though I will admit that it did > > cover most of the widely known gTLDs. > > > > Owen > > > > On Oct 7, 2011, at 4:45 PM, steve pirk [egrep] wrote: > > > > > It turns out it was an artificial limitation on Network Solution's > part. > > > Being the only registrar at the time, it was pretty much internet wide > at > > > that point, contrary to the RFC spec. > > > > > > What was so funny was that someone got Internic/Network Solutions to up > the > > > limit. Apparently just to save some money on reprinting movie > posters... ok, > > > so they would have had to change some trailers... > > > ;-] > > > > > > On Fri, Oct 7, 2011 at 16:39, Jimmy Hess wrote: > > > > > >> On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin > wrote: > > >>> I remember tales from when there was an eight character limit. But > that > > >> was > > >>> back when you didn't have to pay for them and they assigned you a > class-c > > >>> block automatically. Of course it took six weeks to register because > > >> there > > >>> was only one person running the registry. > > >> > > >> You may be referring to a limitation of a certain OS regarding a > > >> hostname; or some network's policy. > > >> But the DNS protocol itself never had a limit of 8 characters. > > >> When we are talking about the contents of "A" record names, > > >> > > >> I would refer you to > > >> http://www.rfc-editor.org/rfc/rfc2181.txt > > >> "RFC 2181 > > >> Clarifications to the DNS Specification R. Elz, R. Bush > > >> [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) > > >> (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) > > >> (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " > > >> > > >> " > > >> Elz & Bush Standards Track [Page > 12] > > >> ... > > >> Occasionally it is assumed that the Domain Name System serves only > > >> the purpose of mapping Internet host names to data, and mapping > > >> Internet addresses to host names. This is not correct, the DNS is a > > >> general (if somewhat limited) hierarchical database, and can store > > >> almost any kind of data, for almost any purpose. > > >> ... > > >> 11. Name syntax > > >> " > > >> The length of any one label is limited to between 1 and 63 octets. A > > >> full domain > > >> name is limited to 255 octets (including the separators). The zero > > >> length full name is defined as representing the root of the DNS tree, > > >> and is typically written and displayed as ".". Those restrictions > > >> aside, any binary string whatever can be used as the label of any > > >> resource record. > > >> " > > >> > > >> -- > > >> -JH > > >> > > > > > > > > > > > > -- > > > steve pirk > > > refiamerica.org > > > "father... the sleeper has awakened..." paul atreides - dune > > > kexp.org member august '09 > > > > > -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 - Google+ pirk.com From mpetach at netflight.com Tue Oct 11 17:24:29 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 11 Oct 2011 15:24:29 -0700 Subject: 2011.10.11 NANOG53 tues afternoon notes Message-ID: Notes from the tuesday afternoon session have been posted to http://kestrel3.netflight.com/2011.10.11-nanog53-afternoon-session.txt for those who might find them useful...and apache has been restarted for those who pointed out it was hung earlier. ^_^; Thanks! Matt From asmith at ursinus.edu Wed Oct 12 04:33:21 2011 From: asmith at ursinus.edu (Smith, C. Aaron) Date: Wed, 12 Oct 2011 05:33:21 -0400 Subject: Prize looking for a good home Message-ID: <2246F8B902DEFB44B0A83C82D366F5521E6CFE76C1@Exchange02.ursinus.local> I was the lucky winner of one of Tuesday's prizes at NANOG 53 in lovely Philadelphia and all becuase I filled out one of the survey's! The prize is a $500 credit towards any MRV product purchased through J-iNet Solutions. If this is something you are interested in having for yourself I can be convinced to part with it for a fraction of its listed value. Please contact me offline with your offers. I will be at the conference until its end later today. Thanks, Aaron Smith asmith at ursinus.edu From andrew.wallace at rocketmail.com Wed Oct 12 09:47:13 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 12 Oct 2011 07:47:13 -0700 (PDT) Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <003701cc8844$10741b20$315c5160$@iname.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> Message-ID: <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ Andrew ________________________________ From: Frank Bulk To: outages at outages.org Sent: Tuesday, October 11, 2011 7:32 PM Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) And continues: ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics ? Frank ? From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Monday, October 10, 2011 2:52 PM To: frnkblk at iname.com Cc: outages at outages.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) ? RIM shares down as BlackBerry outage continues ? http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 ? Andrew ? ________________________________ From:Frank Bulk To: outages at outages.org Sent: Monday, October 10, 2011 2:47 PM Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber ry-services-down-worldwide,-Egypt-affected.aspx FYI _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages From bhmccie at gmail.com Wed Oct 12 09:52:02 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 12 Oct 2011 09:52:02 -0500 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Message-ID: <4E95A992.6040302@gmail.com> What kills me is what they have told the public. The lost a "core switch". I don't know if they actually mean network switch or not but I'm pretty sure any of us that work on an enterprise environment know how to factor N+1 just for these types of days. And then the backup solution failed? I'm not buying it either. -Hammer- "I was a normal American nerd" -Jack Herer On 10/12/2011 09:47 AM, andrew.wallace wrote: > Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. > > http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ > > > Andrew > > > > ________________________________ > From: Frank Bulk > To: outages at outages.org > Sent: Tuesday, October 11, 2011 7:32 PM > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > > And continues: > ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? > http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics > > Frank > > From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Monday, October 10, 2011 2:52 PM > To: frnkblk at iname.com > Cc: outages at outages.org > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > RIM shares down as BlackBerry outage continues > > http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 > > Andrew > > > ________________________________ > > From:Frank Bulk > To: outages at outages.org > Sent: Monday, October 10, 2011 2:47 PM > Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber > ry-services-down-worldwide,-Egypt-affected.aspx > > FYI > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > From andy-nanog at bash.sh Wed Oct 12 09:54:38 2011 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Wed, 12 Oct 2011 15:54:38 +0100 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Message-ID: Never put down to malice which can be more easily explained by stupidity.. or in this case failure. RIM explained the problem earlier.. "The messaging and browsing delays being experienced by BlackBerry users in Europe, the Middle East, Africa, India, Brazil, Chile and Argentina were caused by a core switch failure within RIM's infrastructure. Although the system is designed to failover to a back-up switch, the failover did not function as previously tested. As a result, a large backlog of data was generated and we are now working to clear that backlog and restore normal service as quickly as possible. We apologise for any inconvenience and we will continue to keep you informed." This appears to have been a result of a change on monday "The problems began at about 11am on Monday. The Guardian understands that RIM was attempting a software upgrade on its database but suffered corruption problems, and that attempts to switch back to an older version led to a collapse" http://www.guardian.co.uk/technology/2011/oct/12/blackberry-outage-executive-apologies?newsfeed=true thanks andrew On Wed, Oct 12, 2011 at 3:47 PM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > Guys the outage has moved to U.S and Canada, I think we need to look at > this perhaps being sabotage. > > > http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ > > > Andrew > > > > ________________________________ > From: Frank Bulk > To: outages at outages.org > Sent: Tuesday, October 11, 2011 7:32 PM > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt > affected (not N.A.) > > > And continues: > ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? > http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics > > Frank > > From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Monday, October 10, 2011 2:52 PM > To: frnkblk at iname.com > Cc: outages at outages.org > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt > affected (not N.A.) > > RIM shares down as BlackBerry outage continues > > > http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 > > Andrew > > > ________________________________ > > From:Frank Bulk > To: outages at outages.org > Sent: Monday, October 10, 2011 2:47 PM > Subject: [outages] News item: Blackberry services down worldwide, Egypt > affected (not N.A.) > > > http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber > ry-services-down-worldwide,-Egypt-affected.aspx > > FYI > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > From paul at paulstewart.org Wed Oct 12 09:59:34 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 12 Oct 2011 10:59:34 -0400 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Message-ID: <007a01cc88ef$8ff5e580$afe1b080$@paulstewart.org> Maybe they use the same security solutions as Playstation Network does... that would explain a lot suddenly. Paul -----Original Message----- From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Wednesday, October 12, 2011 10:47 AM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ Andrew ________________________________ From: Frank Bulk To: outages at outages.org Sent: Tuesday, October 11, 2011 7:32 PM Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) And continues: ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics Frank From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Monday, October 10, 2011 2:52 PM To: frnkblk at iname.com Cc: outages at outages.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) RIM shares down as BlackBerry outage continues http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 Andrew ________________________________ From:Frank Bulk To: outages at outages.org Sent: Monday, October 10, 2011 2:47 PM Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber ry-services-down-worldwide,-Egypt-affected.aspx FYI _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages From balbee at orscheln.com Wed Oct 12 10:04:31 2011 From: balbee at orscheln.com (Ben Albee) Date: Wed, 12 Oct 2011 10:04:31 -0500 Subject: [outages] News item: Blackberry services down worldwide Message-ID: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Our blackberry service with Us Cellular in Missouri started having issues about 8am this morning. From joelja at bogus.com Wed Oct 12 10:39:23 2011 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 12 Oct 2011 08:39:23 -0700 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Message-ID: <4E95B4AB.60706@bogus.com> On 10/12/11 07:47 , andrew.wallace wrote: > Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. > > http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ North American outages of the blackberry platform (particularly related to upgrades gone wrong) were not uncommon. Think for example sept 10, dec 18 and dec 22 2009. > > Andrew > > > > ________________________________ > From: Frank Bulk > To: outages at outages.org > Sent: Tuesday, October 11, 2011 7:32 PM > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > > And continues: > ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? > http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics > > Frank > > From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Monday, October 10, 2011 2:52 PM > To: frnkblk at iname.com > Cc: outages at outages.org > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > RIM shares down as BlackBerry outage continues > > http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 > > Andrew > > > ________________________________ > > From:Frank Bulk > To: outages at outages.org > Sent: Monday, October 10, 2011 2:47 PM > Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber > ry-services-down-worldwide,-Egypt-affected.aspx > > FYI > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > From Valdis.Kletnieks at vt.edu Wed Oct 12 10:41:50 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Oct 2011 11:41:50 -0400 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: Your message of "Wed, 12 Oct 2011 07:47:13 PDT." <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> Message-ID: <6446.1318434110@turing-police.cc.vt.edu> On Wed, 12 Oct 2011 07:47:13 PDT, "andrew.wallace" said: > Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. It ain't sabotage till you rule out "misconfigured router". Consider the actual real-world threat models and their likelyhoods: 1) Insufficiently caffienated network engineer - this *NEVER* happens in real life, it's a total Bruce Schneier caliber movie-plot scenario. 2) Somebody sabotaging a RIM router. This is more likely, because there's just *bazillions* of people out there that stand to benefit from a RIM outage (and in fact profit more from an outage than from being able to watch traffic as it goes by). It's just a question of which one of those bazillions did it *this* time. Andrew, you *really* need to learn what the actual failure modes and root causes in real-life production networks are, and draw conclusions from reality, not whatever MI-7 inspired dream world the claim of "sabotage" 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 mpetach at netflight.com Wed Oct 12 10:46:53 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 12 Oct 2011 08:46:53 -0700 Subject: 2011.10.12 NANOG53 weds morning session notes Message-ID: Wow. As always, Geoff Huston really knows how to deliver a message in a way that just reaches right out and grabs you; awesome, awesome keynote talk, that's going to be another one for the archives. ^_^ Notes from this morning's session have been posted to http://kestrel3.netflight.com/2011.10.12-nanog53-morning-session.txt Thanks again to all the speakers for a great conference--see you all in San Diego!! Matt From Valdis.Kletnieks at vt.edu Wed Oct 12 10:49:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Oct 2011 11:49:56 -0400 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: Your message of "Wed, 12 Oct 2011 09:52:02 CDT." <4E95A992.6040302@gmail.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> Message-ID: <6707.1318434596@turing-police.cc.vt.edu> On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: > What kills me is what they have told the public. The lost a "core > switch". I don't know if they actually mean network switch or not but > I'm pretty sure any of us that work on an enterprise environment know > how to factor N+1 just for these types of days. And then the backup > solution failed? I'm not buying it either. Yeah, and that extra comma in the one config file that didn't make a difference when you tested the failover in the lab *never* makes a difference when it hits in the production network, right? Or they changed the config of the primary and it didn't get propogated just right to the backup, or they had mismatched firmware levels on blades in the blades on the primary and backup switches, so traffic that didn't tickle a bug on the primary blades caused the blade to crash on the backup, or... Anybody on this list who's been around long enough probably has enough "We should have had N+2 because the N+1'th device failed too" stories to drain *several* pitchers of beer at a good pub... I've even had one case where my butt got *saved* from a ohnosecond-class whoops because the N+1'th device *was* crashed (stomped a config file, it replicated, was able to salvage a copy from a device that didn't replicate because it was down at the time). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From w3yni1 at gmail.com Wed Oct 12 10:54:48 2011 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 12 Oct 2011 11:54:48 -0400 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <6707.1318434596@turing-police.cc.vt.edu> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> Message-ID: +1 On Oct 12, 2011 11:51 AM, wrote: > On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: > > What kills me is what they have told the public. The lost a "core > > switch". I don't know if they actually mean network switch or not but > > I'm pretty sure any of us that work on an enterprise environment know > > how to factor N+1 just for these types of days. And then the backup > > solution failed? I'm not buying it either. > > Yeah, and that extra comma in the one config file that didn't make a > difference > when you tested the failover in the lab *never* makes a difference when it > hits > in the production network, right? Or they changed the config of the > primary and > it didn't get propogated just right to the backup, or they had mismatched > firmware > levels on blades in the blades on the primary and backup switches, so > traffic that > didn't tickle a bug on the primary blades caused the blade to crash on the > backup, > or... > > Anybody on this list who's been around long enough probably has enough "We > should have had N+2 because the N+1'th device failed too" stories to drain > *several* pitchers of beer at a good pub... I've even had one case where my > butt got *saved* from a ohnosecond-class whoops because the N+1'th device > *was* > crashed (stomped a config file, it replicated, was able to salvage a copy > from > a device that didn't replicate because it was down at the time). > > From tayeb.meftah at gmail.com Wed Oct 12 10:56:40 2011 From: tayeb.meftah at gmail.com (Tayeb Meftah) Date: Wed, 12 Oct 2011 17:56:40 +0200 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> Message-ID: <8989499694939820800@unknownmsgid> Idiotberry Envoy? de mon iPhone Le 12 oct. 2011 ? 17:55, Charles Mills a ?crit : > +1 > On Oct 12, 2011 11:51 AM, wrote: > >> On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: >>> What kills me is what they have told the public. The lost a "core >>> switch". I don't know if they actually mean network switch or not but >>> I'm pretty sure any of us that work on an enterprise environment know >>> how to factor N+1 just for these types of days. And then the backup >>> solution failed? I'm not buying it either. >> >> Yeah, and that extra comma in the one config file that didn't make a >> difference >> when you tested the failover in the lab *never* makes a difference when it >> hits >> in the production network, right? Or they changed the config of the >> primary and >> it didn't get propogated just right to the backup, or they had mismatched >> firmware >> levels on blades in the blades on the primary and backup switches, so >> traffic that >> didn't tickle a bug on the primary blades caused the blade to crash on the >> backup, >> or... >> >> Anybody on this list who's been around long enough probably has enough "We >> should have had N+2 because the N+1'th device failed too" stories to drain >> *several* pitchers of beer at a good pub... I've even had one case where my >> butt got *saved* from a ohnosecond-class whoops because the N+1'th device >> *was* >> crashed (stomped a config file, it replicated, was able to salvage a copy >> from >> a device that didn't replicate because it was down at the time). >> >> From chris at ctcampbell.com Wed Oct 12 10:58:21 2011 From: chris at ctcampbell.com (Chris Campbell) Date: Wed, 12 Oct 2011 16:58:21 +0100 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <6707.1318434596@turing-police.cc.vt.edu> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> Message-ID: <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> I think it raises serious questions about RIM's DR strategy if a DB corruption or switch failure or whatever can cause this much outage. 'Surely' RIM have an second site that is independent of the primary (within reason) that they could of flipped to when they realised the DB was borked. If not then any business that relies on them needs to be shouting from the rooftops to get RIM to fix it. Chris. On 12 Oct 2011, at 16:49, Valdis.Kletnieks at vt.edu wrote: > On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: >> What kills me is what they have told the public. The lost a "core >> switch". I don't know if they actually mean network switch or not but >> I'm pretty sure any of us that work on an enterprise environment know >> how to factor N+1 just for these types of days. And then the backup >> solution failed? I'm not buying it either. > > Yeah, and that extra comma in the one config file that didn't make a difference > when you tested the failover in the lab *never* makes a difference when it hits > in the production network, right? Or they changed the config of the primary and > it didn't get propogated just right to the backup, or they had mismatched firmware > levels on blades in the blades on the primary and backup switches, so traffic that > didn't tickle a bug on the primary blades caused the blade to crash on the backup, > or... > > Anybody on this list who's been around long enough probably has enough "We > should have had N+2 because the N+1'th device failed too" stories to drain > *several* pitchers of beer at a good pub... I've even had one case where my > butt got *saved* from a ohnosecond-class whoops because the N+1'th device *was* > crashed (stomped a config file, it replicated, was able to salvage a copy from > a device that didn't replicate because it was down at the time). > From bhmccie at gmail.com Wed Oct 12 11:06:29 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 12 Oct 2011 11:06:29 -0500 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> Message-ID: <4E95BB05.2010103@gmail.com> I have been witness to N+1 HUMAN failures but never a N+1 hardware failure or system/design failure that warranted questioning the need for N+2. Usually your N+1 failure is (as already referenced) pasting in a bad config that gets replicated or something like that. Not saying the hardware is perfect. It's just that I haven't personally seen a full blown failure like that without human help. Closest example would be an update that wasn't properly vetted in dev/test before migrating to prod. I've seen a few of those that I guess you could blame on the system. Even though the humans could have tested better.... -Hammer- "I was a normal American nerd" -Jack Herer On 10/12/2011 10:58 AM, Chris Campbell wrote: > I think it raises serious questions about RIM's DR strategy if a DB corruption or switch failure or whatever can cause this much outage. 'Surely' RIM have an second site that is independent of the primary (within reason) that they could of flipped to when they realised the DB was borked. If not then any business that relies on them needs to be shouting from the rooftops to get RIM to fix it. > > Chris. > > > On 12 Oct 2011, at 16:49, Valdis.Kletnieks at vt.edu wrote: > > >> On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: >> >>> What kills me is what they have told the public. The lost a "core >>> switch". I don't know if they actually mean network switch or not but >>> I'm pretty sure any of us that work on an enterprise environment know >>> how to factor N+1 just for these types of days. And then the backup >>> solution failed? I'm not buying it either. >>> >> Yeah, and that extra comma in the one config file that didn't make a difference >> when you tested the failover in the lab *never* makes a difference when it hits >> in the production network, right? Or they changed the config of the primary and >> it didn't get propogated just right to the backup, or they had mismatched firmware >> levels on blades in the blades on the primary and backup switches, so traffic that >> didn't tickle a bug on the primary blades caused the blade to crash on the backup, >> or... >> >> Anybody on this list who's been around long enough probably has enough "We >> should have had N+2 because the N+1'th device failed too" stories to drain >> *several* pitchers of beer at a good pub... I've even had one case where my >> butt got *saved* from a ohnosecond-class whoops because the N+1'th device *was* >> crashed (stomped a config file, it replicated, was able to salvage a copy from >> a device that didn't replicate because it was down at the time). >> >> > > From leigh.porter at ukbroadband.com Wed Oct 12 11:12:31 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 12 Oct 2011 16:12:31 +0000 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <4E95BB05.2010103@gmail.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> <4E95BB05.2010103@gmail.com> Message-ID: > -----Original Message----- > From: -Hammer- [mailto:bhmccie at gmail.com] > Sent: 12 October 2011 17:10 > To: nanog at nanog.org > Subject: Re: [outages] News item: Blackberry services down worldwide, > Egypt affected (not N.A.) > > I have been witness to N+1 HUMAN failures but never a N+1 hardware > failure or system/design failure that warranted questioning the need > for > N+2. Usually your N+1 failure is (as already referenced) pasting in a > bad config that gets replicated or something like that. Not saying the > hardware is perfect. It's just that I haven't personally seen a full > blown failure like that without human help. You have not seen VIP2-40s and CEF in action ;-) -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From ekim.ittag at gmail.com Wed Oct 12 11:53:28 2011 From: ekim.ittag at gmail.com (Mike Gatti) Date: Wed, 12 Oct 2011 09:53:28 -0700 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> <4E95BB05.2010103@gmail.com> Message-ID: I have and totally get the point ... -- Michael Gatti cell.949.735.5612 ekim.ittag at gmail.com (UTC-8) On Oct 12, 2011, at 9:12 AM, Leigh Porter wrote: > > >> -----Original Message----- >> From: -Hammer- [mailto:bhmccie at gmail.com] >> Sent: 12 October 2011 17:10 >> To: nanog at nanog.org >> Subject: Re: [outages] News item: Blackberry services down worldwide, >> Egypt affected (not N.A.) >> >> I have been witness to N+1 HUMAN failures but never a N+1 hardware >> failure or system/design failure that warranted questioning the need >> for >> N+2. Usually your N+1 failure is (as already referenced) pasting in a >> bad config that gets replicated or something like that. Not saying the >> hardware is perfect. It's just that I haven't personally seen a full >> blown failure like that without human help. > > You have not seen VIP2-40s and CEF in action ;-) > > -- > Leigh Porter > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From forum at lemcoe.com Wed Oct 12 11:59:02 2011 From: forum at lemcoe.com (D. Marshall Lemcoe Jr.) Date: Wed, 12 Oct 2011 12:59:02 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: Haven't received an e-mail on my Blackberry since around 4AM, located in Atlanta. On Wed, Oct 12, 2011 at 11:04 AM, Ben Albee wrote: > Our blackberry service with Us Cellular in Missouri started having > issues about 8am this morning. > > From ralph.brandt at pateam.com Wed Oct 12 12:00:34 2011 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Wed, 12 Oct 2011 13:00:34 -0400 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <4E95A992.6040302@gmail.com> References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> Message-ID: <51C66083768C2949A7EB14910C78B0170166D709@embgsr24.pateam.com> They are out there scrambling, trying to figure out where the truck that hit them came from. The PIO has been told to make up a story. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email Ralph.Brandt at pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -----Original Message----- From: -Hammer- [mailto:bhmccie at gmail.com] Sent: Wednesday, October 12, 2011 10:52 AM To: nanog at nanog.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) What kills me is what they have told the public. The lost a "core switch". I don't know if they actually mean network switch or not but I'm pretty sure any of us that work on an enterprise environment know how to factor N+1 just for these types of days. And then the backup solution failed? I'm not buying it either. -Hammer- "I was a normal American nerd" -Jack Herer On 10/12/2011 09:47 AM, andrew.wallace wrote: > Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. > > http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ > > > Andrew > > > > ________________________________ > From: Frank Bulk > To: outages at outages.org > Sent: Tuesday, October 11, 2011 7:32 PM > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > > And continues: > ?RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2? > http://www.channelstv.com/global/news_details.php?nid=29652&cat=Politics > > Frank > > From:andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Monday, October 10, 2011 2:52 PM > To: frnkblk at iname.com > Cc: outages at outages.org > Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > RIM shares down as BlackBerry outage continues > > http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 > > Andrew > > > ________________________________ > > From:Frank Bulk > To: outages at outages.org > Sent: Monday, October 10, 2011 2:47 PM > Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) > > http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber > ry-services-down-worldwide,-Egypt-affected.aspx > > FYI > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From carlosm3011 at gmail.com Wed Oct 12 12:01:25 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 12 Oct 2011 15:01:25 -0200 Subject: Botnets buying up IPv4 address space In-Reply-To: <4E928F58.8040402@redpill-linpro.com> References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> <4E928F58.8040402@redpill-linpro.com> Message-ID: Maybe we should just allow this to go on until all IPv4 space is so polluted that no-one wants to use it anymore :-) "Bad Reputation as an IPv6 Transition Driver" Nice title for a PPT deck... On Mon, Oct 10, 2011 at 4:23 AM, Tore Anderson wrote: > * Martin Millnert > >> RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*. > > I wonder if that one was listed by mistake. The prefix in question, > 128.0.16.0/20, was assigned to NetWave Ltd. by the NCC last Tuesday. If > it isn't a mistake, I wonder how they justified obtaining the prefix in > the first place. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From leigh.porter at ukbroadband.com Wed Oct 12 12:05:09 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 12 Oct 2011 17:05:09 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: > -----Original Message----- > From: D. Marshall Lemcoe Jr. [mailto:forum at lemcoe.com] > Sent: 12 October 2011 18:01 > Cc: nanog at nanog.org > Subject: Re: [outages] News item: Blackberry services down worldwide > > Haven't received an e-mail on my Blackberry since around 4AM, located > in Atlanta. > Email on my iPhone is working fine.. ;-) -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From steve at pirk.com Wed Oct 12 12:12:23 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Wed, 12 Oct 2011 10:12:23 -0700 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: Found this posting: > Blackberry down. Research in Motion (RIM) sent the following e-mail to all > clients: > To: All Blackberry Clients > > Please be advised that Research in Motion (RIM) is experiencing world-wide > connectivity issues affecting email flow to and from all Blackberries. > RIM has not provided an expected time to resolution as of yet. > Once we receive notice that the issue is resolved, we will forward that > information to you. > > Thank you, > Corporate Information Systems/Mobile Services On Wed, Oct 12, 2011 at 10:05, Leigh Porter wrote: > > > > -----Original Message----- > > From: D. Marshall Lemcoe Jr. [mailto:forum at lemcoe.com] > > Sent: 12 October 2011 18:01 > > Cc: nanog at nanog.org > > Subject: Re: [outages] News item: Blackberry services down worldwide > > > > Haven't received an e-mail on my Blackberry since around 4AM, located > > in Atlanta. > > > > Email on my iPhone is working fine.. ;-) > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 - Google+ pirk.com From jra at baylink.com Wed Oct 12 12:18:02 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Oct 2011 13:18:02 -0400 (EDT) Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: <6446.1318434110@turing-police.cc.vt.edu> Message-ID: <7706112.4822.1318439882197.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Wed, 12 Oct 2011 07:47:13 PDT, "andrew.wallace" said: > > Guys the outage has moved to U.S and Canada, I think we need to look > > at this perhaps being sabotage. > > It ain't sabotage till you rule out "misconfigured router". > > Andrew, you *really* need to learn what the actual failure modes and > root causes in real-life production networks are, and draw conclusions > from reality, not whatever MI-7 inspired dream world the claim of > "sabotage" came from. In fairness, Valdis, Andrew did not say "this was obviously sabotage". He suggested that that possibility be added to the list of things which the RIM employees tasked with finding a root cause consider. I think the old filtering rule applies here: Once is happenstance. Twice is coincidence. Three times is enemy action. If this turns out to look like it came from 3 or more non-cascading failures, then sabotage will look a little more likely. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From ops.lists at gmail.com Wed Oct 12 12:26:27 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 12 Oct 2011 22:56:27 +0530 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> <4E928F58.8040402@redpill-linpro.com> Message-ID: And I suppose the bad guys who are out there gaming RIPE etc policies are not touching v6 with a bargepole? Or are they stockpiling massive amounts of v6 space? On Wed, Oct 12, 2011 at 10:31 PM, Carlos Martinez-Cagnazzo < carlosm3011 at gmail.com> wrote: > Maybe we should just allow this to go on until all IPv4 space is so > polluted that no-one wants to use it anymore :-) > > "Bad Reputation as an IPv6 Transition Driver" > -- Suresh Ramasubramanian (ops.lists at gmail.com) From carlosm3011 at gmail.com Wed Oct 12 12:31:10 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 12 Oct 2011 15:31:10 -0200 Subject: DPI deployment use case In-Reply-To: <4BA0B1DD-93D2-41CA-AECA-BACBD9E75A2E@gmail.com> References: <4BA0B1DD-93D2-41CA-AECA-BACBD9E75A2E@gmail.com> Message-ID: Apparently Telcos are faced with implementing the following algorithm to create value-added services: - Take service S with provides value Y - Artificially remove value, creating new service V - Price V at the same level as S - Offer old S at a higher price point and market it as a "value added" service, compared to V One would have thought that "value added" referred to well, *adding* value to what already exists, not rehashing current offers and artificially limiting them. But then again, I don't think like a marketing person. If you want a funny look at a not-so-funny and grim possible future scenario, you might want to read this: http://www.nlnetlabs.nl/~olaf/LACNIC_XVI_Meat_and_Greed.pdf regards Carlos On Mon, Oct 10, 2011 at 1:59 PM, Arturo Servin wrote: > > ? ? ? ?I imagine that those proposals are not from users ? > > ? ? ? ?I would add "tyrannical" telcos cracking down on their own customers. > > -as > > On 7 Oct 2011, at 14:20, Claudio Lapidus wrote: > >> Hello, >> >> On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert wrote: >> >>> I've seen tyrannical governments use Bluecoat's to crack down on their >>> own population(*). >>> Was this the sort of use-case you were looking for? :) >>> >> Ummm, not really... :) >> >> Actually, we've been faced with proposals to build services based on traffic >> classification, like e.g. "access our own webmail and all social networking >> sites, but not skype and video" or the capability to do exact metering based >> on net traffic time or volume, as well as being able to redirect the >> customer to various captive portals using HTTP redirect directly from the >> DPI box, and such. > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From bhmccie at gmail.com Wed Oct 12 12:29:25 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 12 Oct 2011 12:29:25 -0500 Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) In-Reply-To: References: <000a01cc8753$1dcb4d80$5961e880$@iname.com> <1318276348.21141.YahooMailNeo@web59609.mail.ac4.yahoo.com> <003701cc8844$10741b20$315c5160$@iname.com> <1318430833.60190.YahooMailNeo@web59612.mail.ac4.yahoo.com> <4E95A992.6040302@gmail.com> <6707.1318434596@turing-police.cc.vt.edu> <3EE2ABC4-5A45-49A9-BA0C-0F0AF04201DA@ctcampbell.com> <4E95BB05.2010103@gmail.com> Message-ID: <4E95CE75.1020306@gmail.com> Again. I know those stories are out there. I'm blessed with a lower profile or higher karma. One of the two. -Hammer- "I was a normal American nerd" -Jack Herer On 10/12/2011 11:53 AM, Mike Gatti wrote: > I have and totally get the point ... > > -- > Michael Gatti > cell.949.735.5612 > ekim.ittag at gmail.com > (UTC-8) > > > > On Oct 12, 2011, at 9:12 AM, Leigh Porter wrote: > > >> >> >>> -----Original Message----- >>> From: -Hammer- [mailto:bhmccie at gmail.com] >>> Sent: 12 October 2011 17:10 >>> To: nanog at nanog.org >>> Subject: Re: [outages] News item: Blackberry services down worldwide, >>> Egypt affected (not N.A.) >>> >>> I have been witness to N+1 HUMAN failures but never a N+1 hardware >>> failure or system/design failure that warranted questioning the need >>> for >>> N+2. Usually your N+1 failure is (as already referenced) pasting in a >>> bad config that gets replicated or something like that. Not saying the >>> hardware is perfect. It's just that I haven't personally seen a full >>> blown failure like that without human help. >>> >> You have not seen VIP2-40s and CEF in action ;-) >> >> -- >> Leigh Porter >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > From carlos at lacnic.net Wed Oct 12 12:34:06 2011 From: carlos at lacnic.net (Carlos Martinez-Cagnazzo) Date: Wed, 12 Oct 2011 15:34:06 -0200 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> <4E928F58.8040402@redpill-linpro.com> Message-ID: I don't buy the "bad-guys-rig-policies" thing... but well, I could be wrong. But regarding your second comment, yes, I do believe that bad guys take the path of least resistance whenever possible. At some point IPv6 will look attractive to them and they will start using it. My logs show that I get spam over IPv6, so some bad guys might be already doing it. cheers! Carlos On Wed, Oct 12, 2011 at 3:26 PM, Suresh Ramasubramanian wrote: > And I suppose the bad guys who are out there gaming RIPE etc policies are > not touching v6 with a bargepole? > > Or are they stockpiling massive amounts of v6 space? > > On Wed, Oct 12, 2011 at 10:31 PM, Carlos Martinez-Cagnazzo < > carlosm3011 at gmail.com> wrote: > >> Maybe we should just allow this to go on until all IPv4 space is so >> polluted that no-one wants to use it anymore :-) >> >> "Bad Reputation as an IPv6 Transition Driver" >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From jeroen at unfix.org Wed Oct 12 12:41:36 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 12 Oct 2011 19:41:36 +0200 Subject: Botnets buying up IPv4 address space In-Reply-To: References: <20111007173150.GA12261@vortex.com> <4AF3AAB1-5201-457B-9112-58CE2339EA5A@gmail.com> <3D7740C9-03D5-4A43-A7FD-69B1CC565EA2@virtualized.org> <18AB124B-AA19-4D5E-8AB9-2446CA766496@gmail.com> <4E928F58.8040402@redpill-linpro.com> Message-ID: <4E95D150.1020008@unfix.org> On 2011-10-12 19:34 , Carlos Martinez-Cagnazzo wrote: > I don't buy the "bad-guys-rig-policies" thing... but well, I could be wrong. Rigging is not the right name for it, which is why the original message stated 'gaming', which is quite accurate. You just set up an official (shell) company and thus get official papers for it and with that you go to RIPE NCC (or any other RIR or LIR) and request a new chunk of address space just like every other organization is able to do. Nothing much that RIPE NCC can do about, as all the paperwork will check out just fine and they will generally even pay the fees as well, they are making money off it. [..] > My logs show that I get spam over IPv6, so some bad guys might be > already doing it. Spam will come over every path possible. If a compromised machine has IPv6, it will thus also come over IPv6 if your MXs are reachable over it. Just repeat: Long live SpamAssassin ;) Greets, Jeroen From jabley at hopcount.ca Wed Oct 12 12:50:46 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 12 Oct 2011 13:50:46 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: On 2011-10-12, at 13:05, Leigh Porter wrote: > Email on my iPhone is working fine.. ;-) The blackberry message service is centralised with a lot of processing intelligence in the core. Messaging services that use the core as a simple transport and shift the processing intelligence to the edge have different, less-dramatic failure modes. No news, here. http://isen.com/stupid.html Joe From mksmith at adhost.com Wed Oct 12 13:00:28 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 12 Oct 2011 18:00:28 +0000 Subject: 2011.10.12 NANOG53 weds morning session notes In-Reply-To: References: Message-ID: <05F30649-866E-4240-8291-1D32151E681D@adhost.com> And as always, thank you Matt for taking the time and effort to do all of this work to provide a great service to the community. Thanks again, Mike On Oct 12, 2011, at 11:46 AM, Matthew Petach wrote: > Wow. As always, Geoff Huston really knows > how to deliver a message in a way that just > reaches right out and grabs you; awesome, awesome > keynote talk, that's going to be another one for > the archives. ^_^ > > Notes from this morning's session have been > posted to > http://kestrel3.netflight.com/2011.10.12-nanog53-morning-session.txt > > Thanks again to all the speakers for a great > conference--see you all in San Diego!! > > Matt > -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From carlosm3011 at gmail.com Wed Oct 12 13:09:54 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 12 Oct 2011 16:09:54 -0200 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: I've always believed that RIM's decision to implement email and other services in this way was a very poor choice that at some point would blow up in their faces. My evil half would say that is was a marketer's rather than an engineer's decision. It's one thing when you are basically the only game in town (as RIM was a few years ago), now it's a completely different scenario. RIM already faces a complicated playground. More high-profile incidents like this one and suddenly people start losing confidence in the service... one thing leads to another... then suddenly you're target for acquisition by a huge corporation. Then things look up again but exactly one year later that huge corporation buries everything you did and you're a page in a history book :-) Good luck to them, Carlos On Wed, Oct 12, 2011 at 3:50 PM, Joe Abley wrote: > > On 2011-10-12, at 13:05, Leigh Porter wrote: > >> Email on my iPhone is working fine.. ;-) > > The blackberry message service is centralised with a lot of processing intelligence in the core. Messaging services that use the core as a simple transport and shift the processing intelligence to the edge have different, less-dramatic failure modes. > > No news, here. http://isen.com/stupid.html > > > Joe > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From zachary.mcgibbon+nanog at gmail.com Wed Oct 12 15:10:08 2011 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 12 Oct 2011 16:10:08 -0400 Subject: Apple updates - Affect on network Message-ID: With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big increase on one of our links to our ISP at 1pm Eastern. Did anyone else notice significant traffic jumps on their networks? [image: image.png] -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 61651 bytes Desc: not available URL: From rvandolson at esri.com Wed Oct 12 15:20:28 2011 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 12 Oct 2011 13:20:28 -0700 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: <20111012202027.GA29587@esri.com> On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: > With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big > increase on one of our links to our ISP at 1pm Eastern. > > Did anyone else notice significant traffic jumps on their networks? That's an impressive jump. Do you have some netflow data showing the target subnets that were being hit? Ray From carlos at race.com Wed Oct 12 15:56:23 2011 From: carlos at race.com (Carlos Alcantar) Date: Wed, 12 Oct 2011 20:56:23 +0000 Subject: Apple updates - Affect on network In-Reply-To: <20111012202027.GA29587@esri.com> Message-ID: Has anyone else bricked there phone doing the iOS 5 update. I just ran mine in the middle of the update I got a 3004 error doing some research that error means can't connect to gs.apple.com I'm guessing that?s there upgrade server. So right now I'm SOL till I can connect to the update server. Looking on twitter it looks like I'm not the only person that has gotten this. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / www.race.com On 10/12/11 1:20 PM, "Ray Van Dolson" wrote: >On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: >> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >> increase on one of our links to our ISP at 1pm Eastern. >> >> Did anyone else notice significant traffic jumps on their networks? > >That's an impressive jump. Do you have some netflow data showing the >target subnets that were being hit? > >Ray > > From paul at paulgraydon.co.uk Wed Oct 12 16:05:45 2011 From: paul at paulgraydon.co.uk (Paul) Date: Wed, 12 Oct 2011 11:05:45 -1000 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: <4E960129.8040005@paulgraydon.co.uk> There are a fair number of reports of Apple's update servers being down/intermittent. I imagine that's probably fairly inevitable on launch day. If people haven't already updated and are thinking about doing it, it's probably worth holding off a day or two just in case. Paul On 10/12/2011 10:56 AM, Carlos Alcantar wrote: > Has anyone else bricked there phone doing the iOS 5 update. I just ran > mine in the middle of the update I got a 3004 error doing some research > that error means can't connect to gs.apple.com I'm guessing that?s there > upgrade server. So right now I'm SOL till I can connect to the update > server. Looking on twitter it looks like I'm not the only person that has > gotten this. > > Carlos Alcantar > Race Communications / Race Team Member > 101 Haskins Way, So. San Francisco, CA. 94080 > Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / > www.race.com > > > > > > On 10/12/11 1:20 PM, "Ray Van Dolson" wrote: > >> On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: >>> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >>> increase on one of our links to our ISP at 1pm Eastern. >>> >>> Did anyone else notice significant traffic jumps on their networks? >> That's an impressive jump. Do you have some netflow data showing the >> target subnets that were being hit? >> >> Ray >> >> > From jmamodio at gmail.com Wed Oct 12 16:20:39 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 12 Oct 2011 16:20:39 -0500 Subject: Apple updates - Affect on network In-Reply-To: References: <20111012202027.GA29587@esri.com> Message-ID: I didn't have issues downloading the update, it took less than 10min, but I've so many apps and stuff on a 32GB iPod that the process of backing up, upgrade, restore, somewhere in the middle you have to confirm some settings and backing up the apps for which I still I see 23 pending updates I guess due the new version of iOS is kind of tedious, iTunes does not provide much information besides a dialog box saying "Restoring iPod apps", but the iPod is not with the classic "syncing" message, on the iPod I can see the icons for the apps being restored showing up one by one. Besides connectivity problems and latency, the whole process seems to take a lot of time, so be patient and plan to see your iGadget coming back to live slowly. -J On Wed, Oct 12, 2011 at 3:56 PM, Carlos Alcantar wrote: > Has anyone else bricked there phone doing the iOS 5 update. ?I just ran > mine in the middle of the update I got a 3004 error doing some research > that error means can't connect to gs.apple.com I'm guessing that?s there > upgrade server. ?So right now I'm SOL till I can connect to the update > server. ?Looking on twitter it looks like I'm not the only person that has > gotten this. > > Carlos Alcantar > Race Communications / Race Team Member > 101 Haskins Way, So. San Francisco, CA. 94080 > Phone: +1 415 376 3314 ?Fax: ?+1 650 246 8901 / carlos *at* race.com / > www.race.com > > > > > > On 10/12/11 1:20 PM, "Ray Van Dolson" wrote: > >>On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: >>> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >>> increase on one of our links to our ISP at 1pm Eastern. >>> >>> Did anyone else notice significant traffic jumps on their networks? >> >>That's an impressive jump. ?Do you have some netflow data showing the >>target subnets that were being hit? >> >>Ray >> >> > > > From ryan at deadfrog.net Wed Oct 12 16:25:57 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 12 Oct 2011 16:25:57 -0500 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: <681D0829-D535-4EB0-8E26-634DFE6AEA2A@deadfrog.net> Have you previously run TinyUmbrella? It has been known to set gs.apple.com to a cydia server in the local hosts file which would return an error. Or it could be gs is overloaded or down. Regards, Ryan Wilkins On Oct 12, 2011, at 3:56 PM, Carlos Alcantar wrote: > Has anyone else bricked there phone doing the iOS 5 update. I just ran > mine in the middle of the update I got a 3004 error doing some research > that error means can't connect to gs.apple.com I'm guessing that?s there > upgrade server. So right now I'm SOL till I can connect to the update > server. Looking on twitter it looks like I'm not the only person that has > gotten this. > > Carlos Alcantar > Race Communications / Race Team Member > 101 Haskins Way, So. San Francisco, CA. 94080 > Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / > www.race.com > > > > > > On 10/12/11 1:20 PM, "Ray Van Dolson" wrote: > >> On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: >>> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >>> increase on one of our links to our ISP at 1pm Eastern. >>> >>> Did anyone else notice significant traffic jumps on their networks? >> >> That's an impressive jump. Do you have some netflow data showing the >> target subnets that were being hit? >> >> Ray >> >> > > From cburnham at du.edu Wed Oct 12 16:41:20 2011 From: cburnham at du.edu (Chad Burnham) Date: Wed, 12 Oct 2011 15:41:20 -0600 Subject: Apple updates - Effect on network Message-ID: HI, Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's traffic jumped significantly today. The theory (no data) is the Apple updates released today. Chad Burnham University of Denver -----Original Message----- From: Zachary McGibbon [mailto:zachary.mcgibbon+nanog at gmail.com] Sent: Wednesday, October 12, 2011 2:10 PM To: nanog at nanog.org Subject: Apple updates - Affect on network With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big increase on one of our links to our ISP at 1pm Eastern. Did anyone else notice significant traffic jumps on their networks? [image: image.png] . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5593 bytes Desc: not available URL: From jared at puck.nether.net Wed Oct 12 16:50:23 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 12 Oct 2011 17:50:23 -0400 Subject: Apple updates - Effect on network In-Reply-To: References: Message-ID: <46AFBD5C-9840-47B8-8351-A3B8B5D0120D@puck.nether.net> The simple updates for a single machine today range in the 700mb-1.5gb or more range 10.7.2+iTunes+one iOS image. With a variety of devices it could easily be 4gb+ per user. Many broadband users are seeing slow akamai speeds because of these updates. I've seen 2+ hour download times myself.... Jared Mauch On Oct 12, 2011, at 5:41 PM, Chad Burnham wrote: > HI, > > Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's traffic > jumped significantly today. The theory (no data) is the Apple updates > released today. > > Chad Burnham > University of Denver > > > -----Original Message----- > From: Zachary McGibbon [mailto:zachary.mcgibbon+nanog at gmail.com] > Sent: Wednesday, October 12, 2011 2:10 PM > To: nanog at nanog.org > Subject: Apple updates - Affect on network > > With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big > increase on one of our links to our ISP at 1pm Eastern. > > Did anyone else notice significant traffic jumps on their networks? > > [image: image.png] > > > > > > > > > > > > > > > > > > > > > > > . From jra at baylink.com Wed Oct 12 16:53:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Oct 2011 17:53:37 -0400 (EDT) Subject: L3 announces new peering policy Message-ID: <22797990.4880.1318456417706.JavaMail.root@benjamin.baylink.com> In the wake of their GBLX acquisition, Level 3 has announced (already) what its new peering policy will be, in this press release posted at Telecom Ramblings: http://newswire.telecomramblings.com/2011/10/level-3-announces-new-policy-for-internet-protocol-interconnection/ Cheers, -- j -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jmamodio at gmail.com Wed Oct 12 16:55:10 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 12 Oct 2011 16:55:10 -0500 Subject: Apple updates - Effect on network In-Reply-To: <46AFBD5C-9840-47B8-8351-A3B8B5D0120D@puck.nether.net> References: <46AFBD5C-9840-47B8-8351-A3B8B5D0120D@puck.nether.net> Message-ID: On top of all that add that there are many apps that have also been updated today to be in sync with new iOS features. -J On Wed, Oct 12, 2011 at 4:50 PM, Jared Mauch wrote: > The simple updates for a single machine today range in the 700mb-1.5gb or more range 10.7.2+iTunes+one iOS image. With a variety of devices it could easily be 4gb+ per user. Many broadband users are seeing slow akamai speeds because of these updates. I've seen 2+ hour download times myself.... > > Jared Mauch > > On Oct 12, 2011, at 5:41 PM, Chad Burnham wrote: > >> HI, >> >> Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's traffic >> jumped significantly today. ?The theory (no data) is the Apple updates >> released today. >> >> Chad Burnham >> University of Denver >> >> >> -----Original Message----- >> From: Zachary McGibbon [mailto:zachary.mcgibbon+nanog at gmail.com] >> Sent: Wednesday, October 12, 2011 2:10 PM >> To: nanog at nanog.org >> Subject: Apple updates - Affect on network >> >> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >> increase on one of our links to our ISP at 1pm Eastern. >> >> Did anyone else notice significant traffic jumps on their networks? > From regnauld at nsrc.org Wed Oct 12 17:02:40 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 13 Oct 2011 00:02:40 +0200 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> Message-ID: <20111012220240.GC30621@macbook.bluepipe.net> Joe Abley (jabley) writes: > > On 2011-10-12, at 13:05, Leigh Porter wrote: > > > Email on my iPhone is working fine.. ;-) > > The blackberry message service is centralised with a lot of processing intelligence in the core. Messaging services that use the core as a simple transport and shift the processing intelligence to the edge have different, less-dramatic failure modes. This is not the case for corporate customers with dedicated servers, AFAIU. P. From nanog at maunier.org Wed Oct 12 17:03:12 2011 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Thu, 13 Oct 2011 00:03:12 +0200 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: 2011/10/12 Zachary McGibbon > With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big > increase on one of our links to our ISP at 1pm Eastern. > > Did anyone else notice significant traffic jumps on their networks? > > [image: image.png] > On our side, Akamai is sending us 40% more traffic than yesterday at the same time. A traffic increase can be seen on Lonap exchange point ( http://www.lonap.net/bandwidth.shtml) -- Pierre-Yves Maunier -------------- next part -------------- A non-text attachment was scrubbed... Name: lonap-total-day.png Type: image/png Size: 4932 bytes Desc: not available URL: From jabley at hopcount.ca Wed Oct 12 17:06:17 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 12 Oct 2011 18:06:17 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <20111012220240.GC30621@macbook.bluepipe.net> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> Message-ID: On 2011-10-12, at 18:02, Phil Regnauld wrote: > Joe Abley (jabley) writes: >> >> On 2011-10-12, at 13:05, Leigh Porter wrote: >> >>> Email on my iPhone is working fine.. ;-) >> >> The blackberry message service is centralised with a lot of processing intelligence in the core. Messaging services that use the core as a simple transport and shift the processing intelligence to the edge have different, less-dramatic failure modes. > > This is not the case for corporate customers with dedicated servers, > AFAIU. I'm no expert, but my understanding is that at some/most/all traffic between handhelds and a BES, carried from the handheld device through a cellular network, still flows through RIM. Joe From regnauld at nsrc.org Wed Oct 12 17:40:49 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 13 Oct 2011 00:40:49 +0200 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> Message-ID: <20111012224049.GE30621@macbook.bluepipe.net> Joe Abley (jabley) writes: > > > This is not the case for corporate customers with dedicated servers, > > AFAIU. > > I'm no expert, but my understanding is that at some/most/all traffic between handhelds and a BES, carried from the handheld device through a cellular network, still flows through RIM. Correct - they need to transit at some point through the RIM servers. http://www.interworks.com/blogs/wlyles/2010/01/14/why-rim-outage-affects-users-corporate-bes That's just wrong on so many levels. Cheers, Phil From carlos at race.com Wed Oct 12 18:08:22 2011 From: carlos at race.com (Carlos Alcantar) Date: Wed, 12 Oct 2011 23:08:22 +0000 Subject: Apple updates - Affect on network In-Reply-To: <681D0829-D535-4EB0-8E26-634DFE6AEA2A@deadfrog.net> Message-ID: Ryan, Looks to have been the gs.apple.com was over loaded after about 30 attempts and 3 hrs it finally went through. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / http://www.race.com On 10/12/11 2:25 PM, "Ryan Wilkins" wrote: >Have you previously run TinyUmbrella? It has been known to set >gs.apple.com to a cydia server in the local hosts file which would return >an error. > >Or it could be gs is overloaded or down. > >Regards, >Ryan Wilkins > >On Oct 12, 2011, at 3:56 PM, Carlos Alcantar wrote: > >> Has anyone else bricked there phone doing the iOS 5 update. I just ran >> mine in the middle of the update I got a 3004 error doing some research >> that error means can't connect to gs.apple.com I'm guessing that?s there >> upgrade server. So right now I'm SOL till I can connect to the update >> server. Looking on twitter it looks like I'm not the only person that >>has >> gotten this. >> >> Carlos Alcantar >> Race Communications / Race Team Member >> 101 Haskins Way, So. San Francisco, CA. 94080 >> Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / >> www.race.com >> >> >> >> >> >> On 10/12/11 1:20 PM, "Ray Van Dolson" wrote: >> >>> On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote: >>>> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >>>> increase on one of our links to our ISP at 1pm Eastern. >>>> >>>> Did anyone else notice significant traffic jumps on their networks? >>> >>> That's an impressive jump. Do you have some netflow data showing the >>> target subnets that were being hit? >>> >>> Ray >>> >>> >> >> > From surfer at mauigateway.com Wed Oct 12 18:39:05 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Oct 2011 16:39:05 -0700 Subject: L3 announces new peering policy Message-ID: <20111012163905.F639CE32@resin16.mta.everyone.net> --- jra at baylink.com wrote: From: Jay Ashworth In the wake of their GBLX acquisition, Level 3 has announced (already) what its new peering policy will be, in this press release posted at Telecom Ramblings: http://newswire.telecomramblings.com/2011/10/level-3-announces-new-policy-for-internet-protocol-interconnection/ ----------------------------------------------------- Isn't it just more of the same, or am I brainnumb today? "...each party bears a reasonably equal share of backbone burdens ? taking into account the amount of traffic carried by each party and the distance over which that traffic is carried." "One fundamental aspect of the new policy is a requirement that carriers adjust routing practices and interconnection locations so that the distance and volume of traffic carried by each party on their backbone network remains equitable." "If one party to a settlement-free peering relationship is carrying far less traffic over far less distances than the other party, the policy would require changes to interconnection locations and routing to more equitably distribute the burden of carrying traffic and thus preserve a fair settlement-free peering relationship" Hopefully, I am not accidentally trolling as has happened in the past... :-) scott From jra at baylink.com Wed Oct 12 19:33:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Oct 2011 20:33:15 -0400 (EDT) Subject: TR: Will Sprint sell IP network to get cash to build out LTE? Message-ID: <6815708.4914.1318465995210.JavaMail.root@benjamin.baylink.com> Telecom Ramblings had another good piece this week, on who might buy Sprint's terrestrial division if they put it up for sale... http://www.telecomramblings.com/2011/10/where-sprint-is-going-to-get-the-cash Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From james at gitflorida.com Wed Oct 12 20:54:32 2011 From: james at gitflorida.com (James P. Ashton) Date: Wed, 12 Oct 2011 21:54:32 -0400 (EDT) Subject: Google Contact Message-ID: <20b08f38-e805-4fda-8b11-ba61bbc479ad@mail.gitflorida.com> Hello all, Can someone from Google, clue-full about the malware list, please contact me offlist. It appears that several customer servers have had their sites listed simply because they originate from our ASN. If anyone has any experience with this, thoughts and ideas are more than welcome. Thanks James From matt.addison at lists.evilgeni.us Wed Oct 12 21:40:28 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Wed, 12 Oct 2011 22:40:28 -0400 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: On Wed, Oct 12, 2011 at 16:10, Zachary McGibbon wrote: > With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big > increase on one of our links to our ISP at 1pm Eastern. > > Did anyone else notice significant traffic jumps on their networks? Saw a +300mbps (+150%) increase on my Akamai cluster ~1315 EDT. No appreciable increase on transit or peering. ~Matt From jra at baylink.com Wed Oct 12 22:09:29 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Oct 2011 23:09:29 -0400 (EDT) Subject: RIP dmr Message-ID: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> Oh, hell: http://boingboing.net/2011/10/12/dennis-ritchie-1941-2011-computer-scientist-unix-co-creator-c-co-inventor.html -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From ops.lists at gmail.com Wed Oct 12 22:24:46 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 13 Oct 2011 08:54:46 +0530 Subject: RIP dmr In-Reply-To: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> References: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Oct 13, 2011 at 8:39 AM, Jay Ashworth wrote: > > http://boingboing.net/2011/10/12/dennis-ritchie-1941-2011-computer-scientist-unix-co-creator-c-co-inventor.html A longer obituary thread for him than for steve jobs I think.? He deserves it. [and gmail wants me to "consider including Mikael Abrahamsson" on this thread, dont know whatever for] -- Suresh Ramasubramanian (ops.lists at gmail.com) From jbates at brightok.net Wed Oct 12 22:32:28 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Oct 2011 22:32:28 -0500 Subject: Apple updates - Affect on network In-Reply-To: References: Message-ID: <4E965BCC.8020305@brightok.net> On 10/12/2011 9:40 PM, Matt Addison wrote: > On Wed, Oct 12, 2011 at 16:10, Zachary McGibbon > wrote: >> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >> increase on one of our links to our ISP at 1pm Eastern. >> >> Did anyone else notice significant traffic jumps on their networks? > Saw a +300mbps (+150%) increase on my Akamai cluster ~1315 EDT. No > appreciable increase on transit or peering. > > Same. 165% increase to Akamai. Had a large spike 10/11, though not as much as 10/12. Jack From morrowc.lists at gmail.com Wed Oct 12 22:37:32 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Oct 2011 23:37:32 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <20111012224049.GE30621@macbook.bluepipe.net> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <20111012224049.GE30621@macbook.bluepipe.net> Message-ID: On Wed, Oct 12, 2011 at 6:40 PM, Phil Regnauld wrote: > ? ? ? ?Correct - they need to transit at some point through the RIM servers. > > ? ? ? ?http://www.interworks.com/blogs/wlyles/2010/01/14/why-rim-outage-affects-users-corporate-bes > > ? ? ? ?That's just wrong on so many levels. yet... people AND CORPORATIONS still use them... Hrm, one wonders how plain-text-like the traffic is between endpoints? how much data is there that could be used to identify the endpoints? "Look, jabley's sure sending lots of traffic to capitan knight... maybe there's something going on in jabley-land?" just sayin'! From pf at tippete.net Wed Oct 12 23:23:26 2011 From: pf at tippete.net (Pierfrancesco Caci) Date: Thu, 13 Oct 2011 06:23:26 +0200 Subject: L3 announces new peering policy In-Reply-To: <22797990.4880.1318456417706.JavaMail.root@benjamin.baylink.com> References: <22797990.4880.1318456417706.JavaMail.root@benjamin.baylink.com> Message-ID: <34fac379-4cde-415a-9228-5ecbc8641a58@email.android.com> Jay Ashworth wrote: >In the wake of their GBLX acquisition, Level 3 has announced (already) >what >its new peering policy will be, in this press release posted at Telecom > >Ramblings: > >http://newswire.telecomramblings.com/2011/10/level-3-announces-new-policy-for-internet-protocol-interconnection/ Says all and nothing. -- Pierfrancesco Caci From shrdlu at deaddrop.org Wed Oct 12 23:32:37 2011 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 12 Oct 2011 21:32:37 -0700 Subject: RIP dmr In-Reply-To: References: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> Message-ID: <4E9669E5.3060005@deaddrop.org> I started with UNIX back when it arrived at school, on reel to reel tapes, and it was loaded on to the PDP 11/45. I learned to write C from the original K&R (which I still have, of course). Dennis was one of the good ones. A kind and generous person, who changed all our worlds. Rest In Peace From aoxomoxoa at sunlightdata.com Thu Oct 13 00:13:35 2011 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Wed, 12 Oct 2011 22:13:35 -0700 Subject: RIP dmr Message-ID: <201110130513.p9D5Dd2g049956@stark.hevanet.com> The UNIX Time-Sharing System http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf UNIX Time-Sharing System: A Retrospective http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1947.pdf UNIX Time-Sharing System: The C Programming Language http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1991.pdf From david at cantrell.org.uk Thu Oct 13 04:21:42 2011 From: david at cantrell.org.uk (David Cantrell) Date: Thu, 13 Oct 2011 10:21:42 +0100 Subject: Apple updates - Affect on network In-Reply-To: <4E960129.8040005@paulgraydon.co.uk> References: <4E960129.8040005@paulgraydon.co.uk> Message-ID: <20111013092142.GA22370@bytemark.barnyard.co.uk> On Wed, Oct 12, 2011 at 11:05:45AM -1000, Paul wrote: > There are a fair number of reports of Apple's update servers being > down/intermittent. I imagine that's probably fairly inevitable on > launch day. If people haven't already updated and are thinking about > doing it, it's probably worth holding off a day or two just in case. That's always worth doing anyway. Let the early adopters test it first for you! -- David Cantrell | Cake Smuggler Extraordinaire You can't spell AWESOME without ME! From jamie at photon.com Thu Oct 13 06:36:11 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 13 Oct 2011 07:36:11 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> Message-ID: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> You are correct. The BES uses PSKs to talk to RIM's servers, which then uses them to talk to the devices over the carrier networks. All of this was in complete failure mode until sometime overnight when it appears to have all started flowing again. Someday either Google or Apple will get off their rear ends and roll out an end to end encrypted service that plugs into corporate email/calendar/workgroup services and we can all gladly toss these horrid little devices in the recycle bins where they belong. Jamie > -----Original Message----- > From: Joe Abley [mailto:jabley at hopcount.ca] > Sent: Wednesday, October 12, 2011 6:06 PM > To: Phil Regnauld > Cc: nanog at nanog.org > Subject: Re: [outages] News item: Blackberry services down worldwide > > > On 2011-10-12, at 18:02, Phil Regnauld wrote: > > > Joe Abley (jabley) writes: > >> > >> On 2011-10-12, at 13:05, Leigh Porter wrote: > >> > >>> Email on my iPhone is working fine.. ;-) > >> > >> The blackberry message service is centralised with a lot of > processing intelligence in the core. Messaging services that use the > core as a simple transport and shift the processing intelligence to the > edge have different, less-dramatic failure modes. > > > > This is not the case for corporate customers with dedicated > servers, > > AFAIU. > > I'm no expert, but my understanding is that at some/most/all traffic > between handhelds and a BES, carried from the handheld device through a > cellular network, still flows through RIM. > > > Joe From carlosm3011 at gmail.com Thu Oct 13 06:52:27 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 13 Oct 2011 09:52:27 -0200 Subject: RIP dmr In-Reply-To: <201110130513.p9D5Dd2g049956@stark.hevanet.com> References: <201110130513.p9D5Dd2g049956@stark.hevanet.com> Message-ID: He will be sadly missed. On Thu, Oct 13, 2011 at 3:13 AM, Fred Heutte wrote: > > The UNIX Time-Sharing System > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf > > UNIX Time-Sharing System: A Retrospective > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1947.pdf > > UNIX Time-Sharing System: The C Programming Language > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1991.pdf > > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From akg1330 at gmail.com Thu Oct 13 07:42:03 2011 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 13 Oct 2011 08:42:03 -0400 Subject: Apple updates - Effect on network In-Reply-To: References: Message-ID: <4E96DC9B.7020201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/12/2011 5:41 PM, Chad Burnham wrote: > HI, > > Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's traffic > jumped significantly today. The theory (no data) is the Apple updates > released today. > > Chad Burnham > University of Denver > > > -----Original Message----- > From: Zachary McGibbon [mailto:zachary.mcgibbon+nanog at gmail.com] > Sent: Wednesday, October 12, 2011 2:10 PM > To: nanog at nanog.org > Subject: Apple updates - Affect on network > > With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big > increase on one of our links to our ISP at 1pm Eastern. > > Did anyone else notice significant traffic jumps on their networks? > > [image: image.png] > Yesterday, around 1PM ET, we saw a nearly 40% increase in inbound traffic, almost all from Akamai. It continued until around 2AM this morning, though, at one point, the traffic switched providers. Interestingly enough, we are peered directly with Akamai at Equnix- Ashburn, and at no point did this traffic use that link. Last time we saw such discrete large inbound flows was the World Cup. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOltybAAoJEBxhAh+LWUKil5UH/i1KvIWy7OrrKNhVjWFQ/VuH OUJg5hJFTns8wT8VkBLT0ANwODA4f8UI8AUJU6nhSeOPvHHor10gw9tytT6H5vh4 znDbxqVhOkCeSms+lKWiylKpVaLrenZ/L649as1ThkxZTogUhZfoRzbmQPJXXTw5 kTuwSrkPjOTmjJNffZ7bo7AvM/dyo56XI1TMsnCp3idRxpIGgvZZm0rlQ2GflVtj UhN205L+bLC0T4l1qZOYTs/62uZZLZn4Mb5aAp6kufzcfYIVi0RUqOwGjTYztfAe FytOdzQThZObQoHR253hov/Ogkf11+/vbP7gsGVd9kpjATVk4FbOM75vrcMGn9Q= =738W -----END PGP SIGNATURE----- From mhuff at ox.com Thu Oct 13 07:43:34 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 13 Oct 2011 08:43:34 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> It's called Microsoft Exchange ActiveSync :) It works with Android, Apple and Microsoft devices. I believe both Lotus and Groupwise have licensed and support it as well. We have a few (but now, very few) blackberry users remaining. They won't let it go until we rip it out of their hands. > -----Original Message----- > From: Jamie Bowden [mailto:jamie at photon.com] > Sent: Thursday, October 13, 2011 7:36 AM > To: Joe Abley > Cc: nanog at nanog.org > Subject: RE: [outages] News item: Blackberry services down worldwide > > You are correct. The BES uses PSKs to talk to RIM's servers, which then > uses them to talk to the devices over the carrier networks. All of this > was in complete failure mode until sometime overnight when it appears to > have all started flowing again. Someday either Google or Apple will get > off their rear ends and roll out an end to end encrypted service that > plugs into corporate email/calendar/workgroup services and we can all > gladly toss these horrid little devices in the recycle bins where they > belong. > > Jamie > > > -----Original Message----- > > From: Joe Abley [mailto:jabley at hopcount.ca] > > Sent: Wednesday, October 12, 2011 6:06 PM > > To: Phil Regnauld > > Cc: nanog at nanog.org > > Subject: Re: [outages] News item: Blackberry services down worldwide > > > > > > On 2011-10-12, at 18:02, Phil Regnauld wrote: > > > > > Joe Abley (jabley) writes: > > >> > > >> On 2011-10-12, at 13:05, Leigh Porter wrote: > > >> > > >>> Email on my iPhone is working fine.. ;-) > > >> > > >> The blackberry message service is centralised with a lot of > > processing intelligence in the core. Messaging services that use the > > core as a simple transport and shift the processing intelligence to > the > > edge have different, less-dramatic failure modes. > > > > > > This is not the case for corporate customers with dedicated > > servers, > > > AFAIU. > > > > I'm no expert, but my understanding is that at some/most/all traffic > > between handhelds and a BES, carried from the handheld device through > a > > cellular network, still flows through RIM. > > > > > > Joe From erik.soosalu at calyxinc.com Thu Oct 13 07:49:20 2011 From: erik.soosalu at calyxinc.com (Erik Soosalu) Date: Thu, 13 Oct 2011 08:49:20 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> Message-ID: <0B224A2FE01CC54C860290D42474BF600505AE9C@exchange.nff.local> Any idea of when Apple's ActiveSync Implementation will close the gap with what BES does? Like maybe having Important message notifications? Categories? Filters? I use an iPhone, but mail handling on it is lacking. -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Thursday, October 13, 2011 8:44 AM To: 'Jamie Bowden'; 'Joe Abley' Cc: 'nanog at nanog.org' Subject: RE: [outages] News item: Blackberry services down worldwide It's called Microsoft Exchange ActiveSync :) It works with Android, Apple and Microsoft devices. I believe both Lotus and Groupwise have licensed and support it as well. We have a few (but now, very few) blackberry users remaining. They won't let it go until we rip it out of their hands. > -----Original Message----- > From: Jamie Bowden [mailto:jamie at photon.com] > Sent: Thursday, October 13, 2011 7:36 AM > To: Joe Abley > Cc: nanog at nanog.org > Subject: RE: [outages] News item: Blackberry services down worldwide > > You are correct. The BES uses PSKs to talk to RIM's servers, which then > uses them to talk to the devices over the carrier networks. All of this > was in complete failure mode until sometime overnight when it appears to > have all started flowing again. Someday either Google or Apple will get > off their rear ends and roll out an end to end encrypted service that > plugs into corporate email/calendar/workgroup services and we can all > gladly toss these horrid little devices in the recycle bins where they > belong. > > Jamie > > > -----Original Message----- > > From: Joe Abley [mailto:jabley at hopcount.ca] > > Sent: Wednesday, October 12, 2011 6:06 PM > > To: Phil Regnauld > > Cc: nanog at nanog.org > > Subject: Re: [outages] News item: Blackberry services down worldwide > > > > > > On 2011-10-12, at 18:02, Phil Regnauld wrote: > > > > > Joe Abley (jabley) writes: > > >> > > >> On 2011-10-12, at 13:05, Leigh Porter wrote: > > >> > > >>> Email on my iPhone is working fine.. ;-) > > >> > > >> The blackberry message service is centralised with a lot of > > processing intelligence in the core. Messaging services that use the > > core as a simple transport and shift the processing intelligence to > the > > edge have different, less-dramatic failure modes. > > > > > > This is not the case for corporate customers with dedicated > > servers, > > > AFAIU. > > > > I'm no expert, but my understanding is that at some/most/all traffic > > between handhelds and a BES, carried from the handheld device through > a > > cellular network, still flows through RIM. > > > > > > Joe From blake at pfankuch.me Thu Oct 13 08:07:54 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Thu, 13 Oct 2011 13:07:54 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> Message-ID: Agreed. Had a customer during the timeframe of this week ditch 90 blackberries for iPhone/android devices. He actually sent me a video after BES finished uninstalling and he shut the server down "so help me I'm never getting another one of these damn coasters." One user said when they got the phone "where is the silly wheelie clicky thing." IT manager said "oh no you just touch the screen." I'm told it was like watching an 8 year old with a box of fireworks and matches.... For those who complain about security on windows mobile, iPhone or android... you can do l2tp vpn and then ActiveSync on top of that over https. Mobile device policies in Exchange for user experience control. Overall much easier than Blackberry, not dependent on someone else's equipment for things like mail delivery and internet browsing, and one less server to care about. -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Thursday, October 13, 2011 6:44 AM To: 'Jamie Bowden'; 'Joe Abley' Cc: 'nanog at nanog.org' Subject: RE: [outages] News item: Blackberry services down worldwide It's called Microsoft Exchange ActiveSync :) It works with Android, Apple and Microsoft devices. I believe both Lotus and Groupwise have licensed and support it as well. We have a few (but now, very few) blackberry users remaining. They won't let it go until we rip it out of their hands. > -----Original Message----- > From: Jamie Bowden [mailto:jamie at photon.com] > Sent: Thursday, October 13, 2011 7:36 AM > To: Joe Abley > Cc: nanog at nanog.org > Subject: RE: [outages] News item: Blackberry services down worldwide > > You are correct. The BES uses PSKs to talk to RIM's servers, which > then uses them to talk to the devices over the carrier networks. All > of this was in complete failure mode until sometime overnight when it > appears to have all started flowing again. Someday either Google or > Apple will get off their rear ends and roll out an end to end > encrypted service that plugs into corporate email/calendar/workgroup > services and we can all gladly toss these horrid little devices in the > recycle bins where they belong. > > Jamie > > > -----Original Message----- > > From: Joe Abley [mailto:jabley at hopcount.ca] > > Sent: Wednesday, October 12, 2011 6:06 PM > > To: Phil Regnauld > > Cc: nanog at nanog.org > > Subject: Re: [outages] News item: Blackberry services down worldwide > > > > > > On 2011-10-12, at 18:02, Phil Regnauld wrote: > > > > > Joe Abley (jabley) writes: > > >> > > >> On 2011-10-12, at 13:05, Leigh Porter wrote: > > >> > > >>> Email on my iPhone is working fine.. ;-) > > >> > > >> The blackberry message service is centralised with a lot of > > processing intelligence in the core. Messaging services that use the > > core as a simple transport and shift the processing intelligence to > the > > edge have different, less-dramatic failure modes. > > > > > > This is not the case for corporate customers with dedicated > > servers, > > > AFAIU. > > > > I'm no expert, but my understanding is that at some/most/all traffic > > between handhelds and a BES, carried from the handheld device > > through > a > > cellular network, still flows through RIM. > > > > > > Joe From robt at cymru.com Thu Oct 13 09:22:34 2011 From: robt at cymru.com (Rob Thomas) Date: Thu, 13 Oct 2011 10:22:34 -0400 Subject: RIP dmr In-Reply-To: <4E9669E5.3060005@deaddrop.org> References: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> <4E9669E5.3060005@deaddrop.org> Message-ID: <4E96F42A.2010604@cymru.com> > I started with UNIX back when it arrived at school, on reel to reel > tapes, and it was loaded on to the PDP 11/45. I learned to write C from > the original K&R (which I still have, of course). Same here! > Dennis was one of the good ones. A kind and generous person, who changed > all our worlds. Dennis always answered my email queries. I asked him all sorts of silly programming and Unix questions early in my career, and he patiently answered them all. I wouldn't have my career without both his contributions and his guidance. His memory is for blessing. -- Rob Thomas Team Cymru https://www.team-cymru.org/ "Say little and do much." M Avot 1:15 From matt at mt.au.com Thu Oct 13 09:24:31 2011 From: matt at mt.au.com (Matt Taylor) Date: Fri, 14 Oct 2011 01:24:31 +1100 Subject: Apple updates - Effect on network In-Reply-To: <4E96DC9B.7020201@gmail.com> References: <4E96DC9B.7020201@gmail.com> Message-ID: <4E96F49F.20904@mt.au.com> Would love to see some bandwidth graphs. :) Matt. On 13/10/2011 11:42 PM, Andrew Gallo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/12/2011 5:41 PM, Chad Burnham wrote: >> HI, >> >> Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's > traffic >> jumped significantly today. The theory (no data) is the Apple updates >> released today. >> >> Chad Burnham >> University of Denver >> >> >> -----Original Message----- >> From: Zachary McGibbon [mailto:zachary.mcgibbon+nanog at gmail.com] >> Sent: Wednesday, October 12, 2011 2:10 PM >> To: nanog at nanog.org >> Subject: Apple updates - Affect on network >> >> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big >> increase on one of our links to our ISP at 1pm Eastern. >> >> Did anyone else notice significant traffic jumps on their networks? >> >> [image: image.png] >> > > Yesterday, around 1PM ET, we saw a nearly 40% increase in inbound > traffic, almost all from Akamai. It continued until around 2AM this > morning, though, at one point, the traffic switched providers. > Interestingly enough, we are peered directly with Akamai at Equnix- > Ashburn, and at no point did this traffic use that link. > > Last time we saw such discrete large inbound flows was the World Cup. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOltybAAoJEBxhAh+LWUKil5UH/i1KvIWy7OrrKNhVjWFQ/VuH > OUJg5hJFTns8wT8VkBLT0ANwODA4f8UI8AUJU6nhSeOPvHHor10gw9tytT6H5vh4 > znDbxqVhOkCeSms+lKWiylKpVaLrenZ/L649as1ThkxZTogUhZfoRzbmQPJXXTw5 > kTuwSrkPjOTmjJNffZ7bo7AvM/dyo56XI1TMsnCp3idRxpIGgvZZm0rlQ2GflVtj > UhN205L+bLC0T4l1qZOYTs/62uZZLZn4Mb5aAp6kufzcfYIVi0RUqOwGjTYztfAe > FytOdzQThZObQoHR253hov/Ogkf11+/vbP7gsGVd9kpjATVk4FbOM75vrcMGn9Q= > =738W > -----END PGP SIGNATURE----- > > From p.lynch at netappliant.com Thu Oct 13 09:35:06 2011 From: p.lynch at netappliant.com (Pierce Lynch) Date: Thu, 13 Oct 2011 14:35:06 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> Message-ID: Like Blake mentioned, I for one will also be ditching Blackberry devices due to the poor, irregular service which Blackberry users continue to be subject to due to RIM's inability to provide a stable and reliable service. To add further insult to injury, it just simply is unacceptable to be subject to RIM's high service and licensing costs for BES to ultimately rely on a second-rate infrastructure that causes regular 'blackouts'. Time to more to a standalone device that then relies only on the carriers, which in most cases are just as unreliable. None the less, I for one can't justify paying for an 'enterprise service' to subject to incompetence and instability of the provider. These situations simply arise to often with RIM, yet as a service provider they chose to ignore that impact these outages have on their customers in the corporate arena. Real-time communications in the corporate/enterprise world have no become one of the primary methods of communication, due to the technology RIM et al offer. It is indeed a shame that the likes of Apple iOS & Google Android are yet to provide features that compete with BlackBerrys, such as encryption etc. (I am not particular clued up with regards to Windows Mobile however...) All of which, to date, are features which are leveraged in terms of justifying the cost of implementing a Blackberry solution. Furthermore, I found RIM's somewhat patronising updates from RIM's CIOs and CEOs quite insulting, particularly when an official statement had already been released stating the issues were 'resolved' to later contradict this statement and simple refer to it as some kind of 'mistake'. Unacceptable, as I am sure many of you would agree. Regards, P. -----Original Message----- From: Blake T. Pfankuch [mailto:blake at pfankuch.me] Sent: 13 October 2011 14:08 To: Matthew Huff; 'Jamie Bowden'; 'Joe Abley' Cc: 'nanog at nanog.org' Subject: RE: [outages] News item: Blackberry services down worldwide Agreed. Had a customer during the timeframe of this week ditch 90 blackberries for iPhone/android devices. He actually sent me a video after BES finished uninstalling and he shut the server down "so help me I'm never getting another one of these damn coasters." One user said when they got the phone "where is the silly wheelie clicky thing." IT manager said "oh no you just touch the screen." I'm told it was like watching an 8 year old with a box of fireworks and matches.... For those who complain about security on windows mobile, iPhone or android... you can do l2tp vpn and then ActiveSync on top of that over https. Mobile device policies in Exchange for user experience control. Overall much easier than Blackberry, not dependent on someone else's equipment for things like mail delivery and internet browsing, and one less server to care about. From asr at latency.net Thu Oct 13 09:54:58 2011 From: asr at latency.net (Adam Rothschild) Date: Thu, 13 Oct 2011 10:54:58 -0400 Subject: L3 announces new peering policy In-Reply-To: <20111012163905.F639CE32@resin16.mta.everyone.net> References: <20111012163905.F639CE32@resin16.mta.everyone.net> Message-ID: On Wed, Oct 12, 2011 at 7:39 PM, Scott Weeks wrote: > Isn't it just more of the same, or am I brainnumb today? What's changed is the introduction of "bit miles" as a means of calculating equality, where traffic ratios might previously have been used. Explained further, as pointed out on-list earlier: http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703819 http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703818 What will be interesting is whether new peering adjacencies crop up as a result of the new policy (I can think of several "smaller" global networks which now qualify, as it's written), or if this is just posturing on Level 3's part. The next few months will be interesting for sure... -a From jra at baylink.com Thu Oct 13 10:12:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Oct 2011 11:12:33 -0400 (EDT) Subject: RIP dmr In-Reply-To: <201110130513.p9D5Dd2g049956@stark.hevanet.com> Message-ID: <3171830.4950.1318518753294.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Fred Heutte" > The UNIX Time-Sharing System > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf > > UNIX Time-Sharing System: A Retrospective > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1947.pdf > > UNIX Time-Sharing System: The C Programming Language > http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1991.pdf Indeed: *the entire BSTJ* is available at that site as PDFs; kudos to the Alcatel-Lucent people who made that happen. Really big ones. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Thu Oct 13 10:13:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Oct 2011 11:13:57 -0400 (EDT) Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> Message-ID: <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jamie Bowden" > Someday either Google or Apple will get > off their rear ends and roll out an end to end encrypted service that > plugs into corporate email/calendar/workgroup services and we can all > gladly toss these horrid little devices in the recycle bins where they > belong. I'm fairly sure K-9 does GPG, at least for the email Cheers, -- jr 'just a doco writer' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From morrowc.lists at gmail.com Thu Oct 13 10:35:35 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Oct 2011 11:35:35 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Oct 13, 2011 at 11:13 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jamie Bowden" > >> Someday either Google or Apple will get >> off their rear ends and roll out an end to end encrypted service that >> plugs into corporate email/calendar/workgroup services and we can all >> gladly toss these horrid little devices in the recycle bins where they >> belong. > > I'm fairly sure K-9 does GPG, at least for the email plus normal mail + k9 will do TLS on SMTP and IMAP... or they both do with my mail server just fine. (idevices seeem to also do this well enough) It's possible that the 'encryption' comment from Jamie is really about encrypting the actual device... which I believe Android[0] will do, I don't know if idevices do though. -chris 0: From jared at puck.nether.net Thu Oct 13 10:56:29 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 13 Oct 2011 11:56:29 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> Message-ID: <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> On Oct 13, 2011, at 11:35 AM, Christopher Morrow wrote: > It's possible that the 'encryption' comment from Jamie is really about > encrypting the actual device... which I believe Android[0] will do, I > don't know if idevices do though. I think the big problem is that rev1 of iDevice did not include on-device crypto, and there was a case where they also 'lied' about their crypto capability to the servers. Rebuilding this trust can take some time. I do expect that with the iMessage stuff that was released yesterday (SMS/MMSoIP to email/phone#) many more companies will shift to using that instead as the value of BBM is decreased. I also wonder what the impact of iMessage and others will be on places like hotel networks as the devices camp out longer/more often on the wifi, etc. We observed the impact to a hotel of the NANOG crowd this week (i wonder if there will be lessons learned on the part of lodgenet, etc?) I know personally I've observed the attwifi ssid expanding to more places (including hilton branded properties) in the past 6 months to offload cellular data. - Jared From jamie at photon.com Thu Oct 13 10:55:49 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 13 Oct 2011 11:55:49 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> Message-ID: <275FEA2949B48341A3B46F424B613D857D8A@WDC-MX.photon.com> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Thursday, October 13, 2011 11:36 AM > To: Jay Ashworth > Cc: NANOG > Subject: Re: [outages] News item: Blackberry services down worldwide > > On Thu, Oct 13, 2011 at 11:13 AM, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Jamie Bowden" > > > >> Someday either Google or Apple will get > >> off their rear ends and roll out an end to end encrypted service > that > >> plugs into corporate email/calendar/workgroup services and we can > all > >> gladly toss these horrid little devices in the recycle bins where > they > >> belong. > > > > I'm fairly sure K-9 does GPG, at least for the email > > plus normal mail + k9 will do TLS on SMTP and IMAP... or they both do > with my mail server just fine. (idevices seeem to also do this well > enough) > > It's possible that the 'encryption' comment from Jamie is really about > encrypting the actual device... which I believe Android[0] will do, I > don't know if idevices do though. As of 2.3[.x?] (can't remember if it's a sub release that intro'd this), Android devices can be wholly encrypted, though I don't know if they are by default. All these kludges are great on a small scale, but the BES does end to end encryption for transmission, plugs into Exchange, Lotus, Sametime, proxies internal http[s], and lets us manage policies and push out software updates from a central management point. When it works, it's also scalable, which matters when you have thousands of devices to manage. Jamie From Ericneu at xbox.com Thu Oct 13 11:00:37 2011 From: Ericneu at xbox.com (Eric Neustadter (E)) Date: Thu, 13 Oct 2011 16:00:37 +0000 Subject: Xbox LIVE needs to talk to someone at the Time Warner Cable NOC Message-ID: We're seeing an outage that's confined to TWC users in Ohio. Could someone reach out to me or the Xbox Operations Center at xoc at microsoft.com? Thanks! [cid:image001.png at 01CC8986.927CD7E0] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 41819 bytes Desc: image001.png URL: From blake at pfankuch.me Thu Oct 13 11:47:41 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Thu, 13 Oct 2011 16:47:41 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> Message-ID: Pierce, Actually with Windows Mobile and Exchange Enterprise, you can force handheld encryption :) -----Original Message----- From: Pierce Lynch [mailto:p.lynch at netappliant.com] Sent: Thursday, October 13, 2011 8:35 AM To: 'nanog at nanog.org' Subject: RE: [outages] News item: Blackberry services down worldwide Like Blake mentioned, I for one will also be ditching Blackberry devices due to the poor, irregular service which Blackberry users continue to be subject to due to RIM's inability to provide a stable and reliable service. To add further insult to injury, it just simply is unacceptable to be subject to RIM's high service and licensing costs for BES to ultimately rely on a second-rate infrastructure that causes regular 'blackouts'. Time to more to a standalone device that then relies only on the carriers, which in most cases are just as unreliable. None the less, I for one can't justify paying for an 'enterprise service' to subject to incompetence and instability of the provider. These situations simply arise to often with RIM, yet as a service provider they chose to ignore that impact these outages have on their customers in the corporate arena. Real-time communications in the corporate/enterprise world have no become one of the primary methods of communication, due to the technology RIM et al offer. It is indeed a shame that the likes of Apple iOS & Google Android are yet to provide features that compete with BlackBerrys, such as encryption etc. (I am not particular clued up with regards to Windows Mobile however...) All of which, to date, are features which are leveraged in terms of justifying the cost of implementing a Blackberry solution. Furthermore, I found RIM's somewhat patronising updates from RIM's CIOs and CEOs quite insulting, particularly when an official statement had already been released stating the issues were 'resolved' to later contradict this statement and simple refer to it as some kind of 'mistake'. Unacceptable, as I am sure many of you would agree. Regards, P. -----Original Message----- From: Blake T. Pfankuch [mailto:blake at pfankuch.me] Sent: 13 October 2011 14:08 To: Matthew Huff; 'Jamie Bowden'; 'Joe Abley' Cc: 'nanog at nanog.org' Subject: RE: [outages] News item: Blackberry services down worldwide Agreed. Had a customer during the timeframe of this week ditch 90 blackberries for iPhone/android devices. He actually sent me a video after BES finished uninstalling and he shut the server down "so help me I'm never getting another one of these damn coasters." One user said when they got the phone "where is the silly wheelie clicky thing." IT manager said "oh no you just touch the screen." I'm told it was like watching an 8 year old with a box of fireworks and matches.... For those who complain about security on windows mobile, iPhone or android... you can do l2tp vpn and then ActiveSync on top of that over https. Mobile device policies in Exchange for user experience control. Overall much easier than Blackberry, not dependent on someone else's equipment for things like mail delivery and internet browsing, and one less server to care about. From mls at vp44.net Thu Oct 13 12:02:53 2011 From: mls at vp44.net (Andrea Gozzi) Date: Thu, 13 Oct 2011 19:02:53 +0200 Subject: NANOG:RE: [outages] News item: Blackberry services down worldwide In-Reply-To: <275FEA2949B48341A3B46F424B613D857D8A@WDC-MX.photon.com> Message-ID: Can't but agree with Jamie. The ability to centralize management for all Blackberry users and _force_ them to comply with company policy (it's an investment bank) saved us lot of hassle when, and it happens regularly, people lose their handsets. Otherwise, it would be all unencrypted, unmonitored and unprotected access points to customer's private data. Some of our representatives recently switched to iphones, but nobody from management will ever be allowed anything than a Blackberry. Andrea On 10/13/11 5:55 PM, "Jamie Bowden" wrote: > > >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Thursday, October 13, 2011 11:36 AM >> To: Jay Ashworth >> Cc: NANOG >> Subject: Re: [outages] News item: Blackberry services down worldwide >> >> On Thu, Oct 13, 2011 at 11:13 AM, Jay Ashworth >wrote: >> > ----- Original Message ----- >> >> From: "Jamie Bowden" >> > >> >> Someday either Google or Apple will get >> >> off their rear ends and roll out an end to end encrypted service >> that >> >> plugs into corporate email/calendar/workgroup services and we can >> all >> >> gladly toss these horrid little devices in the recycle bins where >> they >> >> belong. >> > >> > I'm fairly sure K-9 does GPG, at least for the email >> >> plus normal mail + k9 will do TLS on SMTP and IMAP... or they both do >> with my mail server just fine. (idevices seeem to also do this well >> enough) >> >> It's possible that the 'encryption' comment from Jamie is really about >> encrypting the actual device... which I believe Android[0] will do, I >> don't know if idevices do though. > >As of 2.3[.x?] (can't remember if it's a sub release that intro'd this), >Android devices can be wholly encrypted, though I don't know if they are >by default. All these kludges are great on a small scale, but the BES >does end to end encryption for transmission, plugs into Exchange, Lotus, >Sametime, proxies internal http[s], and lets us manage policies and push >out software updates from a central management point. When it works, >it's also scalable, which matters when you have thousands of devices to >manage. > >Jamie > > > From surfer at mauigateway.com Thu Oct 13 13:13:38 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 13 Oct 2011 11:13:38 -0700 Subject: L3 announces new peering policy Message-ID: <20111013111338.F6399612@resin16.mta.everyone.net> --- asr at latency.net wrote: From: Adam Rothschild On Wed, Oct 12, 2011 at 7:39 PM, Scott Weeks wrote: > Isn't it just more of the same, or am I brainnumb today? What's changed is the introduction of "bit miles" as a means of calculating equality, where traffic ratios might previously have been used. Explained further, as pointed out on-list earlier: http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703819 http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703818 What will be interesting is whether new peering adjacencies crop up as a result of the new policy (I can think of several "smaller" global networks which now qualify, as it's written), or if this is just posturing on Level 3's part. The next few months will be interesting for sure... ---------------------------------------------------- I do recall the bit-miles conversations, but didn't tie that into this. doh! Thanks for the links. That kind of detail is what I should've been looking for and it explains everything. scott From tvest at eyeconomics.com Thu Oct 13 13:19:31 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 13 Oct 2011 14:19:31 -0400 Subject: L3 announces new peering policy In-Reply-To: <20111013111338.F6399612@resin16.mta.everyone.net> References: <20111013111338.F6399612@resin16.mta.everyone.net> Message-ID: <7BCDDF17-74EC-4ECD-AC32-0E2D5FF7A0DC@eyeconomics.com> Note the distinction in the new peering relationship requirement -- only direct adjacencies with other transit-providing ASes count. ...or did that change happen some time ago and I'm just noticing it now (?) TV On Oct 13, 2011, at 2:13 PM, Scott Weeks wrote: > --- asr at latency.net wrote: > From: Adam Rothschild > > On Wed, Oct 12, 2011 at 7:39 PM, Scott Weeks wrote: >> Isn't it just more of the same, or am I brainnumb today? > > What's changed is the introduction of "bit miles" as a means of > calculating equality, where traffic ratios might previously have been > used. Explained further, as pointed out on-list earlier: > > http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703819 > http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703818 > > What will be interesting is whether new peering adjacencies crop up as > a result of the new policy (I can think of several "smaller" global > networks which now qualify, as it's written), or if this is just > posturing on Level 3's part. The next few months will be interesting > for sure... > ---------------------------------------------------- > > > > I do recall the bit-miles conversations, but didn't tie that into this. doh! Thanks for the links. That kind of detail is what I should've been looking for and it explains everything. > > scott > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1554 bytes Desc: not available URL: From patrick at ianai.net Thu Oct 13 13:22:01 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 13 Oct 2011 14:22:01 -0400 Subject: L3 announces new peering policy In-Reply-To: <7BCDDF17-74EC-4ECD-AC32-0E2D5FF7A0DC@eyeconomics.com> References: <20111013111338.F6399612@resin16.mta.everyone.net> <7BCDDF17-74EC-4ECD-AC32-0E2D5FF7A0DC@eyeconomics.com> Message-ID: <05A76F70-414F-419D-BD00-6BA9C86DAB90@ianai.net> On Oct 13, 2011, at 2:19 PM, Tom Vest wrote: > Note the distinction in the new peering relationship requirement -- only direct adjacencies with other transit-providing ASes count. > > ...or did that change happen some time ago and I'm just noticing it now (?) It is new. I'm unclear how that has anything to do with what they need as a business other than to carve out potential customers from the pool. Actually, we are all very clear.... -- TTFN, patrick > On Oct 13, 2011, at 2:13 PM, Scott Weeks wrote: > >> --- asr at latency.net wrote: >> From: Adam Rothschild >> >> On Wed, Oct 12, 2011 at 7:39 PM, Scott Weeks wrote: >>> Isn't it just more of the same, or am I brainnumb today? >> >> What's changed is the introduction of "bit miles" as a means of >> calculating equality, where traffic ratios might previously have been >> used. Explained further, as pointed out on-list earlier: >> >> http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703819 >> http://fjallfoss.fcc.gov/ecfs/document/view?id=7021703818 >> >> What will be interesting is whether new peering adjacencies crop up as >> a result of the new policy (I can think of several "smaller" global >> networks which now qualify, as it's written), or if this is just >> posturing on Level 3's part. The next few months will be interesting >> for sure... >> ---------------------------------------------------- >> >> >> >> I do recall the bit-miles conversations, but didn't tie that into this. doh! Thanks for the links. That kind of detail is what I should've been looking for and it explains everything. >> >> scott >> > From Jeff.Cartier at pernod-ricard.com Thu Oct 13 13:35:35 2011 From: Jeff.Cartier at pernod-ricard.com (Jeff Cartier) Date: Thu, 13 Oct 2011 18:35:35 +0000 Subject: OT: ISPs in Brazil and Chile Message-ID: <6EDE133FF50DBA4B963028BD5CD690DD368B24@CAPRGWLKWEMBX1.pernod-ricard.group> Hi Group, A little off topic, but I was looking for a recommendation on an ISP in both Brazil and Chile. Thanks!! __________________________________________________________________ DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. This message has been scanned for the presence of computer viruses, Spam, and Explicit Content. From mksmith at adhost.com Thu Oct 13 13:45:26 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 13 Oct 2011 18:45:26 +0000 Subject: NANOG Website and ARO Maintenance Message-ID: <34748BFD-A56D-42E9-AA5B-3B25B50B803D@adhost.com> Hello All: There will be maintenance performed to the NANOG Website and ARO system on Saturday, October 22, 2011, starting at 4 PM Pacific (2300 GMT) and lasting approximately 4 hours. During the window there will be brief periods where the website and ARO system are unavailable. Please note this outage will not affect any of the NANOG mailing lists. If you have any questions feel free to let me know. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From luispalmaster at gmail.com Thu Oct 13 13:50:39 2011 From: luispalmaster at gmail.com (Luis Palma) Date: Thu, 13 Oct 2011 15:50:39 -0300 Subject: OT: ISPs in Brazil and Chile In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD368B24@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD368B24@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: I work in Claro. Claro has ISP in both countries. If you need more information contact me off list. Regards 2011/10/13, Jeff Cartier : > Hi Group, > > A little off topic, but I was looking for a recommendation on an ISP in both > Brazil and Chile. > > Thanks!! > > __________________________________________________________________ > DISCLAIMER: This e-mail contains proprietary information some or all of > which may be legally privileged. It is for the intended recipient only. If > an addressing or transmission error has misdirected this e-mail, please > notify the author by replying to this e-mail. If you are not the intended > recipient you must not use, disclose, distribute, copy, print, or rely on > this e-mail. > > This message has been scanned for the presence of computer viruses, Spam, > and Explicit Content. > > -- Enviado desde mi dispositivo m?vil From Gabriel.McCall at thyssenkrupp.com Thu Oct 13 14:21:57 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Thu, 13 Oct 2011 15:21:57 -0400 Subject: NANOG:RE: [outages] News item: Blackberry services down worldwide In-Reply-To: References: Message-ID: ActiveSync on Android allows corporate to force compliance with security policy and allow remote wipe. User cannot complete the exchange account setup without permitting the controls. If the user doesn't agree their sync isn't enabled. Moreover, if corporate requirements change sync is disabled until you approve again. That seems like it covers all the bases to me. Sent from my Verizon Wireless Phone -----Original message----- From: Andrea Gozzi To: Jamie Bowden , Christopher Morrow , Jay Ashworth Cc: NANOG Sent: Thu, Oct 13, 2011 17:02:53 GMT+00:00 Subject: Re: NANOG:RE: [outages] News item: Blackberry services down worldwide Can't but agree with Jamie. The ability to centralize management for all Blackberry users and _force_ them to comply with company policy (it's an investment bank) saved us lot of hassle when, and it happens regularly, people lose their handsets. Otherwise, it would be all unencrypted, unmonitored and unprotected access points to customer's private data. Some of our representatives recently switched to iphones, but nobody from management will ever be allowed anything than a Blackberry. Andrea On 10/13/11 5:55 PM, "Jamie Bowden" wrote: > > >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Thursday, October 13, 2011 11:36 AM >> To: Jay Ashworth >> Cc: NANOG >> Subject: Re: [outages] News item: Blackberry services down worldwide >> >> On Thu, Oct 13, 2011 at 11:13 AM, Jay Ashworth >wrote: >> > ----- Original Message ----- >> >> From: "Jamie Bowden" >> > >> >> Someday either Google or Apple will get >> >> off their rear ends and roll out an end to end encrypted service >> that >> >> plugs into corporate email/calendar/workgroup services and we can >> all >> >> gladly toss these horrid little devices in the recycle bins where >> they >> >> belong. >> > >> > I'm fairly sure K-9 does GPG, at least for the email >> >> plus normal mail + k9 will do TLS on SMTP and IMAP... or they both do >> with my mail server just fine. (idevices seeem to also do this well >> enough) >> >> It's possible that the 'encryption' comment from Jamie is really about >> encrypting the actual device... which I believe Android[0] will do, I >> don't know if idevices do though. > >As of 2.3[.x?] (can't remember if it's a sub release that intro'd this), >Android devices can be wholly encrypted, though I don't know if they are >by default. All these kludges are great on a small scale, but the BES >does end to end encryption for transmission, plugs into Exchange, Lotus, >Sametime, proxies internal http[s], and lets us manage policies and push >out software updates from a central management point. When it works, >it's also scalable, which matters when you have thousands of devices to >manage. > >Jamie > > > From patrick at ianai.net Thu Oct 13 14:30:49 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 13 Oct 2011 15:30:49 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: Message-ID: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> On Oct 13, 2011, at 3:21 PM, McCall, Gabriel wrote: > ActiveSync on Android allows corporate to force compliance with security policy and allow remote wipe. User cannot complete the exchange account setup without permitting the controls. If the user doesn't agree their sync isn't enabled. Moreover, if corporate requirements change sync is disabled until you approve again. That seems like it covers all the bases to me. Same on iThings, plus SSL, wipe if 10 incorrect pass codes entered, enforcement of more than a 4-digit PIN pass code, auto-lock timeout, etc., etc. Any device that doesn't do this is likely old and / or going out of biz. I like Jared's attempt to bring this back on topic, though. :) So going down that path, exactly why is iMessage any different from Skype, AIM, Jabber, etc.? I mean other than likely being part of the OS / seamlessly integrated. (I haven't tried it yet, so I am just assuming Apple has done their standard UI magic on this.) In fact, Skype, just as a for instance, is worse on hotel wifi as launching the app on a laptop makes you a middle node for some conversations. Does Skype on $HANDHELD have the same property? -- TTFN, patrick > -----Original message----- > From: Andrea Gozzi > To: Jamie Bowden , Christopher Morrow , Jay Ashworth > Cc: NANOG > Sent: Thu, Oct 13, 2011 17:02:53 GMT+00:00 > Subject: Re: NANOG:RE: [outages] News item: Blackberry services down worldwide > > Can't but agree with Jamie. > The ability to centralize management for all Blackberry users and _force_ > them to comply with company policy (it's an investment bank) saved us lot > of hassle when, and it happens regularly, people lose their handsets. > Otherwise, it would be all unencrypted, unmonitored and unprotected access > points to customer's private data. > Some of our representatives recently switched to iphones, but nobody from > management will ever be allowed anything than a Blackberry. > > Andrea > > > On 10/13/11 5:55 PM, "Jamie Bowden" wrote: > >> >> >>> -----Original Message----- >>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>> Sent: Thursday, October 13, 2011 11:36 AM >>> To: Jay Ashworth >>> Cc: NANOG >>> Subject: Re: [outages] News item: Blackberry services down worldwide >>> >>> On Thu, Oct 13, 2011 at 11:13 AM, Jay Ashworth >> wrote: >>>> ----- Original Message ----- >>>>> From: "Jamie Bowden" >>>> >>>>> Someday either Google or Apple will get >>>>> off their rear ends and roll out an end to end encrypted service >>> that >>>>> plugs into corporate email/calendar/workgroup services and we can >>> all >>>>> gladly toss these horrid little devices in the recycle bins where >>> they >>>>> belong. >>>> >>>> I'm fairly sure K-9 does GPG, at least for the email >>> >>> plus normal mail + k9 will do TLS on SMTP and IMAP... or they both do >>> with my mail server just fine. (idevices seeem to also do this well >>> enough) >>> >>> It's possible that the 'encryption' comment from Jamie is really about >>> encrypting the actual device... which I believe Android[0] will do, I >>> don't know if idevices do though. >> >> As of 2.3[.x?] (can't remember if it's a sub release that intro'd this), >> Android devices can be wholly encrypted, though I don't know if they are >> by default. All these kludges are great on a small scale, but the BES >> does end to end encryption for transmission, plugs into Exchange, Lotus, >> Sametime, proxies internal http[s], and lets us manage policies and push >> out software updates from a central management point. When it works, >> it's also scalable, which matters when you have thousands of devices to >> manage. >> >> Jamie >> >> >> > > > > From scott at doc.net.au Thu Oct 13 16:42:00 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 13 Oct 2011 14:42:00 -0700 Subject: NANOG:RE: [outages] News item: Blackberry services down worldwide In-Reply-To: References: Message-ID: On Thu, Oct 13, 2011 at 12:21 PM, McCall, Gabriel < Gabriel.McCall at thyssenkrupp.com> wrote: > ActiveSync on Android allows corporate to force compliance with security > policy and allow remote wipe. User cannot complete the exchange account > setup without permitting the controls. If the user doesn't agree their sync > isn't enabled. Moreover, if corporate requirements change sync is disabled > until you approve again. That seems like it covers all the bases to me. > There's two key differences between ActiveSync and BES. The first is that ActiveSync implementations vary widely between different manufacturers/implementations/versions/etc. There is a core set of features that all manufacturers must implement, but it's a very small percentage of the full feature set of controls that ActiveSync supports. Things like enforcing a PIN code fit into this category, but other options like disabling the camera and (from memory) device encryption or even remote wipe are NOT in this category. As a result, even if you enable these features on your Exchange/ActiveSync server, you can't be sure that they are actually being enforced as you can't readily control which devices are being used with ActiveSync, and (realistically) you can't stop a user from changing devices so that even if you gave them a handset that supported all the features you wanted, they could simply move over to a new device that didn't. The second key difference is inbound v's outbound. ActiveSync requires you to allow connections into your network from outside, where BES doesn't. In todays world that's not really an issue - especially as most people will have their email servers accessible from the Internet in some way or other - but in BB's heyday this alone was one of the key differientators for Blackberry v's anything else (be that ActiveSync, POP/IMAP/etc, or any other protocols) With so many companies today working on the entire concept of Mobile Device Management (MDM), Blackberry will fade into insignificance in the not too distant future if they don't come out with something better than the competition - but even today they still allow far better control over handsets than ActiveSync alone does. Scott. From Vinny_Abello at Dell.com Thu Oct 13 16:58:33 2011 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 13 Oct 2011 21:58:33 +0000 Subject: NANOG:RE: [outages] News item: Blackberry services down worldwide In-Reply-To: References: Message-ID: Exchange administration is not my primary job, but in my past experience on Exchange and the iPhone, if I enforced a security policy that the phone could not meet then the user would not be able to sync with the server and setup their account. I remember having to tone back the security policy to a point where the iPhone would actually sync. So effectively they are enforced. You can also simply limit what ActiveSync devices are allowed. If you don't like iPhones but Android is ok, you can do that... at least in Exchange 2010 I can. -Vinny -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Thursday, October 13, 2011 5:42 PM To: McCall, Gabriel Cc: NANOG Subject: Re: NANOG:RE: [outages] News item: Blackberry services down worldwide On Thu, Oct 13, 2011 at 12:21 PM, McCall, Gabriel < Gabriel.McCall at thyssenkrupp.com> wrote: > ActiveSync on Android allows corporate to force compliance with security > policy and allow remote wipe. User cannot complete the exchange account > setup without permitting the controls. If the user doesn't agree their sync > isn't enabled. Moreover, if corporate requirements change sync is disabled > until you approve again. That seems like it covers all the bases to me. > There's two key differences between ActiveSync and BES. The first is that ActiveSync implementations vary widely between different manufacturers/implementations/versions/etc. There is a core set of features that all manufacturers must implement, but it's a very small percentage of the full feature set of controls that ActiveSync supports. Things like enforcing a PIN code fit into this category, but other options like disabling the camera and (from memory) device encryption or even remote wipe are NOT in this category. As a result, even if you enable these features on your Exchange/ActiveSync server, you can't be sure that they are actually being enforced as you can't readily control which devices are being used with ActiveSync, and (realistically) you can't stop a user from changing devices so that even if you gave them a handset that supported all the features you wanted, they could simply move over to a new device that didn't. The second key difference is inbound v's outbound. ActiveSync requires you to allow connections into your network from outside, where BES doesn't. In todays world that's not really an issue - especially as most people will have their email servers accessible from the Internet in some way or other - but in BB's heyday this alone was one of the key differientators for Blackberry v's anything else (be that ActiveSync, POP/IMAP/etc, or any other protocols) With so many companies today working on the entire concept of Mobile Device Management (MDM), Blackberry will fade into insignificance in the not too distant future if they don't come out with something better than the competition - but even today they still allow far better control over handsets than ActiveSync alone does. Scott. From graham at g-rock.net Thu Oct 13 17:40:20 2011 From: graham at g-rock.net (Graham Wooden) Date: Thu, 13 Oct 2011 17:40:20 -0500 Subject: [OT] Overture's Ethernet over bonded Copper products Message-ID: HI operators, Been looking at Overture?s ?Ethernet over Copper? product line; any you folks have any real world experience with them? Would love to hear off-line the good, bad, ugly stories ? if you are willing to share. Much appreciated. -graham From tshaw at oitc.com Thu Oct 13 17:40:54 2011 From: tshaw at oitc.com (TR Shaw) Date: Thu, 13 Oct 2011 18:40:54 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <0B224A2FE01CC54C860290D42474BF600505AE9C@exchange.nff.local> References: <625DBB8B2639984C8DA8F8EB45A39BB6064C97BA@neuman.orscheln.oi.local> <20111012220240.GC30621@macbook.bluepipe.net> <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <483E6B0272B0284BA86D7596C40D29F9012128D073C3@PUR-EXCH07.ox.com> <0B224A2FE01CC54C860290D42474BF600505AE9C@exchange.nff.local> Message-ID: I have been following this thread for a while and I will have to say I am a tad confused. Remote wipe has been in the iPhone since iOS3.1.3 And if your phone is locked it will wipe after 10 (if I remember correctly) failed unlock attempts. My iPhone communicates completely encrypted. It is set to VPN back to our office. And if we didn't wan't to do that we could could use TLS on our mail to keep that traffic encrypted. But encrypt all is the best approach for us. Personally, I hate mail push. I watch folks in meetings constantly looking down or typing some response and never fully listening to the speakers and not fully engaged in the meeting. Additionally, mail push is indiscriminate and just interrupts my train of thought when I am working. If a communique is truly important whomever can iMessage,SMS,jabber/POTS me; otherwise the mail can just wait till I check my inbox. I understand others feel differently. On an iPhone today you can get push from exchange, iCloud/iMap, Gmail/GCloud, Yahoo, OSX Server (I believe) or set your phone the check every x minutes (after all what could be so important that 15 latency minutes would cause a catastrophe? (During many catastrophe situations sms could take hours or the voice cell network could be tied up and are you that close to whatever to be able to react). If you need instant response... script it. As for filtering, its one of my issues about my iPhone. However, iOS5 supports message flagging and a filter script back on your desktop (where Mail does accept/process message push via IDLE) can flag a message which will sync to your iPhone. Lastly I have never liked RIM's model. It basically inculcates the idea that "man in the middle" is a good thing which it is not. Just my 2? Tom On Oct 13, 2011, at 8:49 AM, Erik Soosalu wrote: > Any idea of when Apple's ActiveSync Implementation will close the gap > with what BES does? > > Like maybe having Important message notifications? Categories? Filters? > > I use an iPhone, but mail handling on it is lacking. > > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Thursday, October 13, 2011 8:44 AM > To: 'Jamie Bowden'; 'Joe Abley' > Cc: 'nanog at nanog.org' > Subject: RE: [outages] News item: Blackberry services down worldwide > > It's called Microsoft Exchange ActiveSync :) > > It works with Android, Apple and Microsoft devices. I believe both Lotus > and Groupwise have licensed and support it as well. We have a few (but > now, very few) blackberry users remaining. They won't let it go until we > rip it out of their hands. > > > > >> -----Original Message----- >> From: Jamie Bowden [mailto:jamie at photon.com] >> Sent: Thursday, October 13, 2011 7:36 AM >> To: Joe Abley >> Cc: nanog at nanog.org >> Subject: RE: [outages] News item: Blackberry services down worldwide >> >> You are correct. The BES uses PSKs to talk to RIM's servers, which > then >> uses them to talk to the devices over the carrier networks. All of > this >> was in complete failure mode until sometime overnight when it appears > to >> have all started flowing again. Someday either Google or Apple will > get >> off their rear ends and roll out an end to end encrypted service that >> plugs into corporate email/calendar/workgroup services and we can all >> gladly toss these horrid little devices in the recycle bins where they >> belong. >> >> Jamie >> >>> -----Original Message----- >>> From: Joe Abley [mailto:jabley at hopcount.ca] >>> Sent: Wednesday, October 12, 2011 6:06 PM >>> To: Phil Regnauld >>> Cc: nanog at nanog.org >>> Subject: Re: [outages] News item: Blackberry services down worldwide >>> >>> >>> On 2011-10-12, at 18:02, Phil Regnauld wrote: >>> >>>> Joe Abley (jabley) writes: >>>>> >>>>> On 2011-10-12, at 13:05, Leigh Porter wrote: >>>>> >>>>>> Email on my iPhone is working fine.. ;-) >>>>> >>>>> The blackberry message service is centralised with a lot of >>> processing intelligence in the core. Messaging services that use the >>> core as a simple transport and shift the processing intelligence to >> the >>> edge have different, less-dramatic failure modes. >>>> >>>> This is not the case for corporate customers with dedicated >>> servers, >>>> AFAIU. >>> >>> I'm no expert, but my understanding is that at some/most/all traffic >>> between handhelds and a BES, carried from the handheld device > through >> a >>> cellular network, still flows through RIM. >>> >>> >>> Joe > > > > From matthew at matthew.at Thu Oct 13 18:26:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 13 Oct 2011 19:26:03 -0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> References: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> Message-ID: <4E97738B.1010508@matthew.at> On 10/13/11 3:30 PM, Patrick W. Gilmore wrote: > In fact, Skype, just as a for instance, is worse on hotel wifi as > launching the app on a laptop makes you a middle node for some > conversations. Per the Skype IT administrator guide, a Skype node will not become a supernode unless it has a public IP address and meets the memory, bandwidth, and uptime requirements. It will not become a relay node unless it has a public IP address and is directly reachable from the Internet. It is very unlikely that launching the Skype app on a laptop on hotel wi-fi would meet these requirements. > Does Skype on $HANDHELD have the same property? Not as far as I know, for the obvious reason that handheld devices have network connections that are suboptimal for this. Matthew Kaufman From ios.run at gmail.com Thu Oct 13 18:55:02 2011 From: ios.run at gmail.com (Raul Rodriguez) Date: Thu, 13 Oct 2011 16:55:02 -0700 Subject: [OT] Overture's Ethernet over bonded Copper products In-Reply-To: References: Message-ID: Can't speak to Overture, but at my last gig, Aktino/Positron gear worked well for us. -RR On 10/13/11, Graham Wooden wrote: > HI operators, > > Been looking at Overture?s ?Ethernet over Copper? product line; any you > folks have any real world experience with them? > Would love to hear off-line the good, bad, ugly stories ? if you are willing > to share. > > Much appreciated. > > -graham > > From shopik at inblock.ru Fri Oct 14 04:11:05 2011 From: shopik at inblock.ru (Nikolay Shopik) Date: Fri, 14 Oct 2011 13:11:05 +0400 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> Message-ID: On 13/10/11 19:56, Jared Mauch wrote: > Rebuilding this trust can take some time. I do expect that with the iMessage stuff that was released yesterday (SMS/MMSoIP to email/phone#) many more companies will shift to using that instead as the value of BBM is decreased. > > I also wonder what the impact of iMessage and others will be on places like hotel networks as the devices camp out longer/more often on the wifi, etc. We observed the impact to a hotel of the NANOG crowd this week (i wonder if there will be lessons learned on the part of lodgenet, etc?) If we talking about iMessage as replace of BBM, that's probably fine, but it's really niche market. I was really expecting them to release that stuff and allow desktop users to chat with idevice and making iMessage s2s(XMPP) compatible, so anyone could chat with idevice, even not supporting all fancy features, but at least dumb texting. From leigh.porter at ukbroadband.com Fri Oct 14 06:15:09 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 14 Oct 2011 11:15:09 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> Message-ID: > -----Original Message----- > From: Nikolay Shopik [mailto:shopik at inblock.ru] > Sent: 14 October 2011 10:17 > To: nanog at nanog.org > Subject: Re: [outages] News item: Blackberry services down worldwide > > On 13/10/11 19:56, Jared Mauch wrote: > > Rebuilding this trust can take some time. I do expect that with the > iMessage stuff that was released yesterday (SMS/MMSoIP to email/phone#) > many more companies will shift to using that instead as the value of > BBM is decreased. > > > > I also wonder what the impact of iMessage and others will be on > places like hotel networks as the devices camp out longer/more often on > the wifi, etc. We observed the impact to a hotel of the NANOG crowd > this week (i wonder if there will be lessons learned on the part of > lodgenet, etc?) > > If we talking about iMessage as replace of BBM, that's probably fine, > but it's really niche market. > I was really expecting them to release that stuff and allow desktop > users to chat with idevice and making iMessage s2s(XMPP) compatible, so > anyone could chat with idevice, even not supporting all fancy features, > but at least dumb texting. My iThings camp on WiFi all the time anyway as they are waiting for push updates, checking mail etc. Of course, all these little things add up and add to the total network traffic (and port counts for NAT)so they all take a toll on networks. I agree though, I would have liked to have seen iMessage cross platform. One of the great things about Skype is that I can talk from PeeCee to MAC to iThing to whatever.. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From rdobbins at arbor.net Fri Oct 14 10:36:39 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 14 Oct 2011 15:36:39 +0000 Subject: Request for participation - Arbor 2011 Worldwide Infrastructure Security Report. Message-ID: <962B2FBF-902A-437C-A240-8B2FBF3F4677@arbor.net> [Apologies if you've already seen this announcement in other forums.] Request for participation - Arbor 2011 Worldwide Infrastructure Security Report. ----- Folks, We're in the process of collecting survey responses for the 2011 Worldwide Infrastructure Security Report (WWISR); this is the Seventh Edition of the Report, and we'd really be grateful for your participation! This is the only security-focused survey we're aware of which is specifically oriented towards those who design, build, operate, and defend public-facing network infrastructure/applications/services, and provides an opportunity to share your experiences and perspectives with your peers within the operational community, as well as to benefit from their shared experiences and perspectives. The 2011 Infrastructure Security Survey is up and available for your input. You can register and complete the survey via this URL, which will redirect your browser to the survey tool (the survey itself is accessed via http/s): Once again, we've added several insightful questions from past participants. Survey collection will end as soon as we've reached the desired number of respondents (ideally, 100+). The survey results will be published in the 2011 Worldwide Infrastructure Security Report during January of 2012. Also, please note that *no* personally- or organizationally-identifiable information will be shared in any manner. The 2010 edition of the Report is available here (registration required): Thanks in advance! ----- ----------------------------------------------------------------------- Roland Dobbins // From woody at pch.net Fri Oct 14 10:43:59 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 14 Oct 2011 08:43:59 -0700 Subject: Request for participation - Arbor 2011 Worldwide Infrastructure Security Report. In-Reply-To: <962B2FBF-902A-437C-A240-8B2FBF3F4677@arbor.net> References: <962B2FBF-902A-437C-A240-8B2FBF3F4677@arbor.net> Message-ID: <7FD8AE5E-3D77-4A3E-A9A0-CEE66E920DD0@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Oct 14, 2011, at 8:36 AM, Dobbins, Roland wrote: > 404 The page you requested cannot be found. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJOmFi/AAoJEG+kcEsoi3+Hj9AQAJOCiaUek6VbEYNEZp3OBqvA RyjHmwEi13zGi+KNVpPdHd4ZfSadKJp4cBlmj22D+T4yXbm26HndJrdd7pA9RkhL NyLD3yfcRa5Gdw7G8Uz/e+3hYmgxtY2O1s+VkH5N5E6kpvHspZCVXDDIGlS3yWy+ lmqX+PMXEI2BAX8Ajtq6mS+iZMDeK+vb40NYgbkOlRWToiIRmxvh11EEIZEbszTO 7K0a1INDwcTKJGxKpXgkQx691zGWRMYOeNGCwGUazlsZcevCwbhBhn76SFJmkvuG N6iq/4umC+8VJfOOOzchzWZvK8p7vM6ivkL1Ebpn3+zx9BQgIl8buKd92UBr1t9g JKRALSe4z+4vpfUEFPvv9I0hl/TNVT6RqgABzXcMEipUbYAf/H+ewzg+qHfRqDSo usu2PHBg/0Vp20CZAXegM56OLY9w6vKOJRo3s0JF2vPo6w7mSGxdtkBmsRkm2YWd q6ibBRY6Ms7VyisutvNBLeOPsa7o9JjQi1DryYTlRkf8pSvyeQkxkOE6TlKcGJ1r QSMAsFZWh1AtYshR8KAEtUgSrISoQrAakAxdxLbpey0CqZ1NXOqkg79l6eAy9/X2 WBGJ+huOzk1QHYFKLBq53cpiLGUclMWT3W2w8xejUWxrrhQ+JtwbwhmUCGVKH7Ze swdI8Xl/mDsyvVIKshey =gK7i -----END PGP SIGNATURE----- From rdobbins at arbor.net Fri Oct 14 10:55:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 14 Oct 2011 15:55:00 +0000 Subject: Request for participation - Arbor 2011 Worldwide Infrastructure Security Report. In-Reply-To: <7FD8AE5E-3D77-4A3E-A9A0-CEE66E920DD0@pch.net> References: <962B2FBF-902A-437C-A240-8B2FBF3F4677@arbor.net> <7FD8AE5E-3D77-4A3E-A9A0-CEE66E920DD0@pch.net> Message-ID: On Oct 14, 2011, at 10:43 PM, Bill Woodcock wrote: > 404 I just saw that, thanks - it seems that DDoS attacks are comparatively easy to handle, compared to niggling little details such as URL redirects. ;> Apologies for the inconvenience, the link will be active RSN! ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Fri Oct 14 11:23:36 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 14 Oct 2011 16:23:36 +0000 Subject: Request for participation - Arbor 2011 Worldwide Infrastructure Security Report. In-Reply-To: <7FD8AE5E-3D77-4A3E-A9A0-CEE66E920DD0@pch.net> References: <962B2FBF-902A-437C-A240-8B2FBF3F4677@arbor.net> <7FD8AE5E-3D77-4A3E-A9A0-CEE66E920DD0@pch.net> Message-ID: On Oct 14, 2011, at 10:43 PM, Bill Woodcock wrote: > The page you requested cannot be found. Fixed, thanks! ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From millnert at gmail.com Fri Oct 14 13:48:01 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 14 Oct 2011 20:48:01 +0200 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> References: <275FEA2949B48341A3B46F424B613D857D89@WDC-MX.photon.com> <9342363.4952.1318518837983.JavaMail.root@benjamin.baylink.com> <32215884-DFDE-437B-A8B7-C95292BF6973@puck.nether.net> Message-ID: Jared, On Thu, Oct 13, 2011 at 5:56 PM, Jared Mauch wrote: > Rebuilding this trust can take some time. ?I do expect that with the iMessage stuff that was released yesterday (SMS/MMSoIP to email/phone#) many more companies will shift to using that instead as the value of BBM is decreased. With iMessage, Apple is following the lead of multi-platform apps such as Viber (integrated voice over ip) and whatsapp (integrated "rich" texting over ip). Integrated meaning the unique name/key registered in the system's name lookup service is your phone number, so you automagically discover who of all your address book entries have the application. Turning on whatsapp on my 360 contact address book yielded me 10% of my contact list *online* using it. :) Not being multi-vendor/platform, I wonder if iMessage on iPhone is going to reach similar uptake. Being installed from start certainly helps though, but not piggy backing on the phone numbers is a clear strategic error in my opinion (apple IDs are obviously a long long way from being as universal as phone numbers). I tried out whatsapp yesterday on an old Symbian S60 Nokia (N97) and it works great. Only thing I regret is not trying it out sooner. Now, if mobile devices only had ... globally unique and *reachable* IP addresses, you could even envision sending messages/pictures/video directly from your own device to a peer, with no need for bouncing through overloaded centralized bottlenecks, such as is the case with whatsapp (and certainly iMessage as well). There's certainly a business case in there for a legacy-free, bandwidth-optimized, IP only, LTE-network... (read: no [stupid] tunnels) > I also wonder what the impact of iMessage and others will be on places like hotel networks as the devices camp out longer/more often on the wifi, etc. ?We observed the impact to a hotel of the NANOG crowd this week (i wonder if there will be lessons learned on the part of lodgenet, etc?) > > I know personally I've observed the attwifi ssid expanding to more places (including hilton branded properties) in the past 6 months to offload cellular data. Offloading is wise, indeed. Cheers, Martin From carlos at race.com Fri Oct 14 14:04:44 2011 From: carlos at race.com (Carlos Alcantar) Date: Fri, 14 Oct 2011 19:04:44 +0000 Subject: [outages] News item: Blackberry services down worldwide In-Reply-To: Message-ID: What I'm not digging about the entire iMessage I turned off my iMessage option and someone else here in the office was trying to send me a txt. >From the looks of it the iPhone does not let you pick between wanting to send an iMessage or txt I could be wrong, but his phone was forcing iMessage and of course I was not getting the messages. Little bit of an issue not getting those messages. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / http://www.race.com On 10/14/11 11:48 AM, "Martin Millnert" wrote: >Jared, > >On Thu, Oct 13, 2011 at 5:56 PM, Jared Mauch >wrote: >> Rebuilding this trust can take some time. I do expect that with the >>iMessage stuff that was released yesterday (SMS/MMSoIP to email/phone#) >>many more companies will shift to using that instead as the value of BBM >>is decreased. > >With iMessage, Apple is following the lead of multi-platform apps such >as Viber (integrated voice over ip) and whatsapp (integrated "rich" >texting over ip). Integrated meaning the unique name/key registered in >the system's name lookup service is your phone number, so you >automagically discover who of all your address book entries have the >application. Turning on whatsapp on my 360 contact address book >yielded me 10% of my contact list *online* using it. :) > >Not being multi-vendor/platform, I wonder if iMessage on iPhone is >going to reach similar uptake. Being installed from start certainly >helps though, but not piggy backing on the phone numbers is a clear >strategic error in my opinion (apple IDs are obviously a long long way >from being as universal as phone numbers). > >I tried out whatsapp yesterday on an old Symbian S60 Nokia (N97) and >it works great. Only thing I regret is not trying it out sooner. > >Now, if mobile devices only had ... globally unique and *reachable* IP >addresses, you could even envision sending messages/pictures/video >directly from your own device to a peer, with no need for bouncing >through overloaded centralized bottlenecks, such as is the case with >whatsapp (and certainly iMessage as well). > >There's certainly a business case in there for a legacy-free, >bandwidth-optimized, IP only, LTE-network... (read: no [stupid] >tunnels) > > >> I also wonder what the impact of iMessage and others will be on places >>like hotel networks as the devices camp out longer/more often on the >>wifi, etc. We observed the impact to a hotel of the NANOG crowd this >>week (i wonder if there will be lessons learned on the part of lodgenet, >>etc?) >> >> I know personally I've observed the attwifi ssid expanding to more >>places (including hilton branded properties) in the past 6 months to >>offload cellular data. > >Offloading is wise, indeed. > > >Cheers, >Martin > > From patrick at ianai.net Fri Oct 14 14:11:15 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 14 Oct 2011 15:11:15 -0400 Subject: How Skype uses the network [was: News item: Blackberry services down worldwide] In-Reply-To: <4E97738B.1010508@matthew.at> References: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> <4E97738B.1010508@matthew.at> Message-ID: On Oct 13, 2011, at 7:26 PM, Matthew Kaufman wrote: > On 10/13/11 3:30 PM, Patrick W. Gilmore wrote: >> In fact, Skype, just as a for instance, is worse on hotel wifi as launching the app on a laptop makes you a middle node for some conversations. > > Per the Skype IT administrator guide, a Skype node will not become a supernode unless it has a public IP address and meets the memory, bandwidth, and uptime requirements. It will not become a relay node unless it has a public IP address and is directly reachable from the Internet. > > It is very unlikely that launching the Skype app on a laptop on hotel wi-fi would meet these requirements. In the last 5 seconds, without touching Skype or having any active voice or chat sessions open, my computer has had communication with 14 IP addresses. Here is a sample of some: TiggerAir-i7-2:~ patrick$ host 94.193.99.152 152.99.193.94.in-addr.arpa domain name pointer 94-193-99-152.zone7.bethere.co.uk. TiggerAir-i7-2:~ patrick$ host 78.90.137.244 Host 244.137.90.78.in-addr.arpa. not found: 3(NXDOMAIN) TiggerAir-i7-2:~ patrick$ host 175.129.63.150 150.63.129.175.in-addr.arpa domain name pointer KD175129063150.ppp-bb.dion.ne.jp. TiggerAir-i7-2:~ patrick$ host 218.190.29.244 Host 244.29.190.218.in-addr.arpa. not found: 3(NXDOMAIN) TiggerAir-i7-2:~ patrick$ host 128.2.238.215 215.238.2.128.in-addr.arpa domain name pointer ETC-NALZAYER.ETC.CMU.EDU. TiggerAir-i7-2:~ patrick$ host 212.187.172.66 Host 66.172.187.212.in-addr.arpa. not found: 3(NXDOMAIN) Those do not look like Skype servers. I guess it is possible everyone in my contact list is somehow pinging me, but that seems a little bit silly. My IP address is 172.30.19.19, hopefully I do not have to explain that this is not a "public IP address". I have been online a few minutes, so unless their uptime requirements are about the same as a regular phone call, it is too short. I will admit, I have plenty of bandwidth available, though. In short, while they can claim my laptop is not being used as a supernode or relay, Skype is still randomly talking to a slew of IP addresses. Anyone know what Skype is doing? >> Does Skype on $HANDHELD have the same property? > Not as far as I know, for the obvious reason that handheld devices have network connections that are suboptimal for this. The above happens to my laptop when I am on 3G / EDGE, even when I have a 10-net address. In fact, one of the first things I do on 3G is kill Skype because it noticeably increases my network performance. I haven't checked on my iPhone 'cause I don't have things like tcpdump & little snitch. -- TTFN, patrick From cb.list6 at gmail.com Fri Oct 14 14:17:41 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 14 Oct 2011 12:17:41 -0700 Subject: How Skype uses the network [was: News item: Blackberry services down worldwide] In-Reply-To: References: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> <4E97738B.1010508@matthew.at> Message-ID: On Fri, Oct 14, 2011 at 12:11 PM, Patrick W. Gilmore wrote: > On Oct 13, 2011, at 7:26 PM, Matthew Kaufman wrote: >> On 10/13/11 3:30 PM, Patrick W. Gilmore wrote: >>> In fact, Skype, just as a for instance, is worse on hotel wifi as launching the app on a laptop makes you a middle node for some conversations. >> >> Per the Skype IT administrator guide, a Skype node will not become a supernode unless it has a public IP address and meets the memory, bandwidth, and uptime requirements. It will not become a relay node unless it has a public IP address and is directly reachable from the Internet. >> >> It is very unlikely that launching the Skype app on a laptop on hotel wi-fi would meet these requirements. > > In the last 5 seconds, without touching Skype or having any active voice or chat sessions open, my computer has had communication with 14 IP addresses. ?Here is a sample of some: > > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 94.193.99.152 > ? ? ? ?152.99.193.94.in-addr.arpa domain name pointer 94-193-99-152.zone7.bethere.co.uk. > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 78.90.137.244 > ? ? ? ?Host 244.137.90.78.in-addr.arpa. not found: 3(NXDOMAIN) > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 175.129.63.150 > ? ? ? ?150.63.129.175.in-addr.arpa domain name pointer KD175129063150.ppp-bb.dion.ne.jp. > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 218.190.29.244 > ? ? ? ?Host 244.29.190.218.in-addr.arpa. not found: 3(NXDOMAIN) > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 128.2.238.215 > ? ? ? ?215.238.2.128.in-addr.arpa domain name pointer ETC-NALZAYER.ETC.CMU.EDU. > ? ? ? ?TiggerAir-i7-2:~ patrick$ host 212.187.172.66 > ? ? ? ?Host 66.172.187.212.in-addr.arpa. not found: 3(NXDOMAIN) > > Those do not look like Skype servers. ?I guess it is possible everyone in my contact list is somehow pinging me, but that seems a little bit silly. > > My IP address is 172.30.19.19, hopefully I do not have to explain that this is not a "public IP address". ?I have been online a few minutes, so unless their uptime requirements are about the same as a regular phone call, it is too short. ?I will admit, I have plenty of bandwidth available, though. > And, then there is the increasing prevalence of squat space which may muddy common heuristics. > In short, while they can claim my laptop is not being used as a supernode or relay, Skype is still randomly talking to a slew of IP addresses. ?Anyone know what Skype is doing? > > >>> Does Skype on $HANDHELD have the same property? >> Not as far as I know, for the obvious reason that handheld devices have network connections that are suboptimal for this. > > The above happens to my laptop when I am on 3G / EDGE, even when I have a 10-net address. ?In fact, one of the first things I do on 3G is kill Skype because it noticeably increases my network performance. > > I haven't checked on my iPhone 'cause I don't have things like tcpdump & little snitch. > > -- > TTFN, > patrick > > > From cscora at apnic.net Fri Oct 14 14:21:24 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Oct 2011 05:21:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Oct, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 377646 Prefixes after maximum aggregation: 169419 Deaggregation factor: 2.23 Unique aggregates announced to Internet: 184801 Total ASes present in the Internet Routing Table: 39069 Prefixes per ASN: 9.67 Origin-only ASes present in the Internet Routing Table: 32330 Origin ASes announcing only one prefix: 15494 Transit ASes present in the Internet Routing Table: 5223 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1442 Unregistered ASNs in the Routing Table: 793 Number of 32-bit ASNs allocated by the RIRs: 1853 Number of 32-bit ASNs visible in the Routing Table: 1516 Prefixes from 32-bit ASNs in the Routing Table: 3464 Special use prefixes present in the Routing Table: 8 Prefixes being announced from unallocated address space: 89 Number of addresses announced to Internet: 2483714272 Equivalent to 148 /8s, 10 /16s and 120 /24s Percentage of available address space announced: 67.0 Percentage of allocated address space announced: 67.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.5 Total number of prefixes smaller than registry allocations: 158719 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 94500 Total APNIC prefixes after maximum aggregation: 30930 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 90960 Unique aggregates announced from the APNIC address blocks: 37953 APNIC Region origin ASes present in the Internet Routing Table: 4582 APNIC Prefixes per ASN: 19.85 APNIC Region origin ASes announcing only one prefix: 1261 APNIC Region transit ASes present in the Internet Routing Table: 702 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 93 Number of APNIC addresses announced to Internet: 628403296 Equivalent to 37 /8s, 116 /16s and 172 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 145503 Total ARIN prefixes after maximum aggregation: 74267 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 117507 Unique aggregates announced from the ARIN address blocks: 47802 ARIN Region origin ASes present in the Internet Routing Table: 14725 ARIN Prefixes per ASN: 7.98 ARIN Region origin ASes announcing only one prefix: 5665 ARIN Region transit ASes present in the Internet Routing Table: 1559 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 804636672 Equivalent to 47 /8s, 245 /16s and 200 /24s Percentage of available ARIN address space announced: 63.9 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 90583 Total RIPE prefixes after maximum aggregation: 50537 RIPE Deaggregation factor: 1.79 Prefixes being announced from the RIPE address blocks: 83285 Unique aggregates announced from the RIPE address blocks: 53898 RIPE Region origin ASes present in the Internet Routing Table: 16041 RIPE Prefixes per ASN: 5.19 RIPE Region origin ASes announcing only one prefix: 7967 RIPE Region transit ASes present in the Internet Routing Table: 2509 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1068 Number of RIPE addresses announced to Internet: 490801024 Equivalent to 29 /8s, 65 /16s and 7 /24s Percentage of available RIPE address space announced: 79.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 34946 Total LACNIC prefixes after maximum aggregation: 7861 LACNIC Deaggregation factor: 4.45 Prefixes being announced from the LACNIC address blocks: 34338 Unique aggregates announced from the LACNIC address blocks: 17889 LACNIC Region origin ASes present in the Internet Routing Table: 1539 LACNIC Prefixes per ASN: 22.31 LACNIC Region origin ASes announcing only one prefix: 449 LACNIC Region transit ASes present in the Internet Routing Table: 280 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 339 Number of LACNIC addresses announced to Internet: 90805120 Equivalent to 5 /8s, 105 /16s and 147 /24s Percentage of available LACNIC address space announced: 60.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8488 Total AfriNIC prefixes after maximum aggregation: 2006 AfriNIC Deaggregation factor: 4.23 Prefixes being announced from the AfriNIC address blocks: 6576 Unique aggregates announced from the AfriNIC address blocks: 1966 AfriNIC Region origin ASes present in the Internet Routing Table: 486 AfriNIC Prefixes per ASN: 13.53 AfriNIC Region origin ASes announcing only one prefix: 152 AfriNIC Region transit ASes present in the Internet Routing Table: 105 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 27811072 Equivalent to 1 /8s, 168 /16s and 93 /24s Percentage of available AfriNIC address space announced: 41.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2500 11063 960 Korea Telecom (KIX) 17974 1937 519 33 PT TELEKOMUNIKASI INDONESIA 7545 1612 303 86 TPG Internet Pty Ltd 4755 1540 639 173 TATA Communications formerly 7552 1387 1064 7 Vietel Corporation 9829 1165 989 28 BSNL National Internet Backbo 9583 1087 80 503 Sify Limited 4808 1081 2100 308 CNCGROUP IP network: China169 24560 1018 342 229 Bharti Airtel Ltd., Telemedia 18101 952 165 142 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3547 3815 221 bellsouth.net, inc. 7029 2119 1016 197 Windstream Communications Inc 18566 2098 383 177 Covad Communications 1785 1836 680 121 PaeTec Communications, Inc. 4323 1631 1083 392 Time Warner Telecom 20115 1591 1541 635 Charter Communications 22773 1461 2907 100 Cox Communications, Inc. 19262 1395 4728 400 Verizon Global Networks 30036 1389 250 673 Mediacom Communications Corp 7018 1343 7079 850 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1455 352 13 Corbina telecom 6830 653 1927 415 UPC Distribution Services 34984 582 108 180 BILISIM TELEKOM 20940 544 183 418 Akamai Technologies European 3320 502 8169 384 Deutsche Telekom AG 3292 482 2082 408 TDC Tele Danmark 12479 482 593 7 Uni2 Autonomous System 8866 458 133 26 Bulgarian Telecommunication C 29049 424 31 55 AzerSat LLC. 8551 404 354 44 Bezeq International Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1681 310 155 TVCABLE BOGOTA 8151 1425 2861 349 UniNet S.A. de C.V. 28573 1376 1015 68 NET Servicos de Comunicao S.A 7303 1164 683 175 Telecom Argentina Stet-France 22047 580 322 17 VTR PUNTO NET S.A. 27947 578 72 83 Telconet S.A 6503 574 450 69 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 527 230 101 Empresa Nacional de Telecomun 11172 522 85 95 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 802 146 36 LINKdotNET AS number 8452 633 446 12 TEDATA 15475 444 74 8 Nile Online 36992 298 415 19 Etisalat MISR 3741 278 938 230 The Internet Solution 15706 244 32 6 Sudatel Internet Exchange Aut 6713 242 519 14 Itissalat Al-MAGHRIB 29571 217 17 13 Ci Telecom Autonomous system 33776 207 13 14 Starcomms Nigeria Limited 12258 198 28 58 Vodacom Internet Company Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3547 3815 221 bellsouth.net, inc. 4766 2500 11063 960 Korea Telecom (KIX) 7029 2119 1016 197 Windstream Communications Inc 18566 2098 383 177 Covad Communications 17974 1937 519 33 PT TELEKOMUNIKASI INDONESIA 1785 1836 680 121 PaeTec Communications, Inc. 10620 1681 310 155 TVCABLE BOGOTA 4323 1631 1083 392 Time Warner Telecom 7545 1612 303 86 TPG Internet Pty Ltd 20115 1591 1541 635 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 2119 1922 Windstream Communications Inc 18566 2098 1921 Covad Communications 17974 1937 1904 PT TELEKOMUNIKASI INDONESIA 1785 1836 1715 PaeTec Communications, Inc. 4766 2500 1540 Korea Telecom (KIX) 10620 1681 1526 TVCABLE BOGOTA 7545 1612 1526 TPG Internet Pty Ltd 8402 1455 1442 Corbina telecom 7552 1387 1380 Vietel Corporation 4755 1540 1367 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.80.0/24 30977 JSC "Yugra-Telecom" 128.0.81.0/24 30977 JSC "Yugra-Telecom" 128.0.82.0/24 30977 JSC "Yugra-Telecom" 128.0.83.0/24 30977 JSC "Yugra-Telecom" 128.0.84.0/24 30977 JSC "Yugra-Telecom" 128.0.85.0/24 30977 JSC "Yugra-Telecom" 128.0.86.0/24 30977 JSC "Yugra-Telecom" 128.0.87.0/24 30977 JSC "Yugra-Telecom" Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.rand.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:19 /9:12 /10:27 /11:81 /12:235 /13:464 /14:808 /15:1425 /16:11992 /17:6030 /18:10040 /19:19927 /20:27282 /21:27301 /22:36966 /23:35015 /24:196595 /25:1149 /26:1355 /27:745 /28:169 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2186 3547 bellsouth.net, inc. 18566 2047 2098 Covad Communications 7029 1806 2119 Windstream Communications Inc 10620 1576 1681 TVCABLE BOGOTA 8402 1432 1455 Corbina telecom 30036 1351 1389 Mediacom Communications Corp 11492 1115 1153 Cable One 1785 1056 1836 PaeTec Communications, Inc. 7011 1048 1166 Citizens Utilities 22773 949 1461 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:401 2:479 4:15 5:1 6:3 8:357 12:1954 13:1 14:541 15:11 16:3 17:7 20:9 23:58 24:1682 27:959 31:598 32:65 33:4 34:2 36:4 38:752 40:108 41:2630 42:50 44:3 46:990 47:3 49:268 50:447 52:13 55:6 56:2 57:37 58:876 59:493 60:364 61:1191 62:1093 63:1930 64:4103 65:2306 66:4255 67:1961 68:1156 69:3228 70:883 71:377 72:1863 74:2572 75:378 76:346 77:897 78:862 79:479 80:1124 81:825 82:500 83:536 84:637 85:1117 86:397 87:902 88:354 89:1590 90:269 91:4199 92:527 93:1512 94:1303 95:1046 96:438 97:283 98:908 99:37 101:214 103:359 106:70 107:66 108:54 109:1059 110:667 111:793 112:327 113:480 114:602 115:699 116:879 117:715 118:898 119:1240 120:339 121:693 122:1565 123:1032 124:1363 125:1385 128:256 129:178 130:166 131:587 132:121 133:21 134:218 135:54 136:213 137:139 138:289 139:120 140:488 141:294 142:389 143:428 144:493 145:63 146:473 147:215 148:635 149:258 150:164 151:192 152:448 153:178 154:7 155:387 156:207 157:359 158:151 159:476 160:321 161:214 162:339 163:175 164:509 165:364 166:536 167:435 168:745 169:145 170:872 171:85 172:4 173:1691 174:669 175:423 176:272 177:322 178:1054 180:1115 181:36 182:635 183:215 184:371 185:1 186:1284 187:666 188:928 189:850 190:5096 192:5905 193:5023 194:3544 195:3093 196:1235 197:169 198:3631 199:4152 200:5519 201:1655 202:8566 203:8477 204:4290 205:2366 206:2672 207:2821 208:4049 209:3594 210:2681 211:1454 212:2048 213:1768 214:796 215:90 216:4985 217:1617 218:561 219:336 220:1241 221:515 222:344 223:280 End of report From ml at kenweb.org Fri Oct 14 14:41:23 2011 From: ml at kenweb.org (ML) Date: Fri, 14 Oct 2011 15:41:23 -0400 Subject: Weekly Routing Table Report In-Reply-To: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> References: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> Message-ID: <4E989063.9010201@kenweb.org> On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote: > List of Unregistered Origin ASNs (Global) > ----------------------------------------- > > Bad AS Designation Network Transit AS Description > 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic > 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom > 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom > 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic > 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic > 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic > 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic > 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, > 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic > 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser > > Complete listing at http://thyme.rand.apnic.net/current/data-badAS > > Prefixes from private and non-routed address space (Global) > ----------------------------------------------------------- > > Prefix Origin AS Description > 128.0.80.0/24 30977 JSC "Yugra-Telecom" > 128.0.81.0/24 30977 JSC "Yugra-Telecom" > 128.0.82.0/24 30977 JSC "Yugra-Telecom" > 128.0.83.0/24 30977 JSC "Yugra-Telecom" > 128.0.84.0/24 30977 JSC "Yugra-Telecom" > 128.0.85.0/24 30977 JSC "Yugra-Telecom" > 128.0.86.0/24 30977 JSC "Yugra-Telecom" > 128.0.87.0/24 30977 JSC "Yugra-Telecom" > > Complete listing at http://thyme.rand.apnic.net/current/data-dsua > > Advertised Unallocated Addresses > -------------------------------- > > Network Origin AS Description > 24.225.128.0/18 36377 Comcast Telecommunications, I > 24.225.192.0/23 36377 Comcast Telecommunications, I > 24.225.192.0/18 36377 Comcast Telecommunications, I > 24.225.224.0/21 36377 Comcast Telecommunications, I > 24.225.237.0/24 36377 Comcast Telecommunications, I > 24.225.248.0/21 36377 Comcast Telecommunications, I > 41.222.79.0/24 36938>>UNKNOWN<< > 41.223.92.0/22 36936>>UNKNOWN<< > 62.61.220.0/24 24974 Tachyon Europe BV - Wireless > 62.61.221.0/24 24974 Tachyon Europe BV - Wireless > > Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Maybe I'm just not in the know on this but if these prefixes/ASes shouldn't be seen on the internet, shouldn't there be more of a public flogging to remove them? From scott at sberkman.net Fri Oct 14 15:45:45 2011 From: scott at sberkman.net (Scott Berkman) Date: Fri, 14 Oct 2011 16:45:45 -0400 Subject: [OT] Overture's Ethernet over bonded Copper products In-Reply-To: References: Message-ID: <00fc01cc8ab2$3fdcd2b0$bf967810$@sberkman.net> I've been working with them (it's really the Hatteras Networks products) since before the acquisition. I don't have much to compare to in terms of experience with the competing products, but I can tell you we've been very happy with the equipment, and I've heard lots of horror stories from Zhone customers. Hatteras' support was also phenomenal. I haven't seen any change yet since the acquisition except we have a different sales guy. The biggest challenge is that when dealing with 3rd party (iLEC) copper pairs, you really don't know what you are going to get until you turn up the circuit. There can also be a lot of fingerpointing when things break because the circuits you buy from the iLEC are generally cheap and don't have very high requirements for when the techs test and accept the circuit. Hope that helps, -Scott -----Original Message----- From: Graham Wooden [mailto:graham at g-rock.net] Sent: Thursday, October 13, 2011 6:40 PM To: nanog at nanog.org Subject: [OT] Overture's Ethernet over bonded Copper products HI operators, Been looking at Overture?s ?Ethernet over Copper? product line; any you folks have any real world experience with them? Would love to hear off-line the good, bad, ugly stories ? if you are willing to share. Much appreciated. -graham From cidr-report at potaroo.net Fri Oct 14 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Oct 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201110142200.p9EM01Hv002644@wattle.apnic.net> BGP Update Report Interval: 06-Oct-11 -to- 13-Oct-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 28719 2.0% 33.9 -- BSNL-NIB National Internet Backbone 2 - AS38040 27672 1.9% 5534.4 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS32528 25784 1.8% 6446.0 -- ABBOTT Abbot Labs 4 - AS6316 25314 1.8% 550.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - AS5800 22216 1.5% 111.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS14420 18751 1.3% 23.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS17974 18434 1.3% 11.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS9498 15367 1.1% 39.6 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS8402 14949 1.0% 19.7 -- CORBINA-AS OJSC "Vimpelcom" 10 - AS7552 13808 1.0% 10.2 -- VIETEL-AS-AP Vietel Corporation 11 - AS16916 11954 0.8% 1992.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 12 - AS9562 9855 0.7% 1407.9 -- MSU-TH-AP Mahasarakham University 13 - AS11492 9496 0.7% 17.8 -- CABLEONE - CABLE ONE, INC. 14 - AS51281 9415 0.7% 1569.2 -- COUNTRY-TELECOM-AS Country Telekom CJSC 15 - AS2856 9187 0.6% 48.4 -- BT-UK-AS BTnet UK Regional network 16 - AS9649 8844 0.6% 166.9 -- MOPH-TH-AP Information Technology Office 17 - AS24863 8809 0.6% 12.3 -- LINKdotNET-AS 18 - AS14522 8545 0.6% 24.6 -- Satnet 19 - AS8866 8160 0.6% 17.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 20 - AS27738 7865 0.5% 23.1 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 25784 1.8% 6446.0 -- ABBOTT Abbot Labs 2 - AS38040 27672 1.9% 5534.4 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS17408 3226 0.2% 3226.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 4 - AS16916 11954 0.8% 1992.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 5 - AS50660 1767 0.1% 1767.0 -- SSIF-CJ-AS SOCIETATE DE SERVICII DE INVESTITII FINANCIARE BROKER SA 6 - AS51281 9415 0.7% 1569.2 -- COUNTRY-TELECOM-AS Country Telekom CJSC 7 - AS17425 7412 0.5% 1482.4 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 8 - AS9562 9855 0.7% 1407.9 -- MSU-TH-AP Mahasarakham University 9 - AS10099 1036 0.1% 1036.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 10 - AS44025 1022 0.1% 1022.0 -- KAMTELEKOM-NET Kamtelekom Ltd. 11 - AS55696 1018 0.1% 1018.0 -- SCOM-AS-ID Starcom Solusindo PT. 12 - AS51966 873 0.1% 873.0 -- RESTENA-ANYCAST-AS Fondation RESTENA 13 - AS9168 769 0.1% 769.0 -- TELINO-AS Telino Network AS Number 14 - AS56903 754 0.1% 754.0 -- TELEMARKET-AS OOO TELEMARKET 15 - AS8011 3189 0.2% 637.8 -- AS8011 - CoreComm Internet Services Inc 16 - AS32777 2446 0.2% 611.5 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 17 - AS51372 605 0.0% 605.0 -- ORANGE-AS Orange Ltd. 18 - AS50733 552 0.0% 552.0 -- BINA-AS Ertebat Gostaran Bina 19 - AS6316 25314 1.8% 550.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS38528 497 0.0% 497.0 -- LANIC-AS-AP Lao National Internet Committee TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 14361 0.9% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 130.36.34.0/24 12843 0.8% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 12843 0.8% AS32528 -- ABBOTT Abbot Labs 4 - 206.80.93.0/24 11767 0.8% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 5 - 66.248.104.0/21 10830 0.7% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 66.248.120.0/21 10829 0.7% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 77.87.117.0/24 9388 0.6% AS51281 -- COUNTRY-TELECOM-AS Country Telekom CJSC 8 - 213.16.48.0/24 7142 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - 180.180.249.0/24 6299 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 10 - 180.180.255.0/24 5720 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 156.152.33.0/24 5512 0.3% AS71 -- HP-INTERNET-AS Hewlett-Packard Company 12 - 180.180.248.0/24 5219 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 13 - 180.180.253.0/24 5218 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 14 - 180.180.250.0/24 5216 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 15 - 66.248.96.0/21 3518 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - 202.153.174.0/24 3226 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 202.41.70.0/24 3108 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 18 - 202.151.7.0/24 2464 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 19 - 202.151.6.0/24 2463 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 20 - 202.151.5.0/24 2460 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Oct 14 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Oct 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201110142200.p9EM00ua002638@wattle.apnic.net> This report has been generated at Fri Oct 14 21:12:28 2011 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 07-10-11 378198 221965 08-10-11 378345 221799 09-10-11 378077 221883 10-10-11 377990 222159 11-10-11 378202 222087 12-10-11 378480 222395 13-10-11 379430 222520 14-10-11 379221 222643 AS Summary 39151 Number of ASes in routing system 16558 Number of ASes announcing only one prefix 3547 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108442592 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'). --- 14Oct11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 379814 222529 157285 41.4% All ASes AS6389 3547 224 3323 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2098 405 1693 80.7% COVAD - Covad Communications Co. AS4766 2500 980 1520 60.8% KIXS-AS-KR Korea Telecom AS22773 1461 110 1351 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1537 229 1308 85.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1632 395 1237 75.8% TWTC - tw telecom holdings, inc. AS1785 1839 784 1055 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1376 342 1034 75.1% NET Servicos de Comunicao S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1387 425 962 69.4% VIETEL-AS-AP Vietel Corporation AS10620 1681 748 933 55.5% Telmex Colombia S.A. AS7303 1164 321 843 72.4% Telecom Argentina S.A. AS18101 954 150 804 84.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1429 679 750 52.5% Uninet S.A. de C.V. AS4808 1081 340 741 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1389 678 711 51.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1612 934 678 42.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1936 1271 665 34.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3356 1102 450 652 59.2% LEVEL3 Level 3 Communications AS24560 1018 372 646 63.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8402 1450 823 627 43.2% CORBINA-AS OJSC "Vimpelcom" AS4804 714 94 620 86.8% MPX-AS Microplex PTY LTD AS3549 1052 444 608 57.8% GBLX Global Crossing Ltd. AS17676 675 70 605 89.6% GIGAINFRA Softbank BB Corp. AS7029 2160 1556 604 28.0% WINDSTREAM - Windstream Communications Inc AS22561 966 362 604 62.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS20115 1591 988 603 37.9% CHARTER-NET-HKY-NC - Charter Communications AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS7011 1166 644 522 44.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 889 393 496 55.8% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 43381 15644 27737 63.9% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 130.0.72.0/21 AS42442 ADACOR-AS Adacor Hosting GmbH 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 193.111.87.0/24 AS24812 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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.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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From matthew at matthew.at Fri Oct 14 17:19:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 14 Oct 2011 15:19:50 -0700 Subject: How Skype uses the network [was: News item: Blackberry services down worldwide] In-Reply-To: References: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> <4E97738B.1010508@matthew.at> Message-ID: <4E98B586.2040401@matthew.at> On 10/14/11 12:11 PM, Patrick W. Gilmore wrote: > Those do not look like Skype servers. I guess it is possible everyone in my contact list is somehow pinging me, but that seems a little bit silly. > How do you think peer-to-peer presence (online/away/do-not-disturb/offline) systems work? Matthew Kaufman From ben at bencarleton.com Fri Oct 14 17:58:07 2011 From: ben at bencarleton.com (Ben Carleton) Date: Fri, 14 Oct 2011 18:58:07 -0400 Subject: Cablevision residential ops? Message-ID: <4E98BE7F.2030800@bencarleton.com> Hi folks, Sorry to be a bother, but I'm wondering if there is a tech from Cablevision (Long Island, NY) on the list who can help me. We are unable to access websites that are using the CloudFlare service, and it looks to be an issue internal to Cablevision. I can provide a Traceroute showing where the packets are being stopped inside the CV network. Thanks! -- Ben From askoorb+nanog at gmail.com Sat Oct 15 08:17:54 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Sat, 15 Oct 2011 14:17:54 +0100 Subject: How Skype uses the network [was: News item: Blackberry services down worldwide] In-Reply-To: References: <74D764FE-586E-4CFC-AC94-AEC56101D57A@ianai.net> <4E97738B.1010508@matthew.at> Message-ID: Howdy, On Fri, Oct 14, 2011 at 8:11 PM, Patrick W. Gilmore wrote: > > On Oct 13, 2011, at 7:26 PM, Matthew Kaufman wrote: > > On 10/13/11 3:30 PM, Patrick W. Gilmore wrote: > >> In fact, Skype, just as a for instance, is worse on hotel wifi as launching the app on a laptop makes you a middle node for some conversations. > > > > Per the Skype IT administrator guide, a Skype node will not become a supernode unless it has a public IP address and meets the memory, bandwidth, and uptime requirements. It will not become a relay node unless it has a public IP address and is directly reachable from the Internet. > > > > It is very unlikely that launching the Skype app on a laptop on hotel wi-fi would meet these requirements. > > In the last 5 seconds, without touching Skype or having any active voice or chat sessions open, my computer has had communication with 14 IP addresses. ?Here is a sample of some: For "IT administrators" (which probably qualifies most people on this list) there is a?detailed?26 page guide to how Skype communicates on a network, when you may become a supernode, and how to configure the program (including to never become a supernode) using GPO (registry switches) or XML files at http://download.skype.com/share/business/guides/skype-it-administrators-guide.pdf. There is a summary of the Supernodes section (concentrating on how to stop supernodes happening if you have no control of the?client) at http://www.skype.com/intl/en-us/security/universities/. Anybody who might end up with Skyoe clients on their network might want to give it a gander, as it has some useful info on things like network impact (along with a lot of stuff that nobody cares about and you can skip). HTH, Alex From Allen.Sutton at CenturyLink.com Sat Oct 15 11:13:40 2011 From: Allen.Sutton at CenturyLink.com (Sutton, Allen) Date: Sat, 15 Oct 2011 11:13:40 -0500 Subject: [OT] Overture's Ethernet over bonded Copper products In-Reply-To: References: Message-ID: <748075CF27B6504182B8F3F8E23C2FA362ACA3BB91@PKDWES2V3.EQ.Intranet> We've used them extensively in our network for years (we have about 2,600 of them in the network). They actually used to be Ceterus devices (it's possible that Hatteras merged with Ceterus or something, but I'm not up on my vendor acquisition current events). We mostly use the UTS 810 and UTS-900 models. To be honest with you they work fine, but once something goes wrong, it's pretty bad because they are kind of flaky. We've had to simply reboot a lot of them to get the problem fixed, rather than actually figuring out what is really wrong with them and fixing that so it doesn't happen again. We get lots of trouble tickets for speed issues from customers who have them on their circuits, that's for sure. If I were you I'd probably go with Aktino products. We have a ton of those too, and I've never really had a problem with them. Thanks, _________________________________ Allen -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Friday, October 14, 2011 6:20 PM To: nanog at nanog.org Subject: NANOG Digest, Vol 45, Issue 46 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Weekly Routing Table Report (ML) 2. RE: [OT] Overture's Ethernet over bonded Copper products (Scott Berkman) 3. BGP Update Report (cidr-report at potaroo.net) 4. The Cidr Report (cidr-report at potaroo.net) 5. Re: How Skype uses the network [was: News item: Blackberry services down worldwide] (Matthew Kaufman) ---------------------------------------------------------------------- Message: 1 Date: Fri, 14 Oct 2011 15:41:23 -0400 From: ML To: nanog at nanog.org Subject: Re: Weekly Routing Table Report Message-ID: <4E989063.9010201 at kenweb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote: > List of Unregistered Origin ASNs (Global) > ----------------------------------------- > > Bad AS Designation Network Transit AS Description > 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic > 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom > 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom > 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic > 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic > 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic > 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic > 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, > 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic > 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser > > Complete listing at http://thyme.rand.apnic.net/current/data-badAS > > Prefixes from private and non-routed address space (Global) > ----------------------------------------------------------- > > Prefix Origin AS Description > 128.0.80.0/24 30977 JSC "Yugra-Telecom" > 128.0.81.0/24 30977 JSC "Yugra-Telecom" > 128.0.82.0/24 30977 JSC "Yugra-Telecom" > 128.0.83.0/24 30977 JSC "Yugra-Telecom" > 128.0.84.0/24 30977 JSC "Yugra-Telecom" > 128.0.85.0/24 30977 JSC "Yugra-Telecom" > 128.0.86.0/24 30977 JSC "Yugra-Telecom" > 128.0.87.0/24 30977 JSC "Yugra-Telecom" > > Complete listing at http://thyme.rand.apnic.net/current/data-dsua > > Advertised Unallocated Addresses > -------------------------------- > > Network Origin AS Description > 24.225.128.0/18 36377 Comcast Telecommunications, I > 24.225.192.0/23 36377 Comcast Telecommunications, I > 24.225.192.0/18 36377 Comcast Telecommunications, I > 24.225.224.0/21 36377 Comcast Telecommunications, I > 24.225.237.0/24 36377 Comcast Telecommunications, I > 24.225.248.0/21 36377 Comcast Telecommunications, I > 41.222.79.0/24 36938>>UNKNOWN<< > 41.223.92.0/22 36936>>UNKNOWN<< > 62.61.220.0/24 24974 Tachyon Europe BV - Wireless > 62.61.221.0/24 24974 Tachyon Europe BV - Wireless > > Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Maybe I'm just not in the know on this but if these prefixes/ASes shouldn't be seen on the internet, shouldn't there be more of a public flogging to remove them? ------------------------------ Message: 2 Date: Fri, 14 Oct 2011 16:45:45 -0400 From: "Scott Berkman" To: "'Graham Wooden'" , Subject: RE: [OT] Overture's Ethernet over bonded Copper products Message-ID: <00fc01cc8ab2$3fdcd2b0$bf967810$@sberkman.net> Content-Type: text/plain; charset="windows-1256" I've been working with them (it's really the Hatteras Networks products) since before the acquisition. I don't have much to compare to in terms of experience with the competing products, but I can tell you we've been very happy with the equipment, and I've heard lots of horror stories from Zhone customers. Hatteras' support was also phenomenal. I haven't seen any change yet since the acquisition except we have a different sales guy. The biggest challenge is that when dealing with 3rd party (iLEC) copper pairs, you really don't know what you are going to get until you turn up the circuit. There can also be a lot of fingerpointing when things break because the circuits you buy from the iLEC are generally cheap and don't have very high requirements for when the techs test and accept the circuit. Hope that helps, -Scott -----Original Message----- From: Graham Wooden [mailto:graham at g-rock.net] Sent: Thursday, October 13, 2011 6:40 PM To: nanog at nanog.org Subject: [OT] Overture's Ethernet over bonded Copper products HI operators, Been looking at Overture?s ?Ethernet over Copper? product line; any you folks have any real world experience with them? Would love to hear off-line the good, bad, ugly stories ? if you are willing to share. Much appreciated. -graham ------------------------------ Message: 3 Date: Fri, 14 Oct 2011 22:00:01 GMT From: cidr-report at potaroo.net To: cidr-report at potaroo.net Cc: nanog at nanog.org, routing-wg at ripe.net, ausnog at ausnog.net, apops at apops.net, eof-list at ripe.net, afnog at afnog.org Subject: BGP Update Report Message-ID: <201110142200.p9EM01Hv002644 at wattle.apnic.net> BGP Update Report Interval: 06-Oct-11 -to- 13-Oct-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 28719 2.0% 33.9 -- BSNL-NIB National Internet Backbone 2 - AS38040 27672 1.9% 5534.4 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS32528 25784 1.8% 6446.0 -- ABBOTT Abbot Labs 4 - AS6316 25314 1.8% 550.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - AS5800 22216 1.5% 111.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS14420 18751 1.3% 23.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS17974 18434 1.3% 11.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS9498 15367 1.1% 39.6 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS8402 14949 1.0% 19.7 -- CORBINA-AS OJSC "Vimpelcom" 10 - AS7552 13808 1.0% 10.2 -- VIETEL-AS-AP Vietel Corporation 11 - AS16916 11954 0.8% 1992.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 12 - AS9562 9855 0.7% 1407.9 -- MSU-TH-AP Mahasarakham University 13 - AS11492 9496 0.7% 17.8 -- CABLEONE - CABLE ONE, INC. 14 - AS51281 9415 0.7% 1569.2 -- COUNTRY-TELECOM-AS Country Telekom CJSC 15 - AS2856 9187 0.6% 48.4 -- BT-UK-AS BTnet UK Regional network 16 - AS9649 8844 0.6% 166.9 -- MOPH-TH-AP Information Technology Office 17 - AS24863 8809 0.6% 12.3 -- LINKdotNET-AS 18 - AS14522 8545 0.6% 24.6 -- Satnet 19 - AS8866 8160 0.6% 17.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 20 - AS27738 7865 0.5% 23.1 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 25784 1.8% 6446.0 -- ABBOTT Abbot Labs 2 - AS38040 27672 1.9% 5534.4 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS17408 3226 0.2% 3226.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 4 - AS16916 11954 0.8% 1992.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 5 - AS50660 1767 0.1% 1767.0 -- SSIF-CJ-AS SOCIETATE DE SERVICII DE INVESTITII FINANCIARE BROKER SA 6 - AS51281 9415 0.7% 1569.2 -- COUNTRY-TELECOM-AS Country Telekom CJSC 7 - AS17425 7412 0.5% 1482.4 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 8 - AS9562 9855 0.7% 1407.9 -- MSU-TH-AP Mahasarakham University 9 - AS10099 1036 0.1% 1036.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 10 - AS44025 1022 0.1% 1022.0 -- KAMTELEKOM-NET Kamtelekom Ltd. 11 - AS55696 1018 0.1% 1018.0 -- SCOM-AS-ID Starcom Solusindo PT. 12 - AS51966 873 0.1% 873.0 -- RESTENA-ANYCAST-AS Fondation RESTENA 13 - AS9168 769 0.1% 769.0 -- TELINO-AS Telino Network AS Number 14 - AS56903 754 0.1% 754.0 -- TELEMARKET-AS OOO TELEMARKET 15 - AS8011 3189 0.2% 637.8 -- AS8011 - CoreComm Internet Services Inc 16 - AS32777 2446 0.2% 611.5 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 17 - AS51372 605 0.0% 605.0 -- ORANGE-AS Orange Ltd. 18 - AS50733 552 0.0% 552.0 -- BINA-AS Ertebat Gostaran Bina 19 - AS6316 25314 1.8% 550.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS38528 497 0.0% 497.0 -- LANIC-AS-AP Lao National Internet Committee TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 14361 0.9% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 130.36.34.0/24 12843 0.8% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 12843 0.8% AS32528 -- ABBOTT Abbot Labs 4 - 206.80.93.0/24 11767 0.8% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 5 - 66.248.104.0/21 10830 0.7% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 66.248.120.0/21 10829 0.7% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 77.87.117.0/24 9388 0.6% AS51281 -- COUNTRY-TELECOM-AS Country Telekom CJSC 8 - 213.16.48.0/24 7142 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - 180.180.249.0/24 6299 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 10 - 180.180.255.0/24 5720 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 156.152.33.0/24 5512 0.3% AS71 -- HP-INTERNET-AS Hewlett-Packard Company 12 - 180.180.248.0/24 5219 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 13 - 180.180.253.0/24 5218 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 14 - 180.180.250.0/24 5216 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 15 - 66.248.96.0/21 3518 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - 202.153.174.0/24 3226 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 202.41.70.0/24 3108 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 18 - 202.151.7.0/24 2464 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 19 - 202.151.6.0/24 2463 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 20 - 202.151.5.0/24 2460 0.2% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org ------------------------------ Message: 4 Date: Fri, 14 Oct 2011 22:00:00 GMT From: cidr-report at potaroo.net To: cidr-report at potaroo.net Cc: apops at apops.net, afnog at afnog.org, nanog at nanog.org, eof-list at ripe.net, routing-wg at ripe.net Subject: The Cidr Report Message-ID: <201110142200.p9EM00ua002638 at wattle.apnic.net> This report has been generated at Fri Oct 14 21:12:28 2011 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 07-10-11 378198 221965 08-10-11 378345 221799 09-10-11 378077 221883 10-10-11 377990 222159 11-10-11 378202 222087 12-10-11 378480 222395 13-10-11 379430 222520 14-10-11 379221 222643 AS Summary 39151 Number of ASes in routing system 16558 Number of ASes announcing only one prefix 3547 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108442592 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'). --- 14Oct11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 379814 222529 157285 41.4% All ASes AS6389 3547 224 3323 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2098 405 1693 80.7% COVAD - Covad Communications Co. AS4766 2500 980 1520 60.8% KIXS-AS-KR Korea Telecom AS22773 1461 110 1351 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1537 229 1308 85.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1632 395 1237 75.8% TWTC - tw telecom holdings, inc. AS1785 1839 784 1055 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1376 342 1034 75.1% NET Servicos de Comunicao S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1387 425 962 69.4% VIETEL-AS-AP Vietel Corporation AS10620 1681 748 933 55.5% Telmex Colombia S.A. AS7303 1164 321 843 72.4% Telecom Argentina S.A. AS18101 954 150 804 84.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1429 679 750 52.5% Uninet S.A. de C.V. AS4808 1081 340 741 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1389 678 711 51.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1612 934 678 42.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1936 1271 665 34.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3356 1102 450 652 59.2% LEVEL3 Level 3 Communications AS24560 1018 372 646 63.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8402 1450 823 627 43.2% CORBINA-AS OJSC "Vimpelcom" AS4804 714 94 620 86.8% MPX-AS Microplex PTY LTD AS3549 1052 444 608 57.8% GBLX Global Crossing Ltd. AS17676 675 70 605 89.6% GIGAINFRA Softbank BB Corp. AS7029 2160 1556 604 28.0% WINDSTREAM - Windstream Communications Inc AS22561 966 362 604 62.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS20115 1591 988 603 37.9% CHARTER-NET-HKY-NC - Charter Communications AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS7011 1166 644 522 44.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 889 393 496 55.8% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 43381 15644 27737 63.9% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 130.0.72.0/21 AS42442 ADACOR-AS Adacor Hosting GmbH 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 193.111.87.0/24 AS24812 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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.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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org ------------------------------ Message: 5 Date: Fri, 14 Oct 2011 15:19:50 -0700 From: Matthew Kaufman To: "Patrick W. Gilmore" Cc: NANOG list Subject: Re: How Skype uses the network [was: News item: Blackberry services down worldwide] Message-ID: <4E98B586.2040401 at matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/14/11 12:11 PM, Patrick W. Gilmore wrote: > Those do not look like Skype servers. I guess it is possible everyone in my contact list is somehow pinging me, but that seems a little bit silly. > How do you think peer-to-peer presence (online/away/do-not-disturb/offline) systems work? Matthew Kaufman End of NANOG Digest, Vol 45, Issue 46 ************************************* From hank at efes.iucc.ac.il Sat Oct 15 11:42:17 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 15 Oct 2011 18:42:17 +0200 (IST) Subject: Weekly Routing Table Report In-Reply-To: <4E989063.9010201@kenweb.org> References: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> <4E989063.9010201@kenweb.org> Message-ID: On Fri, 14 Oct 2011, ML wrote: > On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote: >> List of Unregistered Origin ASNs (Global) >> ----------------------------------------- > Maybe I'm just not in the know on this but if these prefixes/ASes shouldn't > be seen on the internet, shouldn't there be more of a public flogging to > remove them? Been there. Done that. See from 2003: http://www.nanog.org/meetings/nanog27/presentations/hank.pdf I had been doing this for over a decade and gave up a few years ago. Bottom line: No one gives a sh*t. Consider it all part of the background noise the Internet generates. Regards, Hank From gih at apnic.net Sat Oct 15 06:23:55 2011 From: gih at apnic.net (Geoff Huston) Date: Sat, 15 Oct 2011 22:23:55 +1100 Subject: [routing-wg] The Cidr Report In-Reply-To: <201110142200.p9EM00ua002638@wattle.apnic.net> References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> From what I learned at the latest NANOG it's very clear that nobody reads this any more. Is there any good reason to persist in spamming the nanog list with this report? thanks, Geoff From gih at apnic.net Sat Oct 15 06:26:36 2011 From: gih at apnic.net (Geoff Huston) Date: Sat, 15 Oct 2011 22:26:36 +1100 Subject: [routing-wg] BGP Update Report In-Reply-To: <201110142200.p9EM01Hv002644@wattle.apnic.net> References: <201110142200.p9EM01Hv002644@wattle.apnic.net> Message-ID: While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? regards, Geoff From gih at apnic.net Sat Oct 15 14:25:58 2011 From: gih at apnic.net (Geoff Huston) Date: Sun, 16 Oct 2011 06:25:58 +1100 Subject: [routing-wg] The Cidr Report In-Reply-To: <201110142200.p9EM00ua002638@wattle.apnic.net> References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: Does anyone give a s**t about this any more? From what I learned at the latest NANOG it's very clear that nobody reads this any more. Is there any good reason to persist in spamming the nanog list with this report? thanks, Geoff From randy at psg.com Sat Oct 15 14:29:06 2011 From: randy at psg.com (Randy Bush) Date: Sat, 15 Oct 2011 12:29:06 -0700 Subject: [routing-wg] The Cidr Report In-Reply-To: <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> References: <201110142200.p9EM00ua002638@wattle.apnic.net> <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> Message-ID: > From what I learned at the latest NANOG it's very clear that nobody > reads this any more. some read it. we are the frustrated ones. no one seems to act on it. > Is there any good reason to persist in spamming the nanog list with > this report? not clear, sad to say. i really think that the only way to reduce fragging is filtering. maybe a bgp blackhole feed for frags for which there are covering prefixes? randy From shrdlu at deaddrop.org Sat Oct 15 15:24:30 2011 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 15 Oct 2011 13:24:30 -0700 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <201110142200.p9EM01Hv002644@wattle.apnic.net> Message-ID: <4E99EBFE.7080707@deaddrop.org> On 10/15/2011 4:26 AM, Geoff Huston wrote: > While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? I read both of them, and also the Weekly Routing Report. I will regret the loss, and consider all three to be far more valuable than 90% of the traffic on the list. -- Last week we lost a giant in the world of computing. Last weekend we lost the giant on whose shoulders he stood. Rest in peace, friend. (Tim Pierce, on the deaths of Dennis Ritchie and Steve Jobs) From john-nanog at johnpeach.com Sat Oct 15 15:30:07 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 15 Oct 2011 16:30:07 -0400 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <201110142200.p9EM01Hv002644@wattle.apnic.net> Message-ID: <20111015163007.4e39086c@milhouse> On Sat, 15 Oct 2011 22:26:36 +1100 Geoff Huston wrote: > While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? If you don't want them, filter them to /dev/null. > > regards, > Geoff -- John From wmaton at ottix.net Sat Oct 15 15:31:44 2011 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Sat, 15 Oct 2011 16:31:44 -0400 (EDT) Subject: [routing-wg] BGP Update Report In-Reply-To: <4E99EBFE.7080707@deaddrop.org> References: <201110142200.p9EM01Hv002644@wattle.apnic.net> <4E99EBFE.7080707@deaddrop.org> Message-ID: On Sat, 15 Oct 2011, Lynda wrote: > On 10/15/2011 4:26 AM, Geoff Huston wrote: >> While I am at it, does anyone read this report, or is this weekly report >> also just part of the spam load on this list? > > I read both of them, and also the Weekly Routing Report. I will regret the > loss, and consider all three to be far more valuable than 90% of the traffic > on the list. +1 The reports are also useful to do a double-check on changes I've made from the perspective of others (even if they are automated tools). wfms From patrick at ianai.net Sat Oct 15 15:41:45 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 15 Oct 2011 16:41:45 -0400 Subject: [routing-wg] The Cidr Report In-Reply-To: References: <201110142200.p9EM00ua002638@wattle.apnic.net> <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> Message-ID: <8569DBD0-35C4-4659-A5A2-77B8E73B0436@ianai.net> On Oct 15, 2011, at 3:29 PM, Randy Bush wrote: >> From what I learned at the latest NANOG it's very clear that nobody >> reads this any more. > > some read it. we are the frustrated ones. Some read it. I think everyone on NANOG is frustrated (or not paying attention). I would suggest that you keep sending it, but I have no way to motivate you to do so other than to confirm I do read it. > no one seems to act on it. It is useful even just as data to show others, whether they act on that data or not. >> Is there any good reason to persist in spamming the nanog list with >> this report? > > not clear, sad to say. > > i really think that the only way to reduce fragging is filtering. maybe > a bgp blackhole feed for frags for which there are covering prefixes? If history is any guide, this will not work. Someone will listen, and those who do not will lose customer (i.e. money). The Internet is a business, and therefore money talks. To date, no one has been able to prove to the bean counters that more prefixes means less profit. For instance, I spoke to someone at the conference whose company is spewing 1000s of prefixes they do not have to. That person said "well, FIB compression makes everything OK, so it doesn't matter, right?" (paraphrased). This is a company who tells others "you have to pay me to use my resources", yet feels absolutely no qualms about using other networks' resources for free. Hypocrisy is live & well on the Internet. (I know you are all shocked.) -- TTFN, patrick From simon.leinen at switch.ch Sat Oct 15 15:50:50 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 15 Oct 2011 22:50:50 +0200 Subject: Apple updates - Effect on network In-Reply-To: <4E96F49F.20904@mt.au.com> (Matt Taylor's message of "Fri, 14 Oct 2011 01:24:31 +1100") References: <4E96DC9B.7020201@gmail.com> <4E96F49F.20904@mt.au.com> Message-ID: Matt Taylor writes: > Would love to see some bandwidth graphs. :) Here's one from another network. -------------- next part -------------- A non-text attachment was scrubbed... Name: akamai-week.png Type: image/png Size: 16614 bytes Desc: not available URL: -------------- next part -------------- Guess it was a good idea to upgrade that Akamai cluster's uplink to 10GE, even though 2*GE (or was it 4*GE) looked sufficient at the time. Remember folks, "overprovisioning" is a misnomer, it should be called "provisioning for robustness and growth". -- Simon. From shrdlu at deaddrop.org Sat Oct 15 15:51:55 2011 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 15 Oct 2011 13:51:55 -0700 Subject: Please change Mailman back to NOT force the rewrite for Reply-to Message-ID: <4E99F26B.9010702@deaddrop.org> I see that someone has instructed Mailman to munge the reply-to. Please don't do that. I was about to make a *private* reply to someone, and realized that the setting had changed, and that I was trapped into replying to the list. Normally I'd have just made this point privately, and perhaps only on Futures, but since it seems to be a recent change, I'm doing the public service of pointing it out, while asking that it be adjusted back. -- Last week we lost a giant in the world of computing. Last weekend we lost the giant on whose shoulders he stood. Rest in peace, friend. (Tim Pierce, on the deaths of Dennis Ritchie and Steve Jobs) From keegan.holley at sungard.com Sat Oct 15 16:01:07 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Sat, 15 Oct 2011 17:01:07 -0400 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <201110142200.p9EM01Hv002644@wattle.apnic.net> <4E99EBFE.7080707@deaddrop.org> Message-ID: +1 good to get a view from multiple sources even if they are automated. Should be easy enough to filter for those that do not want them. 2011/10/15 William F. Maton Sotomayor > On Sat, 15 Oct 2011, Lynda wrote: > > On 10/15/2011 4:26 AM, Geoff Huston wrote: >> >>> While I am at it, does anyone read this report, or is this weekly report >>> also just part of the spam load on this list? >>> >> >> I read both of them, and also the Weekly Routing Report. I will regret the >> loss, and consider all three to be far more valuable than 90% of the traffic >> on the list. >> > > +1 > > The reports are also useful to do a double-check on changes I've made from > the perspective of others (even if they are automated tools). > > wfms > > > From simon.leinen at switch.ch Sat Oct 15 16:01:57 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 15 Oct 2011 23:01:57 +0200 Subject: [routing-wg] The Cidr Report In-Reply-To: (Geoff Huston's message of "Sun, 16 Oct 2011 06:25:58 +1100") References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: Geoff Huston writes: > Does anyone give a s**t about this any more? I do; I check the weekly increase every week, and check who the top offenders are. If someone from my vicinity/circles is on the list (doesn't happen frequently; more often for the BGP updates report than for CIDR), I may send them a note and ask what happened. > From what I learned at the latest NANOG it's very clear that nobody > reads this any more. "Reads" may be an exaggeration, but I'm sure some look at it. > Is there any good reason to persist in spamming the nanog list with > this report? I think it still provides an incentive for people not to mess things up too badly; and a chance of some mishaps to be noticed quicker, with a little help from your friends. -- Simon. From john-nanog at johnpeach.com Sat Oct 15 16:02:53 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 15 Oct 2011 17:02:53 -0400 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <4E99F26B.9010702@deaddrop.org> References: <4E99F26B.9010702@deaddrop.org> Message-ID: <20111015170253.5c53f2bd@milhouse> On Sat, 15 Oct 2011 13:51:55 -0700 Lynda wrote: > > I see that someone has instructed Mailman to munge the reply-to. Please > don't do that. I was about to make a *private* reply to someone, and > realized that the setting had changed, and that I was trapped into > replying to the list. > > Normally I'd have just made this point privately, and perhaps only on > Futures, but since it seems to be a recent change, I'm doing the public > service of pointing it out, while asking that it be adjusted back. I don't see that; I have to specifically choose to reply to the list. Maybe someone, like me, sets their own reply-to to the list. > -- John From regnauld at nsrc.org Sat Oct 15 16:17:58 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 15 Oct 2011 23:17:58 +0200 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <20111015170253.5c53f2bd@milhouse> References: <4E99F26B.9010702@deaddrop.org> <20111015170253.5c53f2bd@milhouse> Message-ID: <20111015211758.GI3054@macbook.bluepipe.net> John Peach (john-nanog) writes: > > Normally I'd have just made this point privately, and perhaps only on > > Futures, but since it seems to be a recent change, I'm doing the public > > service of pointing it out, while asking that it be adjusted back. > > I don't see that; I have to specifically choose to reply to the list. > Maybe someone, like me, sets their own reply-to to the list. From the headers. X-Mailman-Version: 2.1.14 Precedence: list Reply-To: nanog at nanog.org List-Id: North American Network Operators Group Mutt asks me, but other mailers might not. Cheers, Phil From patrick at ianai.net Sat Oct 15 16:21:16 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 15 Oct 2011 17:21:16 -0400 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <20111015211758.GI3054@macbook.bluepipe.net> References: <4E99F26B.9010702@deaddrop.org> <20111015170253.5c53f2bd@milhouse> <20111015211758.GI3054@macbook.bluepipe.net> Message-ID: On Oct 15, 2011, at 5:17 PM, Phil Regnauld wrote: > John Peach (john-nanog) writes: >>> Normally I'd have just made this point privately, and perhaps only on >>> Futures, but since it seems to be a recent change, I'm doing the public >>> service of pointing it out, while asking that it be adjusted back. >> >> I don't see that; I have to specifically choose to reply to the list. >> Maybe someone, like me, sets their own reply-to to the list. > > From the headers. > > X-Mailman-Version: 2.1.14 > Precedence: list > Reply-To: nanog at nanog.org > List-Id: North American Network Operators Group > > Mutt asks me, but other mailers might not. Yes, he said he set reply-to himself. Look at your own post, it has no such header. -- TTFN, patrick From ges at wingfoot.org Sat Oct 15 16:21:58 2011 From: ges at wingfoot.org (Glenn Sieb) Date: Sat, 15 Oct 2011 17:21:58 -0400 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <20111015211758.GI3054@macbook.bluepipe.net> References: <4E99F26B.9010702@deaddrop.org> <20111015170253.5c53f2bd@milhouse> <20111015211758.GI3054@macbook.bluepipe.net> Message-ID: <4E99F976.7000302@wingfoot.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/15/11 5:17 PM, Phil Regnauld wrote: > John Peach (john-nanog) writes: >>> Normally I'd have just made this point privately, and perhaps >>> only on Futures, but since it seems to be a recent change, I'm >>> doing the public service of pointing it out, while asking that >>> it be adjusted back. >> >> I don't see that; I have to specifically choose to reply to the >> list. Maybe someone, like me, sets their own reply-to to the >> list. > > From the headers. > > X-Mailman-Version: 2.1.14 Precedence: list Reply-To: > nanog at nanog.org List-Id: North American Network Operators Group > > > Mutt asks me, but other mailers might not. I think you missed John's last sentence, Phil... For instance, on *this* email, and *your* email, a reply goes to the individual. I have to specifically put the list address in. Perhaps Lynda hit someone's manually-set Reply-to header and thought it was set by Mailman... Best, - --Glenn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Z+XYACgkQf5MxTDXTimFXRgCfUTlQmwPfqL6atcwoGyRi5ERq +7IAoIyILrdRDekx0tnxLw6qV/FhqelS =1Vrf -----END PGP SIGNATURE----- From hank at efes.iucc.ac.il Sat Oct 15 16:26:17 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 15 Oct 2011 23:26:17 +0200 (IST) Subject: [routing-wg] The Cidr Report In-Reply-To: References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: On Sat, 15 Oct 2011, Simon Leinen wrote: Ditto here. -Hank > Geoff Huston writes: >> Does anyone give a s**t about this any more? > > I do; I check the weekly increase every week, and check who the top > offenders are. If someone from my vicinity/circles is on the list > (doesn't happen frequently; more often for the BGP updates report than > for CIDR), I may send them a note and ask what happened. > >> From what I learned at the latest NANOG it's very clear that nobody >> reads this any more. > > "Reads" may be an exaggeration, but I'm sure some look at it. > >> Is there any good reason to persist in spamming the nanog list with >> this report? > > I think it still provides an incentive for people not to mess things up > too badly; and a chance of some mishaps to be noticed quicker, with a > little help from your friends. > From regnauld at nsrc.org Sat Oct 15 16:27:58 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 15 Oct 2011 23:27:58 +0200 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <4E99F976.7000302@wingfoot.org> Message-ID: <20111015212758.GK3054@macbook.bluepipe.net> Patrick W. Gilmore (patrick) writes: > > Yes, he said he set reply-to himself. Look at your own post, it has no such header. Glenn Sieb (ges) writes: > > I think you missed John's last sentence, Phil... *sigh* back to the coffee machine. P. From john-nanog at johnpeach.com Sat Oct 15 16:22:03 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 15 Oct 2011 17:22:03 -0400 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <20111015211758.GI3054@macbook.bluepipe.net> References: <4E99F26B.9010702@deaddrop.org> <20111015170253.5c53f2bd@milhouse> <20111015211758.GI3054@macbook.bluepipe.net> Message-ID: <20111015172203.4355850a@milhouse> On Sat, 15 Oct 2011 23:17:58 +0200 Phil Regnauld wrote: > John Peach (john-nanog) writes: > > > Normally I'd have just made this point privately, and perhaps only on > > > Futures, but since it seems to be a recent change, I'm doing the public > > > service of pointing it out, while asking that it be adjusted back. > > > > I don't see that; I have to specifically choose to reply to the list. > > Maybe someone, like me, sets their own reply-to to the list. > > From the headers. > > X-Mailman-Version: 2.1.14 > Precedence: list > Reply-To: nanog at nanog.org > List-Id: North American Network Operators Group > > Mutt asks me, but other mailers might not. That's the reply-to my MTA puts in there: X-Mailman-Version: 2.1.14 Precedence: list List-Id: North American Network Operators Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nanog-bounces+john-nanog=johnpeach.com at nanog.org > > Cheers, > Phil > -- John From jra at baylink.com Sat Oct 15 17:23:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Oct 2011 18:23:57 -0400 (EDT) Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <4E99F26B.9010702@deaddrop.org> Message-ID: <9122126.5148.1318717437376.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Lynda" > I see that someone has instructed Mailman to munge the reply-to. > Please don't do that. I was about to make a *private* reply to someone, and > realized that the setting had changed, and that I was trapped into > replying to the list. It's you, Lynda. Really. :-) Your message, frex, did not have reply-to munged; I had to do it by hand (since Zimbra 6 is still too stupid; I've had that bug open for over 2 years now; maybe 7 fixes it). One reply to you did, but the rest did not. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From shrdlu at deaddrop.org Sat Oct 15 18:15:49 2011 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 15 Oct 2011 16:15:49 -0700 Subject: Please change Mailman back to NOT force the rewrite for Reply-to In-Reply-To: <9122126.5148.1318717437376.JavaMail.root@benjamin.baylink.com> References: <9122126.5148.1318717437376.JavaMail.root@benjamin.baylink.com> Message-ID: <4E9A1425.2080808@deaddrop.org> On 10/15/2011 3:23 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Lynda" > >> I see that someone has instructed Mailman to munge the reply-to. >> Please don't do that. I was about to make a *private* reply to someone, and >> realized that the setting had changed, and that I was trapped into >> replying to the list. > > It's you, Lynda. Really. :-) Well, *now* I know it's not mailman, but it's not me, either. Not exactly. What I noticed was that *some* of the email to Nanog, today, had this set, but not all. I was very confused (it's not the first time I've been confused, of course). > Your message, frex, did not have reply-to munged; I had to do it by hand > (since Zimbra 6 is still too stupid; I've had that bug open for over 2 years > now; maybe 7 fixes it). One reply to you did, but the rest did not. Yeah, Mr Peach set an evil trap for me. I'd been about to send him a private email (on something of absolutely no importance), and when I realized it went back to Nanog, was puzzled enough to check to see whether it had been changed. Cleverly, I tested replies to a couple of other emails, and as luck would have it, one was my own (and tbird has a stupid habit of knowing that if it's a mailing list, I surely meant to send it to the list), and the other two were both to Mr Peach. Sorry for noise. Back to making sure Geoff H believes us, and keeps right on sending the reports. -- Last week we lost a giant in the world of computing. Last weekend we lost the giant on whose shoulders he stood. Rest in peace, friend. (Tim Pierce, on the deaths of Dennis Ritchie and Steve Jobs) From nanog at namor.ca Sat Oct 15 19:06:12 2011 From: nanog at namor.ca (J) Date: Sat, 15 Oct 2011 19:06:12 -0500 Subject: Apple updates - Akamai effect In-Reply-To: References: <4E96DC9B.7020201@gmail.com> <4E96F49F.20904@mt.au.com> Message-ID: <4E9A1FF4.40103@namor.ca> Simon Leinen wrote: > ------------------------------------------------------------------------ > > Guess it was a good idea to upgrade that Akamai cluster's uplink to > 10GE, even though 2*GE (or was it 4*GE) looked sufficient at the time. > Remember folks, "overprovisioning" is a misnomer, it should be called > "provisioning for robustness and growth". If I may change the thrust a bit, this is of interest to me. Just because we're in the midst of similar - changing from 2xGE to 10GE and increasing the number of Akamai nodes. Anyone have similar stats on that sort of conversion, and what to expect? >From what I can tell, there's a fair bit of local, off-net traffic coming to ours, so I'm curious what the turn-up may look like. This may be just idle curiosity, but what the hey. From joelja at bogus.com Sat Oct 15 19:17:50 2011 From: joelja at bogus.com (Joelja@bogus.com) Date: Sat, 15 Oct 2011 17:17:50 -0700 Subject: [routing-wg] The Cidr Report Message-ID: I read it every week. It's a finger on the pulse of a system on which I am totally dependent... Geoff Huston wrote: >Does anyone give a s**t about this any more? > >From what I learned at the latest NANOG it's very clear that nobody reads this any more. > >Is there any good reason to persist in spamming the nanog list with this report? > > >thanks, > Geoff > > > > From rafael.ribeiro at rnp.br Sat Oct 15 19:37:47 2011 From: rafael.ribeiro at rnp.br (Rafael de Oliveira Ribeiro) Date: Sat, 15 Oct 2011 21:37:47 -0300 (BRT) Subject: OT: ISPs in Brazil and Chile (Luis Palma) In-Reply-To: Message-ID: <73a8df30-c8a2-4236-b0db-86dbabddca29@ara> ----- Original Message ----- > Date: Thu, 13 Oct 2011 18:35:35 +0000 > From: Jeff Cartier > To: "nanog at nanog.org" > Subject: OT: ISPs in Brazil and Chile > Message-ID: > <6EDE133FF50DBA4B963028BD5CD690DD368B24 at CAPRGWLKWEMBX1.pernod-ricard.group> > > Content-Type: text/plain; charset="us-ascii" > > Hi Group, > > A little off topic, but I was looking for a recommendation on an ISP > in both Brazil and Chile. (...) Some ISPs in Brazil include: - Oi; - Telefonica; - Intelig (Telecom Italia group); - CTBC; - GVT; - Embratel (Telmex group) - caveat: they don't peer! - Global Crossing, - et cetera. Chances are that Oi, CTBC and GVT will not be present in Chile, though. While evaluating your ISP, check the PTT-SP roster [1] to see if the ISP has the tick mark on the column "ATM" (MLPA, in Portuguese) - for peering purposes. [1] - Biggest IXP in Brazil, http://sp.ptt.br/particip.html Best regards, -- Rafael de Oliveira Ribeiro DAERO - Gerencia de Operacoes RNP - Rede Nacional de Ensino e Pesquisa Tel.: +55 21 2102 9659 - iNOC: 1916*767 From ops.lists at gmail.com Sat Oct 15 19:43:11 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 16 Oct 2011 06:13:11 +0530 Subject: [routing-wg] The Cidr Report In-Reply-To: References: Message-ID: <21B98BDE-0718-4272-A426-820C98E92945@gmail.com> those who read it and follow routing best practicez will continue to do those, those who havent yet given a shit wont get a sudden dose of exlax after seeing their asn in it. --srs (iPad) On 16-Oct-2011, at 5:47, "Joelja at bogus.com" wrote: > I read it every week. It's a finger on the pulse of a system on which I am totally dependent... > > Geoff Huston wrote: > >> Does anyone give a s**t about this any more? >> >> From what I learned at the latest NANOG it's very clear that nobody reads this any more. >> >> Is there any good reason to persist in spamming the nanog list with this report? >> >> >> thanks, >> Geoff >> >> >> >> From randy at psg.com Sat Oct 15 19:43:30 2011 From: randy at psg.com (Randy Bush) Date: Sat, 15 Oct 2011 17:43:30 -0700 Subject: [routing-wg] The Cidr Report In-Reply-To: References: Message-ID: > I read it every week. It's a finger on the pulse of a system on which > I am totally dependent... the email i want to see here is "i wuz a polluter, but i read the cidr report, i haz seen the light, and i'm gonna stop polluting." no, i am not holding my breath. randy From patrick at ianai.net Sat Oct 15 19:43:20 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 15 Oct 2011 20:43:20 -0400 Subject: Apple updates - Akamai effect In-Reply-To: <4E9A1FF4.40103@namor.ca> References: <4E96DC9B.7020201@gmail.com> <4E96F49F.20904@mt.au.com> <4E9A1FF4.40103@namor.ca> Message-ID: <755F370F-1D7D-44F6-8287-60E8051F8E9E@ianai.net> On Oct 15, 2011, at 20:06, J wrote: > Simon Leinen wrote: >> Guess it was a good idea to upgrade that Akamai cluster's uplink to >> 10GE, even though 2*GE (or was it 4*GE) looked sufficient at the time. >> Remember folks, "overprovisioning" is a misnomer, it should be called >> "provisioning for robustness and growth". > > If I may change the thrust a bit, this is of interest to me. > > Just because we're in the midst of similar - changing from 2xGE to 10GE and > increasing the number of Akamai nodes. > > Anyone have similar stats on that sort of conversion, and what to expect? > From what I can tell, there's a fair bit of local, off-net traffic coming to > ours, so I'm curious what the turn-up may look like. It sounds like you have what Akamai calls an "AANP" deployment. In general, that should not serve users outside your network. There are reasons it can, and you should talk to Akamai about it if you think it is. If you have questions about an on-net node, feel free to email Akamai's Network Support group, NetSupport at akamai.com. They are only M-F, but they can answer any questions you have. -- TTFN, patrick From rjoffe at centergate.com Sat Oct 15 21:14:59 2011 From: rjoffe at centergate.com (Rodney Joffe) Date: Sun, 16 Oct 2011 03:14:59 +0100 Subject: 13 years ago today - October 16, 1998... Message-ID: <8BC52874-7365-4287-8D67-59A01E9F8711@centergate.com> we lost Jon. It feels like just yesterday. http://www.apps.ietf.org/rfc/rfc2468.html From randy_94108 at yahoo.com Sat Oct 15 21:31:11 2011 From: randy_94108 at yahoo.com (Randy) Date: Sat, 15 Oct 2011 19:31:11 -0700 (PDT) Subject: 13 years ago today - October 16, 1998... In-Reply-To: <8BC52874-7365-4287-8D67-59A01E9F8711@centergate.com> Message-ID: <1318732271.58647.YahooMailClassic@web80504.mail.mud.yahoo.com> Yes..and we all owe him a debt of gratitude. --- On Sat, 10/15/11, Rodney Joffe wrote: > From: Rodney Joffe > Subject: 13 years ago today - October 16, 1998... > To: nanog at nanog.org > Date: Saturday, October 15, 2011, 7:14 PM > we lost Jon. > > It feels like just yesterday. > > http://www.apps.ietf.org/rfc/rfc2468.html > > From jra at baylink.com Sat Oct 15 22:20:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Oct 2011 23:20:58 -0400 (EDT) Subject: 13 years ago today - October 16, 1998... In-Reply-To: <8BC52874-7365-4287-8D67-59A01E9F8711@centergate.com> Message-ID: <5351310.5154.1318735258618.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rodney Joffe" > Subject: 13 years ago today - October 16, 1998... > we lost Jon. > > It feels like just yesterday. > > http://www.apps.ietf.org/rfc/rfc2468.html My path didn't cross Jon's much... but he was nice enough to reserve the really cool RFC number that graces my AFJ contribution from 1997 -- 3 or 4 RFCs with higher numbers came out in March. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From nanog at hostleasing.net Sat Oct 15 22:23:16 2011 From: nanog at hostleasing.net (Randy Epstein) Date: Sat, 15 Oct 2011 23:23:16 -0400 Subject: [Nanog] Ballot Confirmation In-Reply-To: Message-ID: On 10/15/11 11:21 PM, "Randy Epstein" wrote: >Betty, > >I believe there was a problem with the voting system this past election. >Proposed amendment 1, which I voted NO on, did not register. It does not >show a vote in the ballot confirmation email (well, it just doesn't say >what I did), but I know I voted NO. Further, what makes this even more >suspicious is that 0 people voted no on this one, yet 8 voted no on the >2nd. Yet, the yes votes on both were 79 and 78 respectively. > >Results: > >Member structure ratification >79 yes > >0 no > > >Committee Structure Simplification Rationale >78 yes > >8 no > > > > > > > > > >Can anyone investigate this? I'm just concerned that there might be a >problem in the future, and I'd like to find out what happened here. > >Regards, > >Randy > >On 10/9/11 11:15 PM, "Nanog" wrote: > >>Ballot Cast: Bylaw Changes >>Cast by: Randy Epstein >> >>1. Membership structure ratification

>>Rationale: >>The membership structure as specified in the original bylaws made a lot >>of people unhappy, so the board used its power to temporarily amend the >>bylaws to institute the now-current membership structure, under which >>all >>current NANOG voters have become members. That amendment now needs to >>be >>ratified by the membership, to avoid the membership structure reverting >>to its previous state.

>> >>Proposal: >>That the membership ratify the bylaw amendment enacted by the Board on >>January 4, 2011, establishing the now-current NANOG membership >>structure. >>

>> >>The amendment is as follows: >>- Replace the current section 5 in its entirety with:

>> >>5. Membership

>> >>5.1 Membership Qualifications - Membership in NewNOG is open to any >>individual with an interest in Internet operations, engineering, or >>research and who wishes to further education and knowledge sharing >>within >>the Internet operations community. Any individual may become a member of >>NewNOG by completing an application and payment of dues.

>> >>5.2 Membership Classes - There shall be only one class of membership, >>with all the rights and privileges specified in these Bylaws.

>> >>5.3 Membership Dues - The Board of Directors shall specify the cost of >>annual membership dues. The Board may establish discounts for members >>meeting certain criteria, or for members wishing to pay for more than >>one >>year in advance.

>> >>5.4 Rights and Benefits of Members - Members in good standing shall be >>entitled to these privileges: >> >>

* Vote in all NewNOG elections. * Run as a candidate for the Board >>of Directors * Serve on an administrative committee, as defined in >>section 9 * Other privileges as specified by the Board of Directors

>> >>5.5 Policies and Procedures - The Board of Directors shall establish and >>publish policies and procedures for implementation of the membership >>program. >> >> >>

2. Committee Structure Simplification >>Rationale:

>>Substantial portions of the roles of the Event Logistics committee and >>the Budget and Finance committee are now being carried out by the >>Executive Director and staff, with oversight by the Treasurer and other >>board members. This amendment eliminates the permanent status of those >>committees, and allows the board discretion to create new ad hoc >>committees as needs change.

>> >>The amendment would: >> >>- Eliminate the finance and event committees as standing committees >>- Allow the board to create other ad-hoc committees as needed to perform >>specific tasks >>- Clarify that all committee chairs are given non-voting ex-officio >>seats >>on the board, which are not counted towards a quorum >>- Fix a few other minor language issues and typos

>> >>Proposal: >>- In section 8.6, replace the text "at least four members" with "at >>least >>four voting members".

>> >>- Replace section 9 introductory text with: >>The Board of Directors will create three standing committees to fulfill >>the NewNOG mission. Those committees will be the Program Committee, the >>Communication Committee, and the Membership and Development Committee. >>The Board may also at its discretion create ad hoc committees to carry >>out other functions as needed. All members of committees must be >>Members >>in Good Standing of NewNOG. >>The chairperson of each committee will serve ex officio in a non-voting >>role on the Board of Directors, in order to facilitate communication >>between the groups.

>> >>- In section 9.1.2, replace the word "Council" with "Committee".

>> >>- In section 9.2.3, replace the misspelled word "Acceptible" with >>"Acceptable".

>> >>- In section 9.2.5, delete the sentence: >>

>> >>The chairperson of the Communications Committee will serve ex officio in >>a non-voting role on the Board of Directors, in order to facilitate >>communication between the two groups.

>> >>- In section 9.3.1, delete the sentence:

>> >>The chairperson of the Membership and Development Committee will serve >>ex >>officio in a non-voting role on the Board of Directors, in order to >>facilitate communication between the two groups.

>> >>- Replace section 9.4 with:

>> >>9.4 Ad Hoc Committees

>> >>The Board of Directors may from time to time create ad hoc committees >>and >>appoint members as needed to carry out specific functions.

>> >>- Delete section 9.5.

>> >>- In section 10.3.2, delete the sentence:

>> >>The Chair of the Program Committee will serve ex officio in a non-voting >>role on the Board of Directors, in order to facilitate communication >>between the two groups.

>> Not Approve >> From Skeeve at eintellego.net Sat Oct 15 22:48:42 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 16 Oct 2011 03:48:42 +0000 Subject: [routing-wg] BGP Update Report In-Reply-To: <4E99EBFE.7080707@deaddrop.org> Message-ID: I read them all too. BUT, I get some 5 or 6 copies of them from all the lists I am on. I would rather subscribe to a list that was just for those. ?Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts Who The Experts Call Juniper - HP Networking - Cisco - Brocade On 16/10/11 7:24 AM, "Lynda" > wrote: On 10/15/2011 4:26 AM, Geoff Huston wrote: While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? I read both of them, and also the Weekly Routing Report. I will regret the loss, and consider all three to be far more valuable than 90% of the traffic on the list. -- Last week we lost a giant in the world of computing. Last weekend we lost the giant on whose shoulders he stood. Rest in peace, friend. (Tim Pierce, on the deaths of Dennis Ritchie and Steve Jobs) From Skeeve at eintellego.net Sat Oct 15 22:50:08 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 16 Oct 2011 03:50:08 +0000 Subject: [routing-wg] BGP Update Report In-Reply-To: <20111015163007.4e39086c@milhouse> Message-ID: John, Bit hard for Geoff to devnull them, he is the author ;-) ?Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts Who The Experts Call Juniper - HP Networking - Cisco - Brocade On 16/10/11 7:30 AM, "John Peach" > wrote: On Sat, 15 Oct 2011 22:26:36 +1100 Geoff Huston > wrote: While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? If you don't want them, filter them to /dev/null. regards, Geoff -- John From don at bowenvale.co.nz Sat Oct 15 23:13:33 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 16 Oct 2011 17:13:33 +1300 Subject: [routing-wg] BGP Update Report In-Reply-To: References: Message-ID: <4E9A59ED.3090509@bowenvale.co.nz> I agree with Skeeve that it hits a number of lists, but I think that is a good thing and is of value. I agree with others who have said that there is any amount of worthless noise on lists and we can just filter if not required. Personally iirc, it was this content that led me to find Geoff's web site and follow on to a number of other very useful resources when I first started learning about this space. We need to remember that not every person in this space enters from University but some migrate to it because of other drivers. Hence some of these resources, that those of you with decades of experience, wonder about the value of, actually have far more value than just their core content. (Hope that makes sense.). D On 16/10/2011 4:48 p.m., Skeeve Stevens wrote: > I read them all too. > > BUT, I get some 5 or 6 copies of them from all the lists I am on. I would rather subscribe to a list that was just for those. > > ?Skeeve > > -- > > Skeeve Stevens, CEO - eintellego Pty Ltd > > skeeve at eintellego.net ; www.eintellego.net > > Phone: 1300 753 383 ; Fax: (+612) 8572 9954 > > Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellego > > twitter.com/networkceoau ; www.linkedin.com/in/skeeve > > PO Box 7726, Baulkham Hills, NSW 1755 Australia > > > -- > > eintellego - The Experts Who The Experts Call > Juniper - HP Networking - Cisco - Brocade > > On 16/10/11 7:24 AM, "Lynda"> wrote: > > On 10/15/2011 4:26 AM, Geoff Huston wrote: > While I am at it, does anyone read this report, or is this weekly report also just part of the spam load on this list? > > I read both of them, and also the Weekly Routing Report. I will regret > the loss, and consider all three to be far more valuable than 90% of the > traffic on the list. > > -- > Last week we lost a giant in the world of computing. > Last weekend we lost the giant on whose shoulders he stood. > Rest in peace, friend. > (Tim Pierce, on the deaths of Dennis Ritchie and Steve Jobs) > > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From charles at knownelement.com Sat Oct 15 23:21:49 2011 From: charles at knownelement.com (Charles N Wyble) Date: Sat, 15 Oct 2011 23:21:49 -0500 Subject: [routing-wg] BGP Update Report In-Reply-To: References: Message-ID: <4E9A5BDD.50708@knownelement.com> On 10/15/2011 10:48 PM, Skeeve Stevens wrote: > I read them all too. > > BUT, I get some 5 or 6 copies of them from all the lists I am on. I would rather subscribe to a list that was just for those. +1. Or an rss feed or something. That way interested folks could easily pull the data and stay up to date. -- Charles N Wyble charles at knownelement.com @charlesnw on twitter http://blog.knownelement.com Building alternative,global scale,secure, cost effective bit moving platform for tomorrows alternate default free zone. From randy at psg.com Sat Oct 15 23:45:49 2011 From: randy at psg.com (Randy Bush) Date: Sat, 15 Oct 2011 21:45:49 -0700 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <4E99EBFE.7080707@deaddrop.org> Message-ID: > BUT, I get some 5 or 6 copies of them from all the lists I am on. I > would rather subscribe to a list that was just for those. procmail is your friend # prevent dupes # :0 Whc: msgid.lock | formail -D 65536 msgid.cache :0 a:0 $TRASH From kyle.creyts at gmail.com Sun Oct 16 00:35:51 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sun, 16 Oct 2011 01:35:51 -0400 Subject: [routing-wg] The Cidr Report In-Reply-To: <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> References: <201110142200.p9EM00ua002638@wattle.apnic.net> <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> Message-ID: I may not read it for the purpose of aggregation, but it is useful data to me for other purposes. As long as there is one person talking and at least one person listening, a thread is in order, and it isn't spam. On Oct 15, 2011 3:25 PM, "Geoff Huston" wrote: > From what I learned at the latest NANOG it's very clear that nobody reads > this any more. > > Is there any good reason to persist in spamming the nanog list with this > report? > > > thanks, > Geoff > > > > From jim at miltonsecurity.com Sun Oct 16 00:45:19 2011 From: jim at miltonsecurity.com (James McMurry) Date: Sat, 15 Oct 2011 22:45:19 -0700 Subject: [routing-wg] The Cidr Report In-Reply-To: References: <201110142200.p9EM00ua002638@wattle.apnic.net> <6FBC4D01-2BAD-4837-AC2E-EA0DA63B1BBD@apnic.net> Message-ID: <6014C40C-A355-4F3F-88F8-122F6A93C58C@miltonsecurity.com> Ditto, and I do find it informative. Jim On Oct 15, 2011, at 10:35 PM, Kyle Creyts wrote: > I may not read it for the purpose of aggregation, but it is useful data to > me for other purposes. > > As long as there is one person talking and at least one person listening, a > thread is in order, and it isn't spam. > On Oct 15, 2011 3:25 PM, "Geoff Huston" wrote: > >> From what I learned at the latest NANOG it's very clear that nobody reads >> this any more. >> >> Is there any good reason to persist in spamming the nanog list with this >> report? >> >> >> thanks, >> Geoff >> >> >> >> From graham at apolix.co.za Sun Oct 16 02:05:25 2011 From: graham at apolix.co.za (Graham Beneke) Date: Sun, 16 Oct 2011 09:05:25 +0200 Subject: [routing-wg] The Cidr Report In-Reply-To: References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: <4E9A8235.4050309@apolix.co.za> On 15/10/2011 21:25, Geoff Huston wrote: > Does anyone give a s**t about this any more? I do. While most of the content of the actual mail has very little relevance to me, it does provide useful leverage and motivation to fix some of the networks where I do have influence. > From what I learned at the latest NANOG it's very clear that nobody reads this any more. I often don't have the time to read every report in detail and much of it applies to networks outside of my circles. Every few weeks it does however prompt me to go and review my own network (and sometimes wave a stick at few ops people) > Is there any good reason to persist in spamming the nanog list with this report? I definitely think its still useful for the community. Perhaps the frequency could be dialed back a little? I'm sure that there are many people who don't really notice it any more due to their mental white noise filters. Perhaps some slightly different presentations of the data would also make it more useful. I am quite interested in the number of prefixes of various lengths that are seen in the table and that doesn't get included in the mailed report. Perhaps a "biggest climbers & fallers" list would also have more relevance for the regular report. The "Top 30" list doesn't seem to change very often... ;-) -- Graham Beneke From bzeeb-lists at lists.zabbadoz.net Sun Oct 16 04:16:39 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun, 16 Oct 2011 09:16:39 +0000 Subject: [routing-wg] The Cidr Report In-Reply-To: References: <201110142200.p9EM00ua002638@wattle.apnic.net> Message-ID: <7ADE4481-E8AD-4BDE-B49E-D655C83C9B94@lists.zabbadoz.net> On 15. Oct 2011, at 19:25 , Geoff Huston wrote: > Does anyone give a s**t about this any more? Yes, and if only to tell people that we could do a lot better if we'd care more about the Net than .. (?)economics(?) ..? I keep wondering if people generate more elaborated filters based on the overall data to get down table sizes rather than saying >=/24 only or similar? To me it reads as we'd still be below 256k then rather than close to 400k? Or more realistically 300k-ish? Anyone done any research how that would affect various numbers in forwarding paths? *hide* > From what I learned at the latest NANOG it's very clear that nobody reads this any more. Read? Or act? Where are the BNOsFH these days? > Is there any good reason to persist in spamming the nanog list with this report? A good reason would be to add the same damned thing for IPv6 as well to avoid us starting with the same *beep* there already. There was a great number of noise in the table when I last looked myself (given it's been a longer while). Now we want to encourage people to deploy IPv6 and not make it harder for them but a lot of obstacles in policies from the very early days are gone these days and could be cleaned up before it's too late and in addition if people roll it out now, why not do it once and do it right from the beginning, but where's the education on `eek not the same *beep* as with legacy IP again`, as some people are trapped in BBCP (bad best current practices)? Well I know you have it online, but polling a website is harder than getting it delivered to the inbox every week;) /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From john-nanog at johnpeach.com Sun Oct 16 08:39:13 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 16 Oct 2011 09:39:13 -0400 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <20111015163007.4e39086c@milhouse> Message-ID: <20111016093913.4be3ca39@milhouse> On Sun, 16 Oct 2011 03:50:08 +0000 Skeeve Stevens wrote: > John, > > Bit hard for Geoff to devnull them, he is the author ;-) not really, given that he is not the sender, the mailing list is.... > > [snip] > -- > John > > -- John From aftab.siddiqui at gmail.com Sun Oct 16 08:41:19 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Sun, 16 Oct 2011 18:41:19 +0500 Subject: The Cidr Report In-Reply-To: References: Message-ID: Randy, yes, our ASN landed on polluter list once and we fixed it. I think there is nothing wrong in sharing that. Me and few bunch of self acclaimed geeks of our region read it and have done our level best to remove few polluters but with very less success. Seems like those who should be reading it are either too busy polluting or using hushmail. Geof, this is very useful stuff for many. so how many uniqe hits you get on the website? On Sunday, October 16, 2011, Randy Bush wrote: >> I read it every week. It's a finger on the pulse of a system on which >> I am totally dependent... > > the email i want to see here is "i wuz a polluter, but i read the cidr > report, i haz seen the light, and i'm gonna stop polluting." > > no, i am not holding my breath. > > randy > > -- Regards, Aftab A. Siddiqui From randy at psg.com Sun Oct 16 08:42:48 2011 From: randy at psg.com (Randy Bush) Date: Sun, 16 Oct 2011 06:42:48 -0700 Subject: The Cidr Report In-Reply-To: References: Message-ID: aftab, > yes, our ASN landed on polluter list once and we fixed it. I think > there is nothing wrong in sharing that. thank you, thank you. > Me and few bunch of self acclaimed geeks of our region read it and > have done our level best to remove few polluters but with very less > success. what would help? randy From aftab.siddiqui at gmail.com Sun Oct 16 08:54:55 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Sun, 16 Oct 2011 18:54:55 +0500 Subject: The Cidr Report In-Reply-To: References: Message-ID: > >> Me and few bunch of self acclaimed geeks of our region read it and >> have done our level best to remove few polluters but with very less >> success. > > what would help? I guess rpki would help and a banner during every NOG/RIR meeting showing top polluters. I seriously don't understand that why an RIR can't send atleast a notice to those announcing bogus prefixes. A letter in RED mailed to the business address would help. m2c of bad geekness -- Regards, Aftab A. Siddiqui From wmaton at ottix.net Sun Oct 16 08:58:30 2011 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Sun, 16 Oct 2011 09:58:30 -0400 (EDT) Subject: [routing-wg] BGP Update Report In-Reply-To: References: <201110142200.p9EM01Hv002644@wattle.apnic.net> <4E99EBFE.7080707@deaddrop.org> Message-ID: On Sat, 15 Oct 2011, Keegan Holley wrote: > +1 > > good to get a view from multiple sources even if they are automated. Should > be easy enough to filter for those that do not want them. Plus it's helped me in the past catch a very massive (well, OK, it was a less than a hundred unaggregated routes run off into the Internet) leak, which forced me to learn about prefix-lists and such. So for those that care enough about their own networks, it can be catalyst to learning something new. > > 2011/10/15 William F. Maton Sotomayor > >> On Sat, 15 Oct 2011, Lynda wrote: >> >> On 10/15/2011 4:26 AM, Geoff Huston wrote: >>> >>>> While I am at it, does anyone read this report, or is this weekly report >>>> also just part of the spam load on this list? >>>> >>> >>> I read both of them, and also the Weekly Routing Report. I will regret the >>> loss, and consider all three to be far more valuable than 90% of the traffic >>> on the list. >>> >> >> +1 >> >> The reports are also useful to do a double-check on changes I've made from >> the perspective of others (even if they are automated tools). >> >> wfms >> >> >> > wfms From randy at psg.com Sun Oct 16 08:59:28 2011 From: randy at psg.com (Randy Bush) Date: Sun, 16 Oct 2011 06:59:28 -0700 Subject: The Cidr Report In-Reply-To: References: Message-ID: >>> Me and few bunch of self acclaimed geeks of our region read it and >>> have done our level best to remove few polluters but with very less >>> success. >> what would help? > I guess rpki would help working on it. it will lessen the perceived security benefit of fragging. > and a banner during every NOG/RIR meeting showing top polluters. NOGs could do that for the polluting operators their region. this may actually be implementable! hey EOF, if you have not been completely digested by the NCC, perhaps this would be good in wien. > I seriously don't understand that why an RIR can't send atleast a > notice to those announcing bogus prefixes. A letter in RED mailed to > the business address would help. RIRs claimed in the past that they have nothing to do with routing. of course, rpki-based origin validation changes this. but i suspect that they may still want to keep as distant as possible. randy From wmaton at ottix.net Sun Oct 16 09:06:10 2011 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Sun, 16 Oct 2011 10:06:10 -0400 (EDT) Subject: The Cidr Report In-Reply-To: References: Message-ID: On Sun, 16 Oct 2011, Aftab Siddiqui wrote: >>> success. >> >> what would help? > > I guess rpki would help and a banner during every NOG/RIR meeting showing > top polluters. A similar thing was done at a USENIX in Monterey over a decade ago. The point behind that one was to drive home how bad it was for the attendees to use telnet to their boxes at the mothership. Nothing like seeing people watch their passwords put up on two screens to teach them about SSH. Granted, placing the CIDR report up on a screen may not have the same effect, but as NANOGs get video recorded, it's a lot harder to explain in the future why you were on that list. Somehow the visual is more powerful than pretending an erased email doesn't make it into a web archive. > I seriously don't understand that why an RIR can't send atleast a notice to > those announcing bogus prefixes. A letter in RED mailed to the business > address would help. May be a useful angle for the RIRs to pursue - but are RIRs in the routing police business? wfms From aftab.siddiqui at gmail.com Sun Oct 16 09:12:33 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Sun, 16 Oct 2011 19:12:33 +0500 Subject: The Cidr Report In-Reply-To: References: Message-ID: >> I seriously don't understand that why an RIR can't send atleast a >> notice to those announcing bogus prefixes. A letter in RED mailed to >> the business address would help. > > RIRs claimed in the past that they have nothing to do with routing. of > course, rpki-based origin validation changes this. but i suspect that > they may still want to keep as distant as possible. > well IMHO, that's "stealing of resource." Yes if they have nothing to do with routing than atleast they should do somethin to safe guard what they are providing to thr members. So, any chance of putting a banner of top polluters in next APRICOT. :) -- Regards, Aftab A. Siddiqui From randy at psg.com Sun Oct 16 09:15:19 2011 From: randy at psg.com (Randy Bush) Date: Sun, 16 Oct 2011 07:15:19 -0700 Subject: The Cidr Report In-Reply-To: References: Message-ID: > So, any chance of putting a banner of top polluters in next APRICOT. :) ^ a/p i will try to work with the organizers on this randy From jra at baylink.com Sun Oct 16 09:48:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 16 Oct 2011 10:48:28 -0400 (EDT) Subject: [routing-wg] The Cidr Report In-Reply-To: <4E9A8235.4050309@apolix.co.za> Message-ID: <21622225.5166.1318776508205.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Graham Beneke" > Perhaps a "biggest climbers & fallers" list would also have more > relevance for the regular report. The "Top 30" list doesn't seem to > change very often... ;-) "And now... with the top 30 prefixes in the United States for the week ending October 16th, Two Thousand Eleven, I'm Casey Kasem... (Shuckatoom[1] plays)" Cheers, -- jra [1]http://www.youtube.com/watch?v=zhM4Y3Bo2jM -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From smb at cs.columbia.edu Sun Oct 16 09:52:37 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 16 Oct 2011 10:52:37 -0400 Subject: 13 years ago today - October 16, 1998... In-Reply-To: <5351310.5154.1318735258618.JavaMail.root@benjamin.baylink.com> References: <5351310.5154.1318735258618.JavaMail.root@benjamin.baylink.com> Message-ID: On Oct 15, 2011, at 11:20 58PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Rodney Joffe" > >> Subject: 13 years ago today - October 16, 1998... >> we lost Jon. >> >> It feels like just yesterday. >> >> http://www.apps.ietf.org/rfc/rfc2468.html > > My path didn't cross Jon's much... but he was nice enough to reserve the > really cool RFC number that graces my AFJ contribution from 1997 -- 3 or 4 > RFCs with higher numbers came out in March. Ah, I'm not the only one he did that for. I asked if the IAB/IESG statement on crypto could by RFC 1984. He told me that he never reserved RFC numbers -- but that coincidences could happen... --Steve Bellovin, https://www.cs.columbia.edu/~smb From hank at efes.iucc.ac.il Sun Oct 16 12:51:56 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 16 Oct 2011 19:51:56 +0200 (IST) Subject: The Cidr Report In-Reply-To: References: Message-ID: On Sun, 16 Oct 2011, Aftab Siddiqui wrote: > I seriously don't understand that why an RIR can't send atleast a notice to > those announcing bogus prefixes. A letter in RED mailed to the business > address would help. The RIRs have indicated in the past that they don't see this as their job even though we keep asking for it. Instead, the RIRs do other things with our membership dues that we do not ask for. Go figure. -Hank From Valdis.Kletnieks at vt.edu Sun Oct 16 13:25:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 16 Oct 2011 14:25:56 -0400 Subject: [routing-wg] BGP Update Report In-Reply-To: Your message of "Sun, 16 Oct 2011 09:39:13 EDT." <20111016093913.4be3ca39@milhouse> References: <20111015163007.4e39086c@milhouse> <20111016093913.4be3ca39@milhouse> Message-ID: <74721.1318789556@turing-police.cc.vt.edu> On Sun, 16 Oct 2011 09:39:13 EDT, John Peach said: > not really, given that he is not the sender, the mailing list is.... We want to get pedantic, who generated the Message-ID: for the mail in question? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From john-nanog at johnpeach.com Sun Oct 16 13:32:10 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 16 Oct 2011 14:32:10 -0400 Subject: [routing-wg] BGP Update Report In-Reply-To: <74721.1318789556@turing-police.cc.vt.edu> References: <20111015163007.4e39086c@milhouse> <20111016093913.4be3ca39@milhouse> <74721.1318789556@turing-police.cc.vt.edu> Message-ID: <20111016143210.0e6274dc@milhouse> On Sun, 16 Oct 2011 14:25:56 -0400 Valdis.Kletnieks at vt.edu wrote: > On Sun, 16 Oct 2011 09:39:13 EDT, John Peach said: > > not really, given that he is not the sender, the mailing list is.... > > We want to get pedantic, who generated the Message-ID: for the > mail in question? ;) I had no intentions of being pedantic; just pointing out that once the mail had gone to the mailing list there was no need to ever accept it back again.... -- John From Valdis.Kletnieks at vt.edu Sun Oct 16 13:56:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 16 Oct 2011 14:56:29 -0400 Subject: The Cidr Report In-Reply-To: Your message of "Sun, 16 Oct 2011 10:06:10 EDT." References: Message-ID: <75824.1318791389@turing-police.cc.vt.edu> On Sun, 16 Oct 2011 10:06:10 EDT, "William F. Maton Sotomayor" said: > A similar thing was done at a USENIX in Monterey over a decade ago. The > point behind that one was to drive home how bad it was for the attendees > to use telnet to their boxes at the mothership. Nothing like seeing > people watch their passwords put up on two screens to teach them about > SSH. Did something similar at a SANS-EDU class a few years back, maybe 300 or so attendees. The first morning, I ran several carefully crafted tcpdumps on the wireless network to get just the SYN packets for telnet, ssh, rlogin/rsh, and POP in cleartext and over SSL. Then just before class started up after lunch, I announced the counts (was about 1/3 encrypted, 2/3 cleartext). When the slide with the numbers hit the screen, a predictable 2/3 suddenly got outraged "You have no right to grab our passwords/ that's irresponsible behaior for a security professional/ etc". So I joked "See Randy, I *told* you we wouldn't have to map from IP to MAC to conference registration to tell who they were" which didn't help matters much. ;) Then I tell them that yes, it *would* be irresponsible for me to snarf passwords, so I only grabbed SYN packets. The room got quiet, till I added "but those random people sitting out in the atrium aren't security professionals, and we have no control over whether they grab passwords or not, so you probably want to change your passwords." Sudden flurry of typing from 2/3 of the people. "Over a secure channel, of course". Sudden lack of typing and a lot of deer-in-headlights looks, and one voice from the back of the room "Well played" ;) -------------- 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 namor.ca Sun Oct 16 17:19:41 2011 From: nanog at namor.ca (J) Date: Sun, 16 Oct 2011 17:19:41 -0500 Subject: Apple updates - Akamai effect In-Reply-To: References: Message-ID: <4E9B587D.5060100@namor.ca> Baskett, Andrew wrote: > Hi J, > > As Patrick mentioned, on-net private Akamai clusters should not be serving > out of your network unless you desire them to or there is a configuration > mistake. > > There is a small caveat; we direct users by which DNS they use and not by > end user IP address. So if a user has switched ISPs and not updated their > DNS, they could still be directed to the previous ISP's on-net cluster. > Of course, this would be viewed as serving offnet but usually makes up a > very small % of traffic (think <1%) > > Unfortunately, Akamai has no control over this aspect but ISPs have a few > options to mitigate it. > > If you can let me know more info about what you are seeing, we would be > happy to investigate & help further. > > Thanks, > > Andrew Baskett > Senior Network Support - Akamai Technologies - Cambridge, MA USA > 888-421-1003 or +1-617-444-0089 - netsupport-tix at akamai.com > http://www.akamai.com Andrew, Actually, I've already been talking to you somewhat about our upgrades in the area, I believe. I'm mostly curious about what the user impact is on the cluster and link upgrades in terms of experience when that happens. This seems to be a common progression, so I'm curious ahead of time. > ---------- Forwarded message ---------- > From: "Patrick W. Gilmore" > To: North American Operators' Group > Date: Sat, 15 Oct 2011 20:43:20 -0400 > Subject: Re: Apple updates - Akamai effect > On Oct 15, 2011, at 20:06, J wrote: >> Simon Leinen wrote: > >>> Guess it was a good idea to upgrade that Akamai cluster's uplink to >>> 10GE, even though 2*GE (or was it 4*GE) looked sufficient at the time. >>> Remember folks, "overprovisioning" is a misnomer, it should be called >>> "provisioning for robustness and growth". >> If I may change the thrust a bit, this is of interest to me. >> >> Just because we're in the midst of similar - changing from 2xGE to 10GE >> and >> increasing the number of Akamai nodes. >> >> Anyone have similar stats on that sort of conversion, and what to expect? >> From what I can tell, there's a fair bit of local, off-net traffic >> coming to >> ours, so I'm curious what the turn-up may look like. > > It sounds like you have what Akamai calls an "AANP" deployment. In > general, that should not serve users outside your network. There are > reasons it can, and you should talk to Akamai about it if you think it is. > > If you have questions about an on-net node, feel free to email Akamai's > Network Support group, NetSupport at akamai.com. They are only M-F, but they > can answer any questions you have. > > -- > TTFN, > patrick From leo.vegoda at icann.org Mon Oct 17 09:31:41 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 17 Oct 2011 07:31:41 -0700 Subject: Weekly Routing Table Report In-Reply-To: <4E989063.9010201@kenweb.org> References: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> <4E989063.9010201@kenweb.org> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341837800EE835@EXVPMBX100-1.exc.icann.org> ML Wrote; > On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote: [...] > > Prefixes from private and non-routed address space (Global) > > ----------------------------------------------------------- > > > > Prefix Origin AS Description > > 128.0.80.0/24 30977 JSC "Yugra-Telecom" > > 128.0.81.0/24 30977 JSC "Yugra-Telecom" > > 128.0.82.0/24 30977 JSC "Yugra-Telecom" > > 128.0.83.0/24 30977 JSC "Yugra-Telecom" > > 128.0.84.0/24 30977 JSC "Yugra-Telecom" > > 128.0.85.0/24 30977 JSC "Yugra-Telecom" > > 128.0.86.0/24 30977 JSC "Yugra-Telecom" > > 128.0.87.0/24 30977 JSC "Yugra-Telecom" This one seems to be an error. 128.0.80/21 appears to have been allocated on 5 October, nine days before the report was generated. [...] > Maybe I'm just not in the know on this but if these prefixes/ASes > shouldn't be seen on the internet, shouldn't there be more of a public > flogging to remove them? The report is not 100% accurate. Some of the resources listed do appear to be used without being registered but not all of them. Regards, Leo From sylvie at newnog.org Mon Oct 17 10:36:20 2011 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Mon, 17 Oct 2011 11:36:20 -0400 Subject: [NANOG-announce] Program Committee Appointments Announcement Message-ID: The Board has completed the Program Committee selection process. This year, eighteen members submitted their candidacies for eight available positions. We want to thank each and every one of them for considering this important service to our community and encourage them to try for the next selection cycle. We are pleased to announce the two-year term appointment of Jim Cowie, Igor Gashinsky, Greg Hankins, Manish Karir, Mohit Lad, Dani Roisman, Michael Sinatra and Tony Tauber to the Program Committee. We also want to thank and recognize the contribution of Cathy Aronson, Barry Greene, Chris Morrow and Sonia Sakovich for their service on the 2009-2011 Program Committtees. In the coming weeks, the new Program Committee will hold its first meeting and select a Chair and a Vice-Chair. On behalf of the Board, Sylvie LaPerriere NANOG Chair -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From eesslinger at fpu-tn.com Tue Oct 18 09:13:54 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 18 Oct 2011 09:13:54 -0500 Subject: Dnssec and ptr records Message-ID: Quick question for those who have researched things more closely. I have signed all my forward zones and think I've crossed my I's and dotted my T's, but one thing I'm not sure of... Are we supposed to setup signing for reverse dns zones? __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From randy at psg.com Tue Oct 18 09:15:41 2011 From: randy at psg.com (Randy Bush) Date: Tue, 18 Oct 2011 07:15:41 -0700 Subject: Dnssec and ptr records In-Reply-To: References: Message-ID: > Are we supposed to setup signing for reverse dns zones? yes From regnauld at nsrc.org Tue Oct 18 09:18:17 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 18 Oct 2011 16:18:17 +0200 Subject: Dnssec and ptr records In-Reply-To: References: Message-ID: <20111018141817.GA27779@macbook.bluepipe.net> Eric J Esslinger (eesslinger) writes: > Quick question for those who have researched things more closely. I have signed all my forward zones and think I've crossed my I's and dotted my T's, but one thing I'm not sure of... > > Are we supposed to setup signing for reverse dns zones? Hi Eric, Let me reverse the question: why wouldn't you ? Cheers, Phil From eesslinger at fpu-tn.com Tue Oct 18 09:21:54 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 18 Oct 2011 09:21:54 -0500 Subject: Dnssec and ptr records In-Reply-To: <20111018141817.GA27779@macbook.bluepipe.net> Message-ID: > -----Original Message----- > From: Phil Regnauld [mailto:regnauld at nsrc.org] > Sent: Tuesday, October 18, 2011 9:18 AM > To: Eric J Esslinger > Cc: 'nanog at nanog.org' > Subject: Re: Dnssec and ptr records > > > Eric J Esslinger (eesslinger) writes: > > Quick question for those who have researched things more closely. I > > have signed all my forward zones and think I've crossed my I's and > > dotted my T's, but one thing I'm not sure of... > > > > Are we supposed to setup signing for reverse dns zones? > > Hi Eric, > > Let me reverse the question: why wouldn't you ? > > Cheers, > Phil Well it makes sense we should, just that all the examples, discussion, and such I've read dealt with forward records. I guess I get to dig some more. Thanks. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From bmanning at vacation.karoshi.com Tue Oct 18 09:35:47 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 18 Oct 2011 14:35:47 +0000 Subject: Dnssec and ptr records In-Reply-To: References: Message-ID: <20111018143547.GB3342@vacation.karoshi.com.> On Tue, Oct 18, 2011 at 09:13:54AM -0500, Eric J Esslinger wrote: > Quick question for those who have researched things more closely. I have signed all my forward zones and think I've crossed my I's and dotted my T's, but one thing I'm not sure of... > > Are we supposed to setup signing for reverse dns zones? > > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > you should practice the same diligence with all your DNS zones, either sign all of them or none of them. /bill From Ed.Lewis at neustar.biz Tue Oct 18 09:40:48 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 18 Oct 2011 10:40:48 -0400 Subject: Dnssec and ptr records In-Reply-To: References: Message-ID: At 9:13 -0500 10/18/11, Eric J Esslinger wrote: >Are we supposed to setup signing for reverse dns zones? To the DNS, a zone is a zone. The terms "forward" and "reverse" as zone adjectives were invented by humans. ;) The high-level view of signing the "reverse zones" is the same as for "forward zones." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From jcurran at arin.net Tue Oct 18 11:31:57 2011 From: jcurran at arin.net (John Curran) Date: Tue, 18 Oct 2011 16:31:57 +0000 Subject: Dnssec and ptr records In-Reply-To: References: Message-ID: <40D00D35-DFEB-4E8B-A5F4-D98E00684E65@arin.net> On Oct 18, 2011, at 10:21 AM, Eric J Esslinger wrote: > Well it makes sense we should, just that all the examples, discussion, and such I've read dealt with forward records. > > I guess I get to dig some more. Thanks. Eric - Your in-addr zone first needs to be signed and then the DS records are put in the parent in-addr zone to link into the signed IN-ADDR.ARPA hierarchy. In the ARIN region, this can be done via the DNSSEC DS record management in ARIN Online or via the RESTful provisioning interface. ARIN DNSSEC Project overview: https://www.arin.net/resources/dnssec/ ARIN Online/DNSEC Tutorials: https://www.arin.net/knowledge/dnssec/index.html FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Tue Oct 18 11:56:07 2011 From: jcurran at arin.net (John Curran) Date: Tue, 18 Oct 2011 16:56:07 +0000 Subject: Dnssec and ptr records In-Reply-To: <40D00D35-DFEB-4E8B-A5F4-D98E00684E65@arin.net> References: <40D00D35-DFEB-4E8B-A5F4-D98E00684E65@arin.net> Message-ID: <95D3A3D2-7A0F-4DF5-90BF-68A7C0158D41@arin.net> (Presuming, of course, that you've got an ARIN assignment or allocation. If you're in a provider-assigned block, you'll need to chat with your ISP about the DS linkage for your PTR zones... /John ) On Oct 18, 2011, at 12:31 PM, John Curran wrote: > On Oct 18, 2011, at 10:21 AM, Eric J Esslinger wrote: > >> Well it makes sense we should, just that all the examples, discussion, and such I've read dealt with forward records. >> >> I guess I get to dig some more. Thanks. > > Eric - > > Your in-addr zone first needs to be signed and then the DS > records are put in the parent in-addr zone to link into the > signed IN-ADDR.ARPA hierarchy. In the ARIN region, this can > be done via the DNSSEC DS record management in ARIN Online or > via the RESTful provisioning interface. > > ARIN DNSSEC Project overview: https://www.arin.net/resources/dnssec/ > ARIN Online/DNSEC Tutorials: https://www.arin.net/knowledge/dnssec/index.html > > FYI, > /John > > John Curran > President and CEO > ARIN > > From eesslinger at fpu-tn.com Tue Oct 18 12:12:23 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 18 Oct 2011 12:12:23 -0500 Subject: Dnssec and ptr records In-Reply-To: <95D3A3D2-7A0F-4DF5-90BF-68A7C0158D41@arin.net> Message-ID: > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, October 18, 2011 11:56 AM > To: Eric J Esslinger > Cc: nanog at nanog.org Operators' Group > Subject: Re: Dnssec and ptr records > > > (Presuming, of course, that you've got an ARIN assignment > or allocation. If you're in a provider-assigned block, > you'll need to chat with your ISP about the DS linkage > for your PTR zones... /John ) > > On Oct 18, 2011, at 12:31 PM, John Curran wrote: > > On Oct 18, 2011, at 10:21 AM, Eric J Esslinger wrote: > > > >> Well it makes sense we should, just that all the examples, > >> discussion, and such I've read dealt with forward records. > >> > >> I guess I get to dig some more. Thanks. > > > > Eric - > > > > Your in-addr zone first needs to be signed and then the DS > > records are put in the parent in-addr zone to link into the > > signed IN-ADDR.ARPA hierarchy. In the ARIN region, this can > > be done via the DNSSEC DS record management in ARIN Online or > > via the RESTful provisioning interface. > > > > ARIN DNSSEC Project overview: > https://www.arin.net/resources/dnssec/ > > ARIN Online/DNSEC Tutorials: > > https://www.arin.net/knowledge/dnssec/index.html > > > > FYI, > > /John > > > > John Curran > > President and CEO > > ARIN > > Thank you. That gives me information to work with, and I now have a solid understanding of what I need to do for the proper delegation setup. I'll have to talk to my current ISP for the blocks I currently have, though I don't believe they do dnssec at this time. I am expecting to get an Arin allocation shortly (and return their existing allocations to us) as we are going multihomed soon. I may just have to wait till then to get everything fully setup. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From bpasdar at batblue.com Tue Oct 18 16:03:46 2011 From: bpasdar at batblue.com (Babak Pasdar) Date: Tue, 18 Oct 2011 17:03:46 -0400 Subject: Microsoft Job Poaching on NANOG Message-ID: <20111018210346.92419c91@concur.batblue.com> Is Microsoft trying to poach people off the NANOG list? IMHO this is inappropriate. Babak _____ From: Liz Morgan [mailto:hit-reply at linkedin.com] To: Babak Pasdar [mailto:bpasdar at BatBlue.com] Sent: Tue, 18 Oct 2011 16:54:00 -0400 Subject: Thank you from the Global Foundation Services team and Microsoft! Babak, We hope everyone enjoyed the NANOG conference and Microsoft's event at Triumph Brewery last Monday night! The Global Foundation Services staffing team would like to offer you a chance to sign up for our networking talent community. This allows you to stay on top of the latest networking job opportunities within this team. This is an online service that delivers jobs to your inbox on a monthly basis. Click here:http://bit.ly/gfsjobs and go to the upper right hand corner. Find the orange box that says "talent network." See you at the next NANOG! The NANOG/Staffing Event team Reply Not interested View Liz's LinkedIn profile Don't want to receive e-mail notifications? Adjust your message settings. ? 2011, LinkedIn Corporation -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Networks (p) 212.461.3322 x3005 | (f) 212.584.9999 | www.BatBlue.com Bat Blue's AS: 25885 | BGP Policy | Peering Policy Watch: Cloud Security Video | Cloud Network Video The Official WiFi Provider for ESPN's X Games From james.cutler at consultant.com Tue Oct 18 16:06:04 2011 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 18 Oct 2011 17:06:04 -0400 Subject: Microsoft Job Poaching on NANOG In-Reply-To: <20111018210346.92419c91@concur.batblue.com> References: <20111018210346.92419c91@concur.batblue.com> Message-ID: Since the message in question was not seen on the full list, it probably came from the MS event attendance list. On Oct 18, 2011, at 5:03 PM, Babak Pasdar wrote: > Is Microsoft trying to poach people off the NANOG list? IMHO this is inappropriate. > > Babak > > _____ > > From: Liz Morgan [mailto:hit-reply at linkedin.com] > To: Babak Pasdar [mailto:bpasdar at BatBlue.com] > Sent: Tue, 18 Oct 2011 16:54:00 -0400 > Subject: Thank you from the Global Foundation Services team and Microsoft! > > > Babak, > > We hope everyone enjoyed the NANOG conference and Microsoft's event at Triumph Brewery last Monday night! > > The Global Foundation Services staffing team would like to offer you a chance to sign up for our networking talent community. This allows you to stay on top of the latest networking job opportunities within this team. This is an online service that delivers jobs to your inbox on a monthly basis. > > Click here:http://bit.ly/gfsjobs and go to the upper right hand corner. Find the orange box that says "talent network." > > See you at the next NANOG! > > The NANOG/Staffing Event team > > > > > > > > > Reply > > > > > > > > Not interested > > > > > > View Liz's LinkedIn profile > > > > > > > > > > Don't want to receive e-mail notifications? Adjust your message settings. > > > > ? 2011, LinkedIn Corporation > > -- > Babak Pasdar > President & CEO | Certified Ethical Hacker > Bat Blue Networks > (p) 212.461.3322 x3005 | (f) 212.584.9999 | www.BatBlue.com > > Bat Blue's AS: 25885 | BGP Policy | Peering Policy > > Watch: Cloud Security Video | Cloud Network Video > > The Official WiFi Provider for ESPN's X Games From fearghas at gmail.com Tue Oct 18 16:07:52 2011 From: fearghas at gmail.com (Fearghas McKay) Date: Tue, 18 Oct 2011 22:07:52 +0100 Subject: Microsoft Job Poaching on NANOG In-Reply-To: References: <20111018210346.92419c91@concur.batblue.com> Message-ID: <37F95662-7AD7-412C-904A-301A35644F11@gmail.com> On 18 Oct 2011, at 22:06, Cutler James R wrote: > Since the message in question was not seen on the full list, it probably came from the MS event attendance list. and they were quite open at the event about wanting contact details for recruitment purposes... f From brett at the-watsons.org Tue Oct 18 22:02:33 2011 From: brett at the-watsons.org (Brett Watson) Date: Tue, 18 Oct 2011 23:02:33 -0400 Subject: Microsoft Job Poaching on NANOG In-Reply-To: <20111018210346.92419c91@concur.batblue.com> References: <20111018210346.92419c91@concur.batblue.com> Message-ID: <5E1BB4E2-0650-4AF3-B66B-7100CC62A68E@the-watsons.org> On Oct 18, 2011, at 5:03 PM, Babak Pasdar wrote: > Is Microsoft trying to poach people off the NANOG list? IMHO this is inappropriate. There's a lot more than just MS doing it after this NANOG, and it's damned annoying. I've had it happen over the years just a few times, but it's unprecedented this year, as far as I'm concerned (and did I mentioned damned annoying?). -b From jbates at brightok.net Tue Oct 18 22:18:49 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Oct 2011 22:18:49 -0500 Subject: Microsoft Job Poaching on NANOG In-Reply-To: <5E1BB4E2-0650-4AF3-B66B-7100CC62A68E@the-watsons.org> References: <20111018210346.92419c91@concur.batblue.com> <5E1BB4E2-0650-4AF3-B66B-7100CC62A68E@the-watsons.org> Message-ID: <4E9E4199.7080301@brightok.net> On 10/18/2011 10:02 PM, Brett Watson wrote: > There's a lot more than just MS doing it after this NANOG, and it's > damned annoying. I've had it happen over the years just a few times, > but it's unprecedented this year, as far as I'm concerned (and did I > mentioned damned annoying?). -b That's why you don't tell people your info. It has predictable results like using telnet to access your stuff at NANOG. Don't tell me no one did it; although I never understood why they didn't just block tcp/23 to protect the crazy. :) Or did they, this year? Jack From nccariaga at stluke.com.ph Wed Oct 19 01:46:14 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 19 Oct 2011 14:46:14 +0800 Subject: BGP Peers as basis of available routes Message-ID: <4E9E7236.5000403@stluke.com.ph> Hi! We're currently evaluating web hosting providers in the APAC region and one of the criteria that we are currently considering is the availability of routes going to the web hosting provider. In this regard, I would like to ask for your idea regarding this. Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) Thanks. -- -nathan From raymond at prolocation.net Wed Oct 19 02:00:36 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 19 Oct 2011 09:00:36 +0200 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7236.5000403@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> Message-ID: Hi! Dont mix up peering and transit connections! That you dont see that route on a lookingglass doesnt mean much. Only Could tell you they dont transit there. Its all depending what you defini?ren with available routes. If i peer with all ISP's in a specific area and your looking glass isnt licated there does that mean its bad? You need to know much more. If your customers are local there its even prefered. Its never that black/white ...its depending on your needs! Thanks, Raymond Dijkxhoorn, Prolocation Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: > Hi! > > We're currently evaluating web hosting providers in the APAC region and one of the criteria that we are currently considering is the availability of routes going to the web hosting provider. > > In this regard, I would like to ask for your idea regarding this. Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) > > Thanks. > > > -- > -nathan From nccariaga at stluke.com.ph Wed Oct 19 02:21:27 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 19 Oct 2011 15:21:27 +0800 Subject: BGP Peers as basis of available routes In-Reply-To: References: <4E9E7236.5000403@stluke.com.ph> Message-ID: <4E9E7A77.5010109@stluke.com.ph> Hi. Thanks for the prompt response. Actually our requirement is to find a webhosting provider whose routes are widely advertised locally and regionally. This is why I thought of using bgp as a basis studying the availability of routes of the hosting provider. -nathan On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote: > Hi! > > Dont mix up peering and transit connections! > > That you dont see that route on a lookingglass doesnt mean much. Only Could tell you they dont transit there. > > Its all depending what you defini?ren with available routes. > > If i peer with all ISP's in a specific area and your looking glass isnt licated there does that mean its bad? You need to know much more. If your customers are local there its even prefered. > > Its never that black/white ...its depending on your needs! > > Thanks, > Raymond Dijkxhoorn, Prolocation > > > Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: > >> Hi! >> >> We're currently evaluating web hosting providers in the APAC region and one of the criteria that we are currently considering is the availability of routes going to the web hosting provider. >> >> In this regard, I would like to ask for your idea regarding this. Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) >> >> Thanks. >> >> >> -- >> -nathan From raymond at prolocation.net Wed Oct 19 02:20:04 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 19 Oct 2011 09:20:04 +0200 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7A77.5010109@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> <4E9E7A77.5010109@stluke.com.ph> Message-ID: Hi! You wont see those local peerings unless all those providers have looking glasses. So thats not gonna work out in this case. You will only see who they transit with... Thanks, Raymond Dijkxhoorn, Prolocation Op 19 okt. 2011 om 09:21 heeft "Nathanael C. Cariaga" het volgende geschreven: > Hi. > > Thanks for the prompt response. Actually our requirement is to find a webhosting provider whose routes are widely advertised locally and regionally. This is why I thought of using bgp as a basis studying the availability of routes of the hosting provider. > > > -nathan > > On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote: >> Hi! >> >> Dont mix up peering and transit connections! >> >> That you dont see that route on a lookingglass doesnt mean much. Only Could tell you they dont transit there. >> >> Its all depending what you defini?ren with available routes. >> >> If i peer with all ISP's in a specific area and your looking glass isnt licated there does that mean its bad? You need to know much more. If your customers are local there its even prefered. >> >> Its never that black/white ...its depending on your needs! >> >> Thanks, >> Raymond Dijkxhoorn, Prolocation >> >> >> Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: >> >>> Hi! >>> >>> We're currently evaluating web hosting providers in the APAC region and one of the criteria that we are currently considering is the availability of routes going to the web hosting provider. >>> >>> In this regard, I would like to ask for your idea regarding this. Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) >>> >>> Thanks. >>> >>> >>> -- >>> -nathan From nccariaga at stluke.com.ph Wed Oct 19 02:35:04 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Wed, 19 Oct 2011 15:35:04 +0800 Subject: BGP Peers as basis of available routes In-Reply-To: References: <4E9E7236.5000403@stluke.com.ph> <4E9E7A77.5010109@stluke.com.ph> Message-ID: <4E9E7DA8.5060904@stluke.com.ph> Ok. Thanks for the information :) So that would mean that to answer my question, I would need to determine the web hosting provider who has the most number of peers and most number of transit providers? -nathan On 10/19/2011 3:20 PM, Raymond Dijkxhoorn wrote: > Hi! > > You wont see those local peerings unless all those providers have looking glasses. So thats not gonna work out in this case. You will only see who they transit with... > > Thanks, > Raymond Dijkxhoorn, Prolocation > > > Op 19 okt. 2011 om 09:21 heeft "Nathanael C. Cariaga" het volgende geschreven: > >> Hi. >> >> Thanks for the prompt response. Actually our requirement is to find a webhosting provider whose routes are widely advertised locally and regionally. This is why I thought of using bgp as a basis studying the availability of routes of the hosting provider. >> >> >> -nathan >> >> On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote: >>> Hi! >>> >>> Dont mix up peering and transit connections! >>> >>> That you dont see that route on a lookingglass doesnt mean much. Only Could tell you they dont transit there. >>> >>> Its all depending what you defini?ren with available routes. >>> >>> If i peer with all ISP's in a specific area and your looking glass isnt licated there does that mean its bad? You need to know much more. If your customers are local there its even prefered. >>> >>> Its never that black/white ...its depending on your needs! >>> >>> Thanks, >>> Raymond Dijkxhoorn, Prolocation >>> >>> >>> Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: >>> >>>> Hi! >>>> >>>> We're currently evaluating web hosting providers in the APAC region and one of the criteria that we are currently considering is the availability of routes going to the web hosting provider. >>>> >>>> In this regard, I would like to ask for your idea regarding this. Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) >>>> >>>> Thanks. >>>> >>>> >>>> -- >>>> -nathan From raymond at prolocation.net Wed Oct 19 02:38:21 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 19 Oct 2011 09:38:21 +0200 (CEST) Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7DA8.5060904@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> <4E9E7A77.5010109@stluke.com.ph> <4E9E7DA8.5060904@stluke.com.ph> Message-ID: Hi! > Ok. Thanks for the information :) So that would mean that to answer my > question, I would need to determine the web hosting provider who has the most > number of peers and most number of transit providers? >> You wont see those local peerings unless all those providers have looking >> glasses. So thats not gonna work out in this case. You will only see who >> they transit with... I cant answer that, only you can. If that hosting provider has many peers but your customers are not behind them its of no use. But generally a hosting provider with many local peers, either public or private -might have- ok connections ;) For example if they private peer with 10 mbps and the other one has 10 gbps public peering... There isnt a real answer to your question. Its based on your own buisiness needs and decisions on those. Bye, Raymond. From thilo.bangert at gmail.com Wed Oct 19 03:03:51 2011 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Wed, 19 Oct 2011 10:03:51 +0200 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7DA8.5060904@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> <4E9E7DA8.5060904@stluke.com.ph> Message-ID: <201110191003.51247.thilo.bangert@gmail.com> On Wednesday, October 19, 2011 09:35:04 AM Nathanael C. Cariaga wrote: > Ok. Thanks for the information :) So that would mean that to answer my > question, I would need to determine the web hosting provider who has the > most number of peers and most number of transit providers? > what i found usefull is to check the autnum objects in whois, as many document their peerings and transits there. robtex has also some of this info, in a webinterface... also helpful was peeringdb - you can lookup indvidual ASs without logging in like this http://as.peeringdb.com/ it may give you an indication as to which exchanges your (potential) provider is present at - though not all providers have a / maintain their peeringdb record. HTH kind regards Thilo > -nathan > > On 10/19/2011 3:20 PM, Raymond Dijkxhoorn wrote: > > Hi! > > > > You wont see those local peerings unless all those providers have looking > > glasses. So thats not gonna work out in this case. You will only see who > > they transit with... > > > > Thanks, > > Raymond Dijkxhoorn, Prolocation > > > > Op 19 okt. 2011 om 09:21 heeft "Nathanael C. Cariaga" het volgende geschreven: > >> Hi. > >> > >> Thanks for the prompt response. Actually our requirement is to find a > >> webhosting provider whose routes are widely advertised locally and > >> regionally. This is why I thought of using bgp as a basis studying the > >> availability of routes of the hosting provider. > >> > >> > >> -nathan > >> > >> On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote: > >>> Hi! > >>> > >>> Dont mix up peering and transit connections! > >>> > >>> That you dont see that route on a lookingglass doesnt mean much. Only > >>> Could tell you they dont transit there. > >>> > >>> Its all depending what you defini?ren with available routes. > >>> > >>> If i peer with all ISP's in a specific area and your looking glass isnt > >>> licated there does that mean its bad? You need to know much more. If > >>> your customers are local there its even prefered. > >>> > >>> Its never that black/white ...its depending on your needs! > >>> > >>> Thanks, > >>> Raymond Dijkxhoorn, Prolocation > >>> > >>> Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: > >>>> Hi! > >>>> > >>>> We're currently evaluating web hosting providers in the APAC region > >>>> and one of the criteria that we are currently considering is the > >>>> availability of routes going to the web hosting provider. > >>>> > >>>> In this regard, I would like to ask for your idea regarding this. Is > >>>> it safe to conclude that the web hosting provider's available routes > >>>> would would depend on the peers who are advertising their AS / > >>>> network? (i.e if web hosting provider claims that they are peering > >>>> with telco a, b, c but as seen from a third party looking glass, only > >>>> C is seen advertising the web hosting provider network that would > >>>> mean web hosting provider is effectively utilizing c as their > >>>> upstream??) > >>>> > >>>> Thanks. > >>>> > >>>> > >>>> -- > >>>> -nathan From pfsinoz at gmail.com Wed Oct 19 05:02:43 2011 From: pfsinoz at gmail.com (Philip Smith) Date: Wed, 19 Oct 2011 20:02:43 +1000 Subject: Weekly Routing Table Report In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341837800EE835@EXVPMBX100-1.exc.icann.org> References: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> <4E989063.9010201@kenweb.org> <41F6C547EA49EC46B4EE1EB2BC2F341837800EE835@EXVPMBX100-1.exc.icann.org> Message-ID: <4E9EA043.4030701@gmail.com> Hi Leo, Leo Vegoda said the following on 18/10/11 00:31 : >> >>> 128.0.87.0/24 30977 JSC "Yugra-Telecom" > > This one seems to be an error. 128.0.80/21 appears to have been allocated on 5 October, nine days before the report was generated. The report is as good as what is in the RIR allocation databases, as I grab those from the RIR public listings about 2 hours before the report is run. So if it was allocated, it wasn't listed in the file that I pick up. I'll investigate why. > The report is not 100% accurate. Some of the resources listed do appear to be used without being registered but not all of them. It is as accurate as the data I have access to. ;-) But I'd be delighted to hear suggestions for improvements. philip -- From _CC removed_ on March 22, 2012 at request of sender__ Wed Oct 19 08:13:50 2011 From: _CC removed_ on March 22, 2012 at request of sender__ Date: Wed, 19 Oct 2011 09:13:50 -0400 Subject: Outsourcing DDOS Message-ID: We are considering using Prolexic to 'defend' our Internet-facing network from DDOS attacks. Anyone have any known issues or word of warnings before we proceed? _CC removed_ on March 22, 2012 at request of sender__ From bill at herrin.us Wed Oct 19 08:27:54 2011 From: bill at herrin.us (William Herrin) Date: Wed, 19 Oct 2011 09:27:54 -0400 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7236.5000403@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> Message-ID: On Wed, Oct 19, 2011 at 2:46 AM, Nathanael C. Cariaga wrote: > In this regard, ?I would like to ask for your idea regarding this. ?Is it > safe to conclude that the web hosting provider's available routes would > would depend on the peers who are advertising their AS / network? ?(i.e if > web hosting provider claims that they are peering with telco a, b, c but as > seen from a third party looking glass, only C is seen advertising the web > hosting provider network that would mean web hosting provider is effectively > utilizing c as their upstream??) Hi Nathan, BGP is a distance-vector protocol. In other words, when BGP is advertised on a link from one AS to another, only the "best" distance to a particular route is offered. If A and B both advertise the web hosting provider's (WHP's) route to D and A's distance is better then D won't advertise B's WHP route to A but it will advertise A's WHP route to B. Thus a looking glass at B will see both routes in the BGP RIB, but a looking glass at A will only see A's route. With more AS's between A and B than just D, it's possible (even likely) that neither A nor B will see the others' route during normal operation. Should WHP's connection to A drop, D will find that B's distance is now better and B's route to WHP will be newly advertised to A. A, then having no other connection to WHP, will accept the route via D to B, and pass it onward. When we talk about the BGP table "converging" after a change, this is the process we're talking about. Even if A and B are directly connected, if WHP sets its initial "distance" via B worse than via A, B will decide that A has a better distance to WHP and won't advertise its own version of the route to anyone else at all. And that's before you consider local prefs, communities and other mechanisms for fine-tuning route propagation. And, even if A, B and C have multiple routes in the BGP RIB, generally only one of those routes will be selected for the packet forwarding FIB. So, a traceroute from B to WHP may travel via A even though B is directly connected to WHP. Long story short, if WHP is connected to A, B and C then A, B and C should each see their own direct route to WHP in the BGP RIB, but there's no guarantee that anybody else will see more than one of the three at any given time. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From galu at packetdam.com Wed Oct 19 08:46:42 2011 From: galu at packetdam.com (Vlad Galu) Date: Wed, 19 Oct 2011 15:46:42 +0200 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: On Oct 19, 2011, at 3:13 PM, _CC removed_ on March 22, 2012 at request of sender__ wrote: > We are considering using Prolexic to 'defend' our Internet-facing network from DDOS attacks. Anyone have any known issues or word of warnings before we proceed? > They say that "When an attack is detected, our protection services are implemented within minutes. Upon activation, a Prolexic customer routes in-bound traffic to the nearest Prolexic scrubbing center where proprietary-filtering techniques, advanced routing, and patent-pending hardware devices remove bot traffic close to the source." You may want to ask them how near is "nearest" before you proceed. If their sensor is too far from your systems, simply sending all that traffic to the scrubbing center could be overkill. The last phrase suggests they use sink holing, though. -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com From randy at psg.com Wed Oct 19 11:03:33 2011 From: randy at psg.com (Randy Bush) Date: Wed, 19 Oct 2011 09:03:33 -0700 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7DA8.5060904@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> <4E9E7A77.5010109@stluke.com.ph> <4E9E7DA8.5060904@stluke.com.ph> Message-ID: > Ok. Thanks for the information :) So that would mean that to answer my > question, I would need to determine the web hosting provider who has > the most number of peers and most number of transit providers? if i was choosing a hosting provider, many other considerations would come before this randy From woody at pch.net Wed Oct 19 11:53:15 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 19 Oct 2011 09:53:15 -0700 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9E7236.5000403@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> Message-ID: <69A249CE-D3F9-4B93-AE88-2C6208E2DA2C@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Oct 18, 2011, at 11:46 PM, Nathanael C. Cariaga wrote: > Is it safe to conclude that the web hosting provider's available routes would would depend on the peers who are advertising their AS / network? (i.e if web hosting provider claims that they are peering with telco a, b, c but as seen from a third party looking glass, only C is seen advertising the web hosting provider network that would mean web hosting provider is effectively utilizing c as their upstream??) Modulo a lot of nit-picking caveats, this would indicate that they are purchasing transit from C, while they may or may not be peering with A and B. If a customer of A or B is able to reach them in a single AS-hop, but A and B are not advertising a route to C to looking-glasses or their own peers or transit providers, then A and B are peers, but not transit providers, to the web host. > I would need to determine the web hosting provider who has the most number of peers and most number of transit providers? A large number of transit providers has been shown, both theoretically and experimentally, to _decrease_ uptime, because of greater route-convergence times when there are more parallel paths to a destination. Your mileage may vary, but the optimum number is usually somewhere around three transit providers. The number of peers, though, and more to the point, the number of routes acquired through peering, is an excellent measure of how large and how long an ISP (in this case a web-hoster) has been in business. That shouldn't be your only measure of quality, however. It may be that reliability of power, competence of remote-hands, and flexibility to accommodate your needs are more important than how the packets get delivered. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJOnwB7AAoJEG+kcEsoi3+H4hEQAKecuMs/sXjXMqpuGaZ/I4+W ZZze/q/pmQskfrJ8l2lWkiv+h0YUlcR9uBEJALmsAZMLwtZwlWPBWO7EgHBXbhFr rA++bM6cjyX8NHER2eAtjmp9ERL4pOV3CoIz6WlMJEfuETmF2equoyFN1yoRRJCm x87HeXBkK3vram37eZx90GYXOnnlqqYkTTwoU6BqGU1aFQ1WmCr6udZ8+PDU1f55 xpSsU4OdQv+KjIVsUvaAuBVOAozZ2PO7VP8Lx1FGMuR7yFziliK1GYmlF7CVB6Aw rvZJNPPXQHx74FBWqmGSQrq3slrE++6vUKUvylr4Rz3oV5B/JXFgzgFTVyTtD63B Fl8zkuSFLXgiot8wMVJXo0XHCHbt8kLelBdVooKULgiNxh9UznxcELiB0/M6bBF0 wos2sr56MxwHKneY+yek+CJ9lC5teh+e37r/Lup8PK3JBzYMCA81/uKaFxFTQLWA YNRzudJ3W1kOmwvtkBUPISX1hGBLgzrREmm+2DXQrC4lWSgKsH4p+lyHnx3TR0vv ZRsgUQ9ErBAKYd303bP8Z1KBlK7EkTKBr4FsK0lQcikDR3NArMXTCi4x6WSZkiqZ 9xixEa3rIuI7UwsgFIZibKHK15PunoCQSZQnEF8lKeqWbSsLbKQ3icVP7zBgOB8J ycKYwKtsWQc2ayyvpWs2 =zi6u -----END PGP SIGNATURE----- From lorell at hathcock.org Wed Oct 19 12:15:55 2011 From: lorell at hathcock.org (Lorell Hathcock) Date: Wed, 19 Oct 2011 12:15:55 -0500 Subject: 4.2.2.2 acting up? or is it just me? Message-ID: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> All: I am experiencing trouble with reaching 4.2.2.2 right now from my netblock. ASN 23077. Is it just me or are others experiencing the same thing? Thanks, Lorell From nickellman at gmail.com Wed Oct 19 12:19:02 2011 From: nickellman at gmail.com (brian nikell) Date: Wed, 19 Oct 2011 11:19:02 -0600 Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> References: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> Message-ID: same On Wed, Oct 19, 2011 at 11:15 AM, Lorell Hathcock wrote: > All: > > > > I am experiencing trouble with reaching 4.2.2.2 right now from my netblock. > ASN 23077. > > > > Is it just me or are others experiencing the same thing? > > > > Thanks, > > > > Lorell > > > > > > -- -B From keegan.holley at sungard.com Wed Oct 19 12:28:35 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 19 Oct 2011 13:28:35 -0400 Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: References: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> Message-ID: I can hit it from home (comcast) and from my company's network. 2011/10/19 brian nikell > same > > On Wed, Oct 19, 2011 at 11:15 AM, Lorell Hathcock >wrote: > > > All: > > > > > > > > I am experiencing trouble with reaching 4.2.2.2 right now from my > netblock. > > ASN 23077. > > > > > > > > Is it just me or are others experiencing the same thing? > > > > > > > > Thanks, > > > > > > > > Lorell > > > > > > > > > > > > > > > -- > -B > > From nickellman at gmail.com Wed Oct 19 12:40:32 2011 From: nickellman at gmail.com (brian nikell) Date: Wed, 19 Oct 2011 11:40:32 -0600 Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: References: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> Message-ID: Packet loss from AS4323 On Wed, Oct 19, 2011 at 11:30 AM, Brandon Grant wrote: > I can also hit it from ASN 40409 and 26499. > > -----Original Message----- > From: Keegan Holley [mailto:keegan.holley at sungard.com] > Sent: Wednesday, October 19, 2011 1:29 PM > To: brian nikell > Cc: nanog at nanog.org > Subject: Re: 4.2.2.2 acting up? or is it just me? > > I can hit it from home (comcast) and from my company's network. > > > 2011/10/19 brian nikell > > > same > > > > On Wed, Oct 19, 2011 at 11:15 AM, Lorell Hathcock > >wrote: > > > > > All: > > > > > > > > > > > > I am experiencing trouble with reaching 4.2.2.2 right now from my > > netblock. > > > ASN 23077. > > > > > > > > > > > > Is it just me or are others experiencing the same thing? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Lorell > > > > > > > > > > > > > > > > > > > > > > > > -- > > -B > > > > > -- -B From paul at paulgraydon.co.uk Wed Oct 19 12:45:44 2011 From: paul at paulgraydon.co.uk (Paul) Date: Wed, 19 Oct 2011 07:45:44 -1000 Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> References: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> Message-ID: <4E9F0CC8.3000801@paulgraydon.co.uk> No packet loss but I'm seeing some fairly variable performance on the penultimate hop, reaching it both from Timewarner in Hawaii and HE's fremont location: ae-31-80.car1.SanJose1.Level3.net Last: 56.2 Average:74.6 Best: 56.1 Worst: 259.3 StDev: 47.4 Paul On 10/19/2011 07:15 AM, Lorell Hathcock wrote: > All: > > > > I am experiencing trouble with reaching 4.2.2.2 right now from my netblock. > ASN 23077. > > > > Is it just me or are others experiencing the same thing? > > > > Thanks, > > > > Lorell > > > > > From jared at puck.nether.net Wed Oct 19 12:48:37 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 Oct 2011 13:48:37 -0400 Subject: BGP Peers as basis of available routes In-Reply-To: References: <4E9E7236.5000403@stluke.com.ph> Message-ID: On Oct 19, 2011, at 3:00 AM, Raymond Dijkxhoorn wrote: > Dont mix up peering and transit connections! I've nearly given up on this. I've heard many a small provider say they are "Peering" with level3 when they mean "we are buying transit from Level3". Many people equate having BGP up with them to mean something else. - Jared From matt.taber.nanog at gmail.com Wed Oct 19 12:57:16 2011 From: matt.taber.nanog at gmail.com (Matt Taber) Date: Wed, 19 Oct 2011 13:57:16 -0400 Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: <4E9F0CC8.3000801@paulgraydon.co.uk> References: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> <4E9F0CC8.3000801@paulgraydon.co.uk> Message-ID: <4E9F0F7C.1010706@gmail.com> Outages mailing list narrowed it down to something Level3 in Dallas -- anycast IPs, etc. On 10/19/2011 1:45 PM, Paul wrote: > No packet loss but I'm seeing some fairly variable performance on the > penultimate hop, reaching it both from Timewarner in Hawaii and HE's > fremont location: > > ae-31-80.car1.SanJose1.Level3.net Last: 56.2 Average:74.6 Best: 56.1 > Worst: 259.3 StDev: 47.4 > > Paul > > On 10/19/2011 07:15 AM, Lorell Hathcock wrote: >> All: >> >> >> >> I am experiencing trouble with reaching 4.2.2.2 right now from my >> netblock. >> ASN 23077. >> >> >> >> Is it just me or are others experiencing the same thing? >> >> >> >> Thanks, >> >> >> >> Lorell >> >> >> >> >> > > From jbates at brightok.net Wed Oct 19 13:20:42 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Oct 2011 13:20:42 -0500 Subject: BGP Peers as basis of available routes In-Reply-To: References: <4E9E7236.5000403@stluke.com.ph> Message-ID: <4E9F14FA.20902@brightok.net> On 10/19/2011 12:48 PM, Jared Mauch wrote: > > On Oct 19, 2011, at 3:00 AM, Raymond Dijkxhoorn wrote: > >> Dont mix up peering and transit connections! > > I've nearly given up on this. I've heard many a small provider say they are "Peering" with level3 when they mean "we are buying transit from Level3". > > Many people equate having BGP up with them to mean something else. And yet I might pay for transit from Sprint, but decide to limit routes to just between us (which is peering, but technically I'm paying for transit). Terminology has always been a blast. Jack From bmanning at vacation.karoshi.com Wed Oct 19 13:54:08 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 19 Oct 2011 18:54:08 +0000 Subject: BGP Peers as basis of available routes In-Reply-To: <4E9F14FA.20902@brightok.net> References: <4E9E7236.5000403@stluke.com.ph> <4E9F14FA.20902@brightok.net> Message-ID: <20111019185408.GB9797@vacation.karoshi.com.> On Wed, Oct 19, 2011 at 01:20:42PM -0500, Jack Bates wrote: > On 10/19/2011 12:48 PM, Jared Mauch wrote: > > > >On Oct 19, 2011, at 3:00 AM, Raymond Dijkxhoorn wrote: > > > >>Dont mix up peering and transit connections! > > > >I've nearly given up on this. I've heard many a small provider say they > >are "Peering" with level3 when they mean "we are buying transit from > >Level3". > > > >Many people equate having BGP up with them to mean something else. > > And yet I might pay for transit from Sprint, but decide to limit routes > to just between us (which is peering, but technically I'm paying for > transit). > > Terminology has always been a blast. > > > Jack actually, its pretty clear. peer - exchange routes with a neighbor (BGP/OSPF/ISIS/EGP/Static). transit - your neighbor agrees to send your routes to -their- neighbors. peering you can control, transit is controlled by a third party. so Jack, you could pay Sprint for transit (they propogte your routes elsewhere) and then insist on no-export for the routes you give them.. -IF- Sprint honours your no-export, then your just peering, regardless of what you are paying for. /bill From morrowc.lists at gmail.com Wed Oct 19 14:13:55 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Oct 2011 15:13:55 -0400 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: On Wed, Oct 19, 2011 at 9:13 AM, _CC removed_ on March 22, 2012 at request of sender__ wrote: > We are considering using Prolexic to 'defend' our Internet-facing network from DDOS attacks. ?Anyone have any known issues or word of warnings before we proceed? > you appear to be an ATT customer (and qwest) ATT has a dos-mitigation solution, it works well enough... why not just use theirs? it's guaranteed to be cheaper (in the case of an actual attack) as compared to prolexic (and closer to your actual website/presence... (since they have a scrubbing center in stl) -chris From jra at baylink.com Wed Oct 19 14:44:21 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Oct 2011 15:44:21 -0400 (EDT) Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: <001c01cc8e82$c32eab10$498c0130$@hathcock.org> Message-ID: <17754928.5426.1319053461110.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Lorell Hathcock" > I am experiencing trouble with reaching 4.2.2.2 right now from my > netblock. ASN 23077. > > Is it just me or are others experiencing the same thing? Well, it's presently reachable from Tampa: HOST: elphaba.baylink.com Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.4 1.4 1.3 1.6 0.1 2.|-- 208.38.174.194 0.0% 10 2.2 2.0 1.7 2.5 0.3 3.|-- gi2-4.border4.esnet.com 0.0% 10 1.7 2.0 1.7 2.6 0.4 4.|-- ge-6-20.car4.Tampa1.Level 0.0% 10 2.0 1.8 1.7 2.0 0.1 5.|-- ae-24-24.car2.Tampa1.Leve 0.0% 10 28.5 45.0 1.9 120.9 46.7 6.|-- ae-2-7.bar2.Tampa1.Level3 0.0% 10 1.9 2.0 1.9 2.5 0.2 7.|-- ae-12-12.ebr1.Dallas1.Lev 0.0% 10 25.8 25.8 25.5 26.7 0.4 8.|-- ae-91-91.csw4.Dallas1.Lev 0.0% 10 25.6 26.8 25.5 31.9 2.1 9.|-- ae-41-90.car1.Dallas1.Lev 0.0% 10 25.9 88.8 25.7 225.9 79.9 10.|-- vnsc-bak.sys.gtei.net 0.0% 10 26.1 26.1 25.6 27.2 0.6 But understand that all 6 of GTEI's anycast customer resolver nameservers are really intended for customers of whatever tha company is called these days, and they've been known to block ingress to various ones of them at random times, just to make sure we remember that. That said, they do have some of the coolest, most easily memorable IPv4 addresses on the net... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Wed Oct 19 18:27:26 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Oct 2011 19:27:26 -0400 (EDT) Subject: 4.2.2.2 acting up? or is it just me? In-Reply-To: <17754928.5426.1319053461110.JavaMail.root@benjamin.baylink.com> Message-ID: <3238427.5446.1319066846548.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > But understand that all 6 of GTEI's anycast customer resolver nameservers > are really intended for customers of whatever tha company is called these > days, and they've been known to block ingress to various ones of them at > random times, just to make sure we remember that. A source tells me that to the best of her knowledge, they do *not*, in fact, block ingress to those addresses from off-net, at least not purposefully. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From Valdis.Kletnieks at vt.edu Wed Oct 19 18:53:40 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Oct 2011 19:53:40 -0400 Subject: BGP Peers as basis of available routes In-Reply-To: Your message of "Wed, 19 Oct 2011 15:21:27 +0800." <4E9E7A77.5010109@stluke.com.ph> References: <4E9E7236.5000403@stluke.com.ph> <4E9E7A77.5010109@stluke.com.ph> Message-ID: <32337.1319068420@turing-police.cc.vt.edu> On Wed, 19 Oct 2011 15:21:27 +0800, "Nathanael C. Cariaga" said: > Thanks for the prompt response. Actually our requirement is to find a > webhosting provider whose routes are widely advertised locally and > regionally. That's different from who the provider peers with. We (AS1312) don't peer with much of anybody, but I *hope* our routes are pretty widely advertised. Anybody *not* seeing routes for AS1312? (And yes, most of the routes end up going through one or another of MATP's PoP's). So what failure mode are you trying to protect against by finding a provider with a lot of routes? I suspect there's probably a better metric to deal with the actual concern... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From leothelion.murtaza at gmail.com Thu Oct 20 01:22:40 2011 From: leothelion.murtaza at gmail.com (Murtaza) Date: Thu, 20 Oct 2011 17:22:40 +1100 Subject: Facebook insecure by design In-Reply-To: <093055FBC670440881925307C4117BF2@digitpc> References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> <4E88E923.2000006@bogus.com> <4E88EE42.8000407@bogus.com> <093055FBC670440881925307C4117BF2@digitpc> Message-ID: Going back to the initial security problem identified by Williams, I also experienced something today. I guess he is right about that. I am behind a proxy and I just disabled the proxy for "Secure Web" which means HTTPS. Now guess what I was still able to access facebook while I was not able to access google. That clearly means there is something wrong. What do you guys think? Ghulam On Wed, Oct 5, 2011 at 2:28 AM, Bill.Pilloud wrote: > Is this not the nature of social media? If you want to make sure something > is secure (sensitive information), Why is it on social media. If you are > worried about it being monetised, I think Google has already done that. > ----- Original Message ----- From: "Joel jaeggli" > To: "Jimmy Hess" > Cc: > Sent: Sunday, October 02, 2011 4:05 PM > Subject: Re: Facebook insecure by design > > > > On 10/2/11 15:43 , Joel jaeggli wrote: >> >>> On 10/2/11 15:25 , Jimmy Hess wrote: >>> >>>> On Sun, Oct 2, 2011 at 4:53 PM, wrote: >>>> >>>>> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: >>>>> >>>>>> I'm not sure why lack of TLS is considered to be problem with >>>>>> Facebook. >>>>>> The man in the middle is the other side of the connection, tls or >>>>>> otherwise. >>>>>> >>>>> Ooh.. subtle. :) >>>>> >>>> >>>> Man in the Middle (MITM) is a technical term that refers to a rather >>>> specific kind of attack. >>>> >>>> In this case, I believe the proper term would be just "The man". >>>> [Or "Man at the Other End (MATOE)"]; you either trust Facebook with >>>> info to send to >>>> them or you don't, and network security is only for securing the >>>> transportation of that information >>>> you opt to send facebook. >>>> >>> >>> alice sends charlie a message using bob's api, bob can observe and >>> probably monetize the contents. >>> >>> Yes, if Alice sends Bob an encrypted message that Bob can read, and >>>> Bob turns out to >>>> be untrustworthy, then Bob can sell/re-use the information in an >>>> abusive/unapproved way for >>>> personal or economic profit. >>>> >>> >>> charlie is probably untrustworthy, bob is probably moreso (mostly >>> >> ^ >> trustworthy >> >>> because bob has more to lose than charlie), alice isn't cognizant of the >>> implications of running charlie's app on bob's platform despite the >>> numerous disclaimers she blindly clicked through on the way there. >>> >>> >>> >>> -- >>>> -JH >>>> >>>> >>> >>> >> >> > > From regnauld at nsrc.org Thu Oct 20 01:49:17 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 20 Oct 2011 08:49:17 +0200 Subject: Abha Ahuja, 2001 Message-ID: <20111020064917.GA59759@macbook.bluepipe.net> Abha passed away 10 years ago today. Time flies. From jeroen at mompl.net Thu Oct 20 14:39:25 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 20 Oct 2011 12:39:25 -0700 Subject: RIP dmr In-Reply-To: <4E9669E5.3060005@deaddrop.org> References: <15361100.4928.1318475369289.JavaMail.root@benjamin.baylink.com> <4E9669E5.3060005@deaddrop.org> Message-ID: <4EA078ED.1050508@mompl.net> Lynda wrote: > Dennis was one of the good ones. A kind and generous person, who changed > all our worlds. Indeed. I consider the K&R C book as the pinnacle of how a book like that should be written. Every page, every sentence contains a multitude of information and there is no redundancy. The C book contains in 200 or so pages more useful information than the majority of programming books could ever hope to cram in 2000 odd pages. And they still managed to add some humour... > Rest In Peace Likewise... -- Earthquake Magnitude: 5.1 Date: Thursday, October 20, 2011 16:07:24 UTC Location: west of Macquarie Island Latitude: -52.5035; Longitude: 140.2170 Depth: 15.20 km From hank at efes.iucc.ac.il Thu Oct 20 15:43:33 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 20 Oct 2011 22:43:33 +0200 Subject: Outsourcing DDOS In-Reply-To: Message-ID: <5.1.0.14.2.20111020223918.00c301e0@efes.iucc.ac.il> At 09:13 19/10/2011 -0400, _CC removed_ on March 22, 2012 at request of sender__ wrote: >We are considering using Prolexic to 'defend' our Internet-facing network >from DDOS attacks. Anyone have any known issues or word of warnings >before we proceed? Things to check: - DDOS service caps - outage remedy credits - service trial period - monitoring - you will want some external mutually agreeable monitoring service like gomez/compuware. Who pays for it? Regards, Hank _CC removed_ on March 22, 2012 at request of sender__ From kilobit at gmail.com Thu Oct 20 15:48:34 2011 From: kilobit at gmail.com (bas) Date: Thu, 20 Oct 2011 22:48:34 +0200 Subject: Did Internap lose all clue? Message-ID: Recently I was contacted by an Internap sales person. The third line of the email read: "As you know well, BGP makes all routing decisions simply based on HOP COUNT" I blinked my eyes a couple of times.. Yes it really said hop count. Then I replied to the guy that if he tries to sell a technical product to technical people he should get his info straight. But he replied BGP actually makes decisions based on hop count. He even sent an URL from the internap website that states this http://www.internap.com/it-iq/route-optimization-miro/ On that page there is also this gem: "BGP relies on the premise that hops are responsible for packet loss and congestion, and therefore a route with fewer hops is inherently better. " I can imagine blatant misinformation like this from a shady startup trying to trick some sales with smoke and mirrors, but from Internap? -- Bas From paul at paulgraydon.co.uk Thu Oct 20 15:53:26 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 20 Oct 2011 10:53:26 -1000 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: <4EA08A46.9030208@paulgraydon.co.uk> On 10/20/2011 10:48 AM, bas wrote: > Recently I was contacted by an Internap sales person. > The third line of the email read: > > "As you know well, BGP makes all routing decisions simply based on HOP COUNT" > > I blinked my eyes a couple of times.. Yes it really said hop count. > Then I replied to the guy that if he tries to sell a technical product > to technical people he should get his info straight. > > But he replied BGP actually makes decisions based on hop count. > He even sent an URL from the internap website that states this > http://www.internap.com/it-iq/route-optimization-miro/ > > On that page there is also this gem: > "BGP relies on the premise that hops are responsible for packet loss > and congestion, and therefore a route with fewer hops is inherently > better. " > > > I can imagine blatant misinformation like this from a shady startup > trying to trick some sales with smoke and mirrors, but from Internap? > > > -- Bas > Reply with a link to wikipedia? http://en.wikipedia.org/wiki/BGP Possibly better still, Cisco's docwiki about it, assuming he might consider Cisco a bit more of an authoritative source: http://docwiki.cisco.com/wiki/Border_Gateway_Protocol#BGP_Attributes Paul From zeusdadog at gmail.com Thu Oct 20 15:54:22 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 20 Oct 2011 16:54:22 -0400 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: Well, it didn't say "router hops"... They could mean "AS hops" I guess. I never trust marketing garbage anyway. It makes my head hurt. On Thu, Oct 20, 2011 at 4:48 PM, bas wrote: > Recently I was contacted by an Internap sales person. > The third line of the email read: > > "As you know well, BGP makes all routing decisions simply based on HOP COUNT" > > I blinked my eyes a couple of times.. Yes it really said hop count. > Then I replied to the guy that if he tries to sell a technical product > to technical people he should get his info straight. > > But he replied BGP actually makes decisions based on hop count. > He even sent an URL from the internap website that states this > http://www.internap.com/it-iq/route-optimization-miro/ > > On that page there is also this gem: > "BGP relies on the premise that hops are responsible for packet loss > and congestion, and therefore a route with fewer hops is inherently > better. " > > > I can imagine blatant misinformation like this from a shady startup > trying to trick some sales with smoke and mirrors, but from Internap? > > > -- Bas > > From dholmes at mwdh2o.com Thu Oct 20 15:59:25 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 20 Oct 2011 13:59:25 -0700 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products. -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Thursday, October 20, 2011 1:54 PM To: bas Cc: nanog Subject: Re: Did Internap lose all clue? Well, it didn't say "router hops"... They could mean "AS hops" I guess. I never trust marketing garbage anyway. It makes my head hurt. On Thu, Oct 20, 2011 at 4:48 PM, bas wrote: > Recently I was contacted by an Internap sales person. > The third line of the email read: > > "As you know well, BGP makes all routing decisions simply based on HOP COUNT" > > I blinked my eyes a couple of times.. Yes it really said hop count. > Then I replied to the guy that if he tries to sell a technical product > to technical people he should get his info straight. > > But he replied BGP actually makes decisions based on hop count. > He even sent an URL from the internap website that states this > http://www.internap.com/it-iq/route-optimization-miro/ > > On that page there is also this gem: > "BGP relies on the premise that hops are responsible for packet loss > and congestion, and therefore a route with fewer hops is inherently > better. " > > > I can imagine blatant misinformation like this from a shady startup > trying to trick some sales with smoke and mirrors, but from Internap? > > > -- Bas > > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From ryan at u13.net Thu Oct 20 16:03:05 2011 From: ryan at u13.net (Ryan Rawdon) Date: Thu, 20 Oct 2011 17:03:05 -0400 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> On Oct 20, 2011, at 4:48 PM, bas wrote: > Recently I was contacted by an Internap sales person. > The third line of the email read: > > "As you know well, BGP makes all routing decisions simply based on HOP COUNT" > > I blinked my eyes a couple of times.. Yes it really said hop count. > Then I replied to the guy that if he tries to sell a technical product > to technical people he should get his info straight. > > But he replied BGP actually makes decisions based on hop count. > He even sent an URL from the internap website that states this > http://www.internap.com/it-iq/route-optimization-miro/ > > On that page there is also this gem: > "BGP relies on the premise that hops are responsible for packet loss > and congestion, and therefore a route with fewer hops is inherently > better. " > > > I can imagine blatant misinformation like this from a shady startup > trying to trick some sales with smoke and mirrors, but from Internap? > > That's a shame - I had a sales-oriented conversation with a few people from Internap (we are already a customer but this was about other services) and they were very clueful. This was a few months ago (including some discussions about BGP and their optimization products where their technical sales lead was clueful about how it worked and what it did). Though, Internap had the NOC who replied to a problem report of mine (where even-numbered addresses weren't pingable in our block via Internap; I used .0, a router loopback, as an indication of something unpingable which normally is) with "You should expect .1 to respond to ping and such, but not 2.0 as that is only capable of representing a subnet and not a network interface of any kind, or any machine, at all" From kilobit at gmail.com Thu Oct 20 16:06:00 2011 From: kilobit at gmail.com (bas) Date: Thu, 20 Oct 2011 23:06:00 +0200 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: On Thu, Oct 20, 2011 at 10:54 PM, Jay Nakamura wrote: > Well, it didn't say "router hops"... ?They could mean "AS hops" I > guess. Well actually the url I included earlier contains an explanation ---- "Understanding the ?Hop? Data transmitted across a network passes through numerous devices and carriers before it reaches its final destination. Each device is a transfer point and is referred to as a hop. ---- From rirving at antient.org Thu Oct 20 16:07:11 2011 From: rirving at antient.org (Richard Irving) Date: Thu, 20 Oct 2011 17:07:11 -0400 Subject: Did Internap lose all clue? In-Reply-To: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> Message-ID: <4EA08D7F.7020608@antient.org> Awww C'mon. It is the same old, same old. Q: What is the difference between a Sales Engineer, and an Engineer ? A: The Engineer *knows* when he is lying. :-D "same as it ever was.... same as it ever was...same as it .. ever... was.." - Talking Heads On 10/20/2011 04:59 PM, Holmes,David A wrote: > Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products. > > -----Original Message----- > From: Jay Nakamura [mailto:zeusdadog at gmail.com] > Sent: Thursday, October 20, 2011 1:54 PM > To: bas > Cc: nanog > Subject: Re: Did Internap lose all clue? > > Well, it didn't say "router hops"... They could mean "AS hops" I > guess. I never trust marketing garbage anyway. It makes my head > hurt. > > On Thu, Oct 20, 2011 at 4:48 PM, bas wrote: >> Recently I was contacted by an Internap sales person. >> The third line of the email read: >> >> "As you know well, BGP makes all routing decisions simply based on HOP COUNT" >> >> I blinked my eyes a couple of times.. Yes it really said hop count. >> Then I replied to the guy that if he tries to sell a technical product >> to technical people he should get his info straight. >> >> But he replied BGP actually makes decisions based on hop count. >> He even sent an URL from the internap website that states this >> http://www.internap.com/it-iq/route-optimization-miro/ >> >> On that page there is also this gem: >> "BGP relies on the premise that hops are responsible for packet loss >> and congestion, and therefore a route with fewer hops is inherently >> better. " >> >> >> I can imagine blatant misinformation like this from a shady startup >> trying to trick some sales with smoke and mirrors, but from Internap? >> >> >> -- Bas >> >> > > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. > From patrick at ianai.net Thu Oct 20 16:11:31 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 20 Oct 2011 17:11:31 -0400 Subject: Did Internap lose all clue? In-Reply-To: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> Message-ID: <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> On Oct 20, 2011, at 4:59 PM, Holmes,David A wrote: > Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products. That might have something to do with the fact InterNAP bought both of them (and the third company in that space). -- TTFN, patrick From mhernand1 at comcast.net Thu Oct 20 16:22:34 2011 From: mhernand1 at comcast.net (manny) Date: Thu, 20 Oct 2011 17:22:34 -0400 Subject: Did Internap lose all clue? In-Reply-To: <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> References: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> Message-ID: <4EA0911A.3070109@comcast.net> On 10/20/11 5:11 PM, Patrick W. Gilmore wrote: > On Oct 20, 2011, at 4:59 PM, Holmes,David A wrote: > >> Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products. > > That might have something to do with the fact InterNAP bought both of them (and the third company in that space). > umm... RouteScience was bought by Avaya.... From DHyde at hosting.com Thu Oct 20 16:29:04 2011 From: DHyde at hosting.com (Darrell Hyde) Date: Thu, 20 Oct 2011 17:29:04 -0400 Subject: Did Internap lose all clue? In-Reply-To: <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> References: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> Message-ID: <1AA11A6BC714D944985F3BC7FF7AB35F4A6AAC7D17@MBX03.corp.safesecureweb.com> > That might have something to do with the fact InterNAP bought both of > them (and the third company in that space). I believe RouteScience was acquired by Avaya in 2004. Did Internap acquire the IP after the fact? - Darrell From jbates at brightok.net Thu Oct 20 19:39:51 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 20 Oct 2011 19:39:51 -0500 Subject: Did Internap lose all clue? In-Reply-To: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> References: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> Message-ID: <4EA0BF57.4030609@brightok.net> On 10/20/2011 4:03 PM, Ryan Rawdon wrote: > "You should expect.1 to respond to ping and such, but not 2.0 as that is only capable of representing a subnet and not a network interface of any kind, or any machine, at all" Honestly, though. Can you blame them in this case? Given the lack of insight into your network, I also might question your numbering system (given the number of people who use .0 and .255 in /24 Ethernet segments). Although, there are still perfectly good reasons never to use .0 or .255 in production networks, even if it does work most of the time. I just finished griping at some vendors for using .0/31 on the first ptp link. Sure, it works, it might always work, but I'll be mighty pissed when I have to renumber core interfaces because some stupid software program freaks about it. I can live with 126 ptp links per /24 in 1918 space of all things. Jack From Valdis.Kletnieks at vt.edu Thu Oct 20 20:08:40 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Oct 2011 21:08:40 -0400 Subject: Did Internap lose all clue? In-Reply-To: Your message of "Thu, 20 Oct 2011 19:39:51 CDT." <4EA0BF57.4030609@brightok.net> References: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> <4EA0BF57.4030609@brightok.net> Message-ID: <24853.1319159320@turing-police.cc.vt.edu> On Thu, 20 Oct 2011 19:39:51 CDT, Jack Bates said: > On 10/20/2011 4:03 PM, Ryan Rawdon wrote: > > "You should expect.1 to respond to ping and such, but not 2 > prefix>.0 as that is only capable of representing a subnet and not a network > > interface of any kind, or any machine, at all" > Honestly, though. Can you blame them in this case? Given the lack of > insight into your network, I also might question your numbering system Yes, it's possibly foolish to allocate x.y.z.0 or .255. But saying that that x.y.z.0 is *not* *capable* of representing an interface is demonstrating a dangerous lack of knowledge. There's several totally legal .0 and .255 addresses in each /22 subnet, and yes people *do* use /22 subnets. Unfortunately, we're still stuck with "Don't use .0 or .255, because there are *still* people out there who don't understand CIDR and will hassle you about it"... What really sucks is when the CIDR-challenged people are hassling you indirectly via the code they write... ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Thu Oct 20 20:16:13 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 20 Oct 2011 20:16:13 -0500 Subject: Did Internap lose all clue? In-Reply-To: <24853.1319159320@turing-police.cc.vt.edu> References: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> <4EA0BF57.4030609@brightok.net> <24853.1319159320@turing-police.cc.vt.edu> Message-ID: <4EA0C7DD.2040406@brightok.net> On 10/20/2011 8:08 PM, Valdis.Kletnieks at vt.edu wrote: > Yes, it's possibly foolish to allocate x.y.z.0 or .255. But saying > that that x.y.z.0 is *not* *capable* of representing an interface is > demonstrating a dangerous lack of knowledge. There's several totally > legal .0 and .255 addresses in each /22 subnet, and yes people *do* > use /22 subnets. Unfortunately, we're still stuck with "Don't use .0 > or .255, Yeah, I quit using them in '98ish and never bothered trying again. Was annoying the first time I realized the dialup user wasn't working because they had a .0 or .255 address from the pool. Of course, I've had more calls from people asking why they don't work when they aren't supposed to work. :) > because there are *still* people out there who don't understand CIDR > and will hassle you about it"... What really sucks is when the > CIDR-challenged people are hassling you indirectly via the code they > write... ;) Yeah, but at 2-4 addresses per /24, I really can't be bothered to yell at the coders. Easier to just not use them. Jack From branto at networking-architecture.com Thu Oct 20 21:56:40 2011 From: branto at networking-architecture.com (Brant I. Stevens) Date: Thu, 20 Oct 2011 21:56:40 -0500 Subject: Did Internap lose all clue? In-Reply-To: <4EA0911A.3070109@comcast.net> Message-ID: On 10/20/11 5:22 PM, "manny" wrote: >On 10/20/11 5:11 PM, Patrick W. Gilmore wrote: >> On Oct 20, 2011, at 4:59 PM, Holmes,David A wrote: >> >>> Looking at the link referenced below, the route optimization method >>>mentioned appears to be very similar to the old Routescience or Sockeye >>>BGP optimization products. >> >> That might have something to do with the fact InterNAP bought both of >>them (and the third company in that space). >> >umm... RouteScience was bought by Avaya.... > Internap grabbed Sockeye. > From ras at e-gerbil.net Thu Oct 20 22:19:13 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 20 Oct 2011 22:19:13 -0500 Subject: Did Internap lose all clue? In-Reply-To: References: Message-ID: <20111021031913.GW40752@gerbil.cluepon.net> On Thu, Oct 20, 2011 at 10:48:34PM +0200, bas wrote: > Recently I was contacted by an Internap sales person. > The third line of the email read: > > "As you know well, BGP makes all routing decisions simply based on HOP COUNT" > > I blinked my eyes a couple of times.. Yes it really said hop count. > Then I replied to the guy that if he tries to sell a technical product > to technical people he should get his info straight. Errr, I think they mean AS hops, which is actually mostly correct. After you eliminate things that don't actually convey any information (like localpref, which you have to configure yourself), and things that don't provide any meaningful data in a multi-network path selection role (like MEDs), AS-PATH length is pretty much the only useful basis you have for picking a best path from your BGP peers. All other marketing crap asside, they aren't incorrect in pointing out that BGP really sucks as a way to pick a best path. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bep at whack.org Fri Oct 21 01:28:29 2011 From: bep at whack.org (Bruce Pinsky) Date: Thu, 20 Oct 2011 23:28:29 -0700 Subject: Did Internap lose all clue? In-Reply-To: <1AA11A6BC714D944985F3BC7FF7AB35F4A6AAC7D17@MBX03.corp.safesecureweb.com> References: <922ACC42D498884AA02B3565688AF99533FEFCFEBB@USEXMBS01.mwd.h2o> <98F8F24F-8434-4C5E-86F7-A88F187305B4@ianai.net> <1AA11A6BC714D944985F3BC7FF7AB35F4A6AAC7D17@MBX03.corp.safesecureweb.com> Message-ID: <4EA1110D.2040108@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darrell Hyde wrote: >> That might have something to do with the fact InterNAP bought both of >> them (and the third company in that space). > > I believe RouteScience was acquired by Avaya in 2004. Did Internap acquire the IP after the fact? > Correct on RouteScience going to Lucent/Avaya. InterNAP bought NetVMG and Sockeye in 2003. Proficient Networks merged with IP Deliver forming Infiniroute in 2004. http://www.networkworld.com/news/2003/1013internap.html http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=1204052 And Cisco in the space with OER/PFR. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6hEQ0ACgkQE1XcgMgrtybB5gCfUGfsya2+PlT21jT2nnbp9X9m 7j4AnRXDKEOHeykd9t30tS5FjgenKTch =a85l -----END PGP SIGNATURE----- From jhoppes at cfunet.net Fri Oct 21 10:18:38 2011 From: jhoppes at cfunet.net (Josh V. Hoppes) Date: Fri, 21 Oct 2011 15:18:38 +0000 Subject: Motorola GPON deployments Message-ID: Hello NANOG, We are currently in the process of rolling out a Motorola GPON solution and running into some hiccups and wanted to see if we were doing something unique or if anyone else has run into the issue and we just haven't found the right solution. Our configuration has the OLTs using single tagged VLANs down to each customer ONT, rather than using Q in Q connections. This VLAN is shared among all customers that terminate at a single site, which may have 1-2 OLTs sharing that same VLAN. This VLAN is then carried back via switching to our core equipment which handles routing. We have noticed that malfunctioning customer equipment have generated loops on the network which has caused unusual forwarding problems in the OLT, and many of the ONTs we are in the process of deploying, 1400GTI, don't include the ability to detect these loops. If anyone wants more information feel free to follow up with me off list. We are hoping we aren't the only ones attempting this and can find a sane solution to the issue. Josh Hoppes Cedar Falls Utilities From cscora at apnic.net Fri Oct 21 14:16:46 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Oct 2011 05:16:46 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201110211916.p9LJGkBv024703@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Oct, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 380496 Prefixes after maximum aggregation: 169790 Deaggregation factor: 2.24 Unique aggregates announced to Internet: 185657 Total ASes present in the Internet Routing Table: 39145 Prefixes per ASN: 9.72 Origin-only ASes present in the Internet Routing Table: 32357 Origin ASes announcing only one prefix: 15520 Transit ASes present in the Internet Routing Table: 5252 Transit-only ASes present in the Internet Routing Table: 137 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1488 Unregistered ASNs in the Routing Table: 824 Number of 32-bit ASNs allocated by the RIRs: 1876 Number of 32-bit ASNs visible in the Routing Table: 1536 Prefixes from 32-bit ASNs in the Routing Table: 3535 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 90 Number of addresses announced to Internet: 2485983008 Equivalent to 148 /8s, 45 /16s and 23 /24s Percentage of available address space announced: 67.1 Percentage of allocated address space announced: 67.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.5 Total number of prefixes smaller than registry allocations: 160795 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 94637 Total APNIC prefixes after maximum aggregation: 30888 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 91103 Unique aggregates announced from the APNIC address blocks: 37995 APNIC Region origin ASes present in the Internet Routing Table: 4582 APNIC Prefixes per ASN: 19.88 APNIC Region origin ASes announcing only one prefix: 1263 APNIC Region transit ASes present in the Internet Routing Table: 714 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 95 Number of APNIC addresses announced to Internet: 628909152 Equivalent to 37 /8s, 124 /16s and 100 /24s Percentage of available APNIC address space announced: 79.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 145635 Total ARIN prefixes after maximum aggregation: 74451 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 117542 Unique aggregates announced from the ARIN address blocks: 48144 ARIN Region origin ASes present in the Internet Routing Table: 14743 ARIN Prefixes per ASN: 7.97 ARIN Region origin ASes announcing only one prefix: 5665 ARIN Region transit ASes present in the Internet Routing Table: 1556 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 804723200 Equivalent to 47 /8s, 247 /16s and 26 /24s Percentage of available ARIN address space announced: 64.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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 92842 Total RIPE prefixes after maximum aggregation: 50711 RIPE Deaggregation factor: 1.83 Prefixes being announced from the RIPE address blocks: 85517 Unique aggregates announced from the RIPE address blocks: 54134 RIPE Region origin ASes present in the Internet Routing Table: 16065 RIPE Prefixes per ASN: 5.32 RIPE Region origin ASes announcing only one prefix: 7986 RIPE Region transit ASes present in the Internet Routing Table: 2526 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1077 Number of RIPE addresses announced to Internet: 491110080 Equivalent to 29 /8s, 69 /16s and 190 /24s Percentage of available RIPE address space announced: 79.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 35142 Total LACNIC prefixes after maximum aggregation: 7851 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 34589 Unique aggregates announced from the LACNIC address blocks: 18057 LACNIC Region origin ASes present in the Internet Routing Table: 1541 LACNIC Prefixes per ASN: 22.45 LACNIC Region origin ASes announcing only one prefix: 446 LACNIC Region transit ASes present in the Internet Routing Table: 278 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 348 Number of LACNIC addresses announced to Internet: 91696512 Equivalent to 5 /8s, 119 /16s and 45 /24s Percentage of available LACNIC address space announced: 60.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8532 Total AfriNIC prefixes after maximum aggregation: 2017 AfriNIC Deaggregation factor: 4.23 Prefixes being announced from the AfriNIC address blocks: 6607 Unique aggregates announced from the AfriNIC address blocks: 1982 AfriNIC Region origin ASes present in the Internet Routing Table: 493 AfriNIC Prefixes per ASN: 13.40 AfriNIC Region origin ASes announcing only one prefix: 160 AfriNIC Region transit ASes present in the Internet Routing Table: 109 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 27836672 Equivalent to 1 /8s, 168 /16s and 193 /24s Percentage of available AfriNIC address space announced: 41.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2502 11095 963 Korea Telecom (KIX) 17974 1888 519 33 PT TELEKOMUNIKASI INDONESIA 7545 1610 303 85 TPG Internet Pty Ltd 4755 1538 636 172 TATA Communications formerly 7552 1389 1064 8 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1094 80 498 Sify Limited 4808 1082 2101 308 CNCGROUP IP network: China169 24560 966 343 220 Bharti Airtel Ltd., Telemedia 18101 952 166 148 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3545 3814 220 bellsouth.net, inc. 7029 2287 1016 197 Windstream Communications Inc 18566 2098 383 177 Covad Communications 1785 1839 680 122 PaeTec Communications, Inc. 4323 1628 1084 393 Time Warner Telecom 20115 1589 1542 623 Charter Communications 22773 1462 2907 100 Cox Communications, Inc. 19262 1395 4728 400 Verizon Global Networks 30036 1395 251 672 Mediacom Communications Corp 7018 1322 7030 866 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3352 2203 2317 51 Ibernet, Internet Access Netw 8402 1484 352 13 Corbina telecom 6830 653 1927 415 UPC Distribution Services 34984 584 108 180 BILISIM TELEKOM 20940 548 182 422 Akamai Technologies European 3320 504 8169 384 Deutsche Telekom AG 3292 481 2080 408 TDC Tele Danmark 12479 478 593 7 Uni2 Autonomous System 8866 459 133 26 Bulgarian Telecommunication C 29049 423 31 55 AzerSat LLC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1694 313 155 TVCABLE BOGOTA 28573 1442 1032 69 NET Servicos de Comunicao S.A 8151 1430 2913 352 UniNet S.A. de C.V. 7303 1227 747 177 Telecom Argentina Stet-France 27947 588 72 83 Telconet S.A 22047 580 322 17 VTR PUNTO NET S.A. 6503 569 450 69 AVANTEL, S.A. 7738 552 1050 31 Telecomunicacoes da Bahia S.A 3816 541 233 96 Empresa Nacional de Telecomun 11172 522 85 95 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 802 146 36 LINKdotNET AS number 8452 641 446 12 TEDATA 15475 443 74 8 Nile Online 36992 297 415 21 Etisalat MISR 3741 280 939 229 The Internet Solution 6713 244 519 14 Itissalat Al-MAGHRIB 15706 240 32 6 Sudatel Internet Exchange Aut 29571 217 17 13 Ci Telecom Autonomous system 33776 208 13 14 Starcomms Nigeria Limited 12258 196 28 57 Vodacom Internet Company Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3545 3814 220 bellsouth.net, inc. 4766 2502 11095 963 Korea Telecom (KIX) 7029 2287 1016 197 Windstream Communications Inc 3352 2203 2317 51 Ibernet, Internet Access Netw 18566 2098 383 177 Covad Communications 17974 1888 519 33 PT TELEKOMUNIKASI INDONESIA 1785 1839 680 122 PaeTec Communications, Inc. 10620 1694 313 155 TVCABLE BOGOTA 4323 1628 1084 393 Time Warner Telecom 7545 1610 303 85 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 3352 2203 2152 Ibernet, Internet Access Netw 7029 2287 2090 Windstream Communications Inc 18566 2098 1921 Covad Communications 17974 1888 1855 PT TELEKOMUNIKASI INDONESIA 1785 1839 1717 PaeTec Communications, Inc. 4766 2502 1539 Korea Telecom (KIX) 10620 1694 1539 TVCABLE BOGOTA 7545 1610 1525 TPG Internet Pty Ltd 8402 1484 1471 Corbina telecom 7552 1389 1381 Vietel Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.rand.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:19 /9:12 /10:27 /11:81 /12:235 /13:464 /14:808 /15:1425 /16:12014 /17:6038 /18:10044 /19:19947 /20:27466 /21:27612 /22:37390 /23:35908 /24:197611 /25:1158 /26:1332 /27:739 /28:157 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2185 3545 bellsouth.net, inc. 18566 2047 2098 Covad Communications 7029 1959 2287 Windstream Communications Inc 3352 1751 2203 Ibernet, Internet Access Netw 10620 1589 1694 TVCABLE BOGOTA 8402 1460 1484 Corbina telecom 30036 1357 1395 Mediacom Communications Corp 11492 1118 1156 Cable One 1785 1057 1839 PaeTec Communications, Inc. 7011 1048 1166 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:407 2:482 4:15 5:1 6:3 8:361 12:1955 13:1 14:540 15:11 16:3 17:7 20:9 23:59 24:1676 27:964 31:604 32:65 33:4 34:2 36:4 38:755 40:110 41:2668 42:53 44:3 46:999 47:3 49:296 50:441 52:13 55:6 56:2 57:37 58:880 59:493 60:362 61:1180 62:1085 63:1956 64:4048 65:2310 66:4285 67:1980 68:1152 69:3193 70:892 71:379 72:1802 74:2573 75:389 76:320 77:888 78:861 79:481 80:1590 81:941 82:494 83:575 84:621 85:1119 86:405 87:894 88:418 89:1598 90:235 91:4210 92:527 93:1536 94:1308 95:1078 96:437 97:284 98:918 99:37 101:211 103:390 106:70 107:73 108:72 109:1050 110:671 111:789 112:331 113:488 114:610 115:706 116:881 117:720 118:900 119:1251 120:340 121:692 122:1569 123:1018 124:1355 125:1384 128:249 129:177 130:165 131:593 132:145 133:21 134:219 135:54 136:213 137:140 138:284 139:123 140:488 141:298 142:387 143:432 144:494 145:63 146:469 147:215 148:641 149:267 150:166 151:192 152:447 153:178 154:7 155:386 156:206 157:362 158:153 159:479 160:324 161:214 162:340 163:172 164:509 165:369 166:537 167:438 168:742 169:146 170:872 171:86 172:4 173:1703 174:684 175:426 176:271 177:338 178:1064 180:1092 181:36 182:649 183:218 184:385 185:1 186:1299 187:704 188:934 189:875 190:5096 192:5916 193:5039 194:3562 195:3102 196:1253 197:164 198:3625 199:4167 200:5485 201:1650 202:8546 203:8491 204:4293 205:2364 206:2687 207:2829 208:4029 209:3573 210:2693 211:1452 212:2079 213:1800 214:786 215:96 216:4925 217:1617 218:564 219:343 220:1243 221:514 222:345 223:274 End of report From keegan.holley at sungard.com Fri Oct 21 15:00:18 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 21 Oct 2011 16:00:18 -0400 Subject: SaudiTelecom Message-ID: Despite this being a north american list anyone know how I can speak with someone from saudi telecom. Preferably someone with the ever illusive clue? From sil at infiltrated.net Fri Oct 21 15:01:56 2011 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 21 Oct 2011 16:01:56 -0400 Subject: Merit Point of Contact Message-ID: <4EA1CFB4.5070903@infiltrated.net> Can someone on list put me in touch with an individual in Merit.edu's security team. An address in their netblock introduced themselves to one my my VoIP honeypots, unsure whether to send it to abuse as it will likely be confusing (the write up). -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From cidr-report at potaroo.net Fri Oct 21 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Oct 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201110212200.p9LM01PJ030944@wattle.apnic.net> BGP Update Report Interval: 13-Oct-11 -to- 20-Oct-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 44731 3.0% 65.6 -- BSNL-NIB National Internet Backbone 2 - AS812 37117 2.5% 6.6 -- ROGERS-CABLE - Rogers Cable Communications Inc. 3 - AS17974 36021 2.4% 20.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS38040 35785 2.4% 7157.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 5 - AS7552 28191 1.9% 31.6 -- VIETEL-AS-AP Vietel Corporation 6 - AS32528 24571 1.6% 4914.2 -- ABBOTT Abbot Labs 7 - AS16010 19354 1.3% 217.5 -- RUSTAVI2ONLINEAS Caucasus Online LLC 8 - AS24560 18517 1.2% 16.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - AS9498 17268 1.1% 20.9 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS47331 16709 1.1% 5.1 -- TTNET TTNet A.S. 11 - AS5800 13361 0.9% 64.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - AS6316 12711 0.8% 149.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 13 - AS16916 12375 0.8% 12375.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 14 - AS8866 12067 0.8% 26.1 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS9649 11042 0.7% 208.3 -- MOPH-TH-AP Information Technology Office 16 - AS22950 10925 0.7% 341.4 -- USASK - University of Saskatchewan 17 - AS8402 10685 0.7% 13.7 -- CORBINA-AS OJSC "Vimpelcom" 18 - AS27738 10263 0.7% 30.2 -- Ecuadortelecom S.A. 19 - AS9562 9516 0.6% 1359.4 -- MSU-TH-AP Mahasarakham University 20 - AS8151 8698 0.6% 8.6 -- Uninet S.A. de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16916 12375 0.8% 12375.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 2 - AS38040 35785 2.4% 7157.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS32528 24571 1.6% 4914.2 -- ABBOTT Abbot Labs 4 - AS10099 3462 0.2% 3462.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 5 - AS50733 2437 0.2% 2437.0 -- BINA-AS Ertebat Gostaran Bina 6 - AS9562 9516 0.6% 1359.4 -- MSU-TH-AP Mahasarakham University 7 - AS17425 6306 0.4% 1261.2 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 8 - AS55696 1258 0.1% 1258.0 -- SCOM-AS-ID Starcom Solusindo PT. 9 - AS22375 6129 0.4% 1225.8 -- CREDCO - First Advantage Membership Services INC. 10 - AS56204 860 0.1% 860.0 -- NETMAX-NP Net Max Technologies Pvt. Ltd. 11 - AS11943 837 0.1% 837.0 -- GLOBE - Globe Wireless 12 - AS51966 753 0.1% 753.0 -- RESTENA-ANYCAST-AS Fondation RESTENA 13 - AS53295 745 0.1% 745.0 -- ROVI - Rovi Corporation 14 - AS5311 547 0.0% 547.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 15 - AS47528 537 0.0% 537.0 -- INTELECOM-AS Intelecom Group ASA 16 - AS55915 907 0.1% 453.5 -- CLASSIC-NP Classic Tech Pvt. Ltd. 17 - AS10445 1606 0.1% 401.5 -- HTG - Huntleigh Telcom 18 - AS56615 397 0.0% 397.0 -- BTT-AS Business Travel Turism SRL 19 - AS4613 4346 0.3% 395.1 -- MOS-NP Mercantile Office Systems 20 - AS46066 379 0.0% 379.0 -- DOCOMOINTERTOUCH-IN DOCOMO interTouch - India Operation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 13427 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 206.80.93.0/24 12375 0.8% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 3 - 130.36.34.0/24 12286 0.8% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 12267 0.8% AS32528 -- ABBOTT Abbot Labs 5 - 213.16.48.0/24 10130 0.6% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - 66.248.120.0/21 8592 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 180.180.255.0/24 7346 0.5% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 8 - 180.180.249.0/24 7293 0.5% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 9 - 180.180.248.0/24 7050 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 10 - 180.180.253.0/24 7048 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 180.180.250.0/24 7048 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 12 - 202.171.192.0/20 4542 0.3% AS4788 -- TMNET-AS-AP TM Net, Internet Service Provider 13 - 66.248.104.0/21 3814 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 14 - 203.160.94.0/24 3462 0.2% AS10099 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 15 - 202.153.174.0/24 3178 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - 202.41.70.0/24 2957 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 17 - 208.54.82.0/24 2839 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 18 - 212.80.20.0/23 2437 0.1% AS50733 -- BINA-AS Ertebat Gostaran Bina 19 - 202.151.7.0/24 2423 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 20 - 202.151.6.0/24 2413 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Oct 21 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Oct 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201110212200.p9LM01Qj030938@wattle.apnic.net> This report has been generated at Fri Oct 21 21:12:43 2011 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 14-10-11 379221 222617 15-10-11 379777 222482 16-10-11 379901 222767 17-10-11 380086 223026 18-10-11 380464 222994 19-10-11 380436 223071 20-10-11 380570 223243 21-10-11 384022 223763 AS Summary 39249 Number of ASes in routing system 16602 Number of ASes announcing only one prefix 3545 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108508128 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'). --- 21Oct11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 382825 223805 159020 41.5% All ASes AS6389 3545 223 3322 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2098 406 1692 80.6% COVAD - Covad Communications Co. AS3352 2203 578 1625 73.8% TELEFONICA-DATA-ESPANA TELEFONICA DE ESPANA AS4766 2502 982 1520 60.8% KIXS-AS-KR Korea Telecom AS22773 1462 110 1352 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1535 226 1309 85.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1629 395 1234 75.8% TWTC - tw telecom holdings, inc. AS1785 1842 786 1056 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1419 363 1056 74.4% NET Servicos de Comunicao S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS10620 1694 712 982 58.0% Telmex Colombia S.A. AS7552 1389 428 961 69.2% VIETEL-AS-AP Vietel Corporation AS7303 1229 330 899 73.1% Telecom Argentina S.A. AS18101 954 156 798 83.6% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7029 2328 1539 789 33.9% WINDSTREAM - Windstream Communications Inc AS8151 1433 682 751 52.4% Uninet S.A. de C.V. AS4808 1082 340 742 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1395 677 718 51.5% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1611 932 679 42.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1102 451 651 59.1% LEVEL3 Level 3 Communications AS17974 1886 1249 637 33.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS24560 966 333 633 65.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4804 708 95 613 86.6% MPX-AS Microplex PTY LTD AS3549 1055 444 611 57.9% GBLX Global Crossing Ltd. AS17676 678 70 608 89.7% GIGAINFRA Softbank BB Corp. AS20115 1594 990 604 37.9% CHARTER-NET-HKY-NC - Charter Communications AS8402 1480 878 602 40.7% CORBINA-AS OJSC "Vimpelcom" AS22561 933 372 561 60.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS7011 1166 644 522 44.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 44893 15824 29069 64.8% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 142.54.202.0/23 AS19137 EPSILON-INTERACTIVE - Epsilon Interactive LLC 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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.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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From neal.rauhauser at gmail.com Fri Oct 21 23:56:54 2011 From: neal.rauhauser at gmail.com (N Rauhauser) Date: Sat, 22 Oct 2011 00:56:54 -0400 Subject: Comcast security please contact me off list Message-ID: I do some protective service work, one client is the head of a Washington D.C. NGO that faced a credible death threat last month. Tonight I received information that the source of this threat traced one of the NGO's volunteers to her home address via Comcast IP, and the location is a relatively short drive away from a man who was arrested last month for criminal harassment almost five hundred miles from his home. I have some genuine concerns for the physical safety of this Comcast customer, and I'd like to talk to someone immediately. We've got an annoyed FBI agent who will confirm the back story on this Monday, but the subjects know they're under some sort of investigation and I'm afraid of what might happen if further info leaks over the weekend. This is a junk box for me - nrauhauser at gmail is the address I check regularly. From matt at overloaded.net Sat Oct 22 00:13:49 2011 From: matt at overloaded.net (Matt Buford) Date: Sat, 22 Oct 2011 00:13:49 -0500 Subject: Did Internap lose all clue? In-Reply-To: <24853.1319159320@turing-police.cc.vt.edu> References: <829895D9-6EBE-447D-A14A-EC911CB2D625@u13.net> <4EA0BF57.4030609@brightok.net> <24853.1319159320@turing-police.cc.vt.edu> Message-ID: On Thu, Oct 20, 2011 at 8:08 PM, wrote: > Yes, it's possibly foolish to allocate x.y.z.0 or .255. > > But saying that that x.y.z.0 is *not* *capable* of representing an > interface is > demonstrating a dangerous lack of knowledge. There's several totally legal > .0 > and .255 addresses in each /22 subnet, and yes people *do* use /22 subnets. > Unfortunately, we're still stuck with "Don't use .0 or .255, because there > are > *still* people out there who don't understand CIDR and will hassle you > about it"... > A decade ago, I recall allocating a /23 to a dialup pool and getting calls from customers who landed on .0 and .255 because they were unable to reach random sites. It should be legal, but doesn't always work. I assumed this was still the case. Several months ago, I fired up a permanent aws ec2 instance with a static IP. To my surprise, they allocated me a .0 address. I haven't noticed any issues with it at all. But I figure if Amazon is using .0 as a normal part of their deployments, their scale is so high that if it didn't work reliably you'd think they would have noticed by now. I don't know if they also use .255. From christopher.curwick at gmail.com Sat Oct 22 04:29:10 2011 From: christopher.curwick at gmail.com (Chris Curwick) Date: Sat, 22 Oct 2011 02:29:10 -0700 Subject: Frontier IPv6 website unavailable Message-ID: When visiting www.frontier.com using an ipv6 tunnel from HE I am getting the following result: Service Unavailable A quick poll of my peers without ipv6 shows the site rendering. It looks like this is limited just to the IPv6 side. From frnkblk at iname.com Sat Oct 22 08:26:49 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 22 Oct 2011 08:26:49 -0500 Subject: Frontier IPv6 website unavailable In-Reply-To: References: Message-ID: <002101cc90be$416cff30$c446fd90$@iname.com> Wget shows that it flops back and forth between 200 and 503. My guess is that the v6 address is on a load-balancer and that one of the two web servers is down. Frank -----Original Message----- From: Chris Curwick [mailto:christopher.curwick at gmail.com] Sent: Saturday, October 22, 2011 4:29 AM To: nanog at nanog.org Subject: Frontier IPv6 website unavailable When visiting www.frontier.com using an ipv6 tunnel from HE I am getting the following result: Service Unavailable A quick poll of my peers without ipv6 shows the site rendering. It looks like this is limited just to the IPv6 side. From carlosm3011 at gmail.com Sat Oct 22 09:14:43 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sat, 22 Oct 2011 12:14:43 -0200 Subject: OT: ISPs in Brazil and Chile In-Reply-To: References: <6EDE133FF50DBA4B963028BD5CD690DD368B24@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: Do you need IPv6 ? On Thu, Oct 13, 2011 at 4:50 PM, Luis Palma wrote: > I work in Claro. Claro has ISP in both countries. > If you need more information contact me off list. > > Regards > > 2011/10/13, Jeff Cartier : >> Hi Group, >> >> A little off topic, but I was looking for a recommendation on an ISP in both >> Brazil and Chile. >> >> Thanks!! >> >> __________________________________________________________________ >> DISCLAIMER: This e-mail contains proprietary information some or all of >> which may be legally privileged. ?It is for the intended recipient only. If >> an addressing or transmission error has misdirected this e-mail, please >> notify the author by replying to this e-mail. ?If you are not the intended >> recipient you must not use, disclose, distribute, copy, print, or rely on >> this e-mail. >> >> This message has been scanned for the presence of computer viruses, Spam, >> and Explicit Content. >> >> > > -- > Enviado desde mi dispositivo m?vil > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From sfouant at shortestpathfirst.net Sat Oct 22 16:45:41 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 22 Oct 2011 17:45:41 -0400 Subject: Outsourcing DDOS In-Reply-To: <5.1.0.14.2.20111020223918.00c301e0@efes.iucc.ac.il> References: <5.1.0.14.2.20111020223918.00c301e0@efes.iucc.ac.il> Message-ID: <4EA33985.80009@shortestpathfirst.net> Although a bit dated, I did a pretty exhaustive comparison of offerings from AT&T, Verizon, Prolexic, and a few others a while back. Don't forget there is also the go-it-yourself approach which is always a fun option, guaranteed to keep you up at night and give you a few additional gray hairs... Let me know if you're interested in the slides... Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate On 10/20/2011 4:43 PM, Hank Nussbacher wrote: > At 09:13 19/10/2011 -0400, _CC removed_ on March 22, 2012 at request of sender__ wrote: >> We are considering using Prolexic to 'defend' our Internet-facing >> network from DDOS attacks. Anyone have any known issues or word of >> warnings before we proceed? > > Things to check: > > - DDOS service caps > - outage remedy credits > - service trial period > - monitoring - you will want some external mutually agreeable monitoring > service like gomez/compuware. Who pays for it? > > Regards, > Hank > > _CC removed_ on March 22, 2012 at request of sender__ From dennis at justipit.com Sat Oct 22 18:24:20 2011 From: dennis at justipit.com (Dennis) Date: Sat, 22 Oct 2011 19:24:20 -0400 Subject: Outsourcing DDOS Message-ID: Good points Steven. I'd suggest a deep dive on the technologies implemented by the vendor today as times and attack methods have evolved. Many attacks today are not Volumetric or easily detected or mitigated by traditional methods. Stefan Fouant wrote: >Although a bit dated, I did a pretty exhaustive comparison of offerings >from AT&T, Verizon, Prolexic, and a few others a while back. > >Don't forget there is also the go-it-yourself approach which is always a >fun option, guaranteed to keep you up at night and give you a few >additional gray hairs... > >Let me know if you're interested in the slides... > >Stefan Fouant >JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI >Technical Trainer, Juniper Networks > >Follow us on Twitter @JuniperEducate > >On 10/20/2011 4:43 PM, Hank Nussbacher wrote: >> At 09:13 19/10/2011 -0400, _CC removed_ on March 22, 2012 at request of sender__ wrote: >>> We are considering using Prolexic to 'defend' our Internet-facing >>> network from DDOS attacks. Anyone have any known issues or word of >>> warnings before we proceed? >> >> Things to check: >> >> - DDOS service caps >> - outage remedy credits >> - service trial period >> - monitoring - you will want some external mutually agreeable monitoring >> service like gomez/compuware. Who pays for it? >> >> Regards, >> Hank >> >> _CC removed_ on March 22, 2012 at request of sender__ From deric.kwok2000 at gmail.com Sat Oct 22 20:07:28 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 22 Oct 2011 21:07:28 -0400 Subject: Can this bgp work? Message-ID: Hello We would like to split our network advertising with same AS no. in different our bgp routers to same or different upstream provider eg: 66.70.0.0/20 in bgpRouterA 67.170.0.0/20 in bgpRouterB 174.70.0.0/20 in bgpRouterC ls it working? Thank you From christopher.morrow at gmail.com Sat Oct 22 20:14:31 2011 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 22 Oct 2011 21:14:31 -0400 Subject: Can this bgp work? In-Reply-To: References: Message-ID: Check routeviews? On Oct 22, 2011 9:07 PM, "Deric Kwok" wrote: > Hello > > We would like to split our network advertising with same AS no. in > different our bgp routers to same or different upstream provider > > eg: > > 66.70.0.0/20 in bgpRouterA > 67.170.0.0/20 in bgpRouterB > 174.70.0.0/20 in bgpRouterC > > ls it working? > > Thank you > > From mysidia at gmail.com Sat Oct 22 20:22:24 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 22 Oct 2011 20:22:24 -0500 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: On Wed, Oct 19, 2011 at 8:46 AM, Vlad Galu wrote: > They say that "When an attack is detected, our protection services are implemented within minutes. > Upon activation, a Prolexic customer routes in-bound traffic to the nearest Prolexic scrubbing center > where proprietary-filtering techniques, advanced routing, and patent-pending hardware devices > remove bot traffic close to the source." If that's true, that they have a technology that is so good they will only describe it as proprietary magic, that will efficiently scrub all bot traffic and not scrub legitimate traffic, and it really works every time, and they've persuaded you/made a convincing argument, i'd be thrilled. But probably there is no way to validate that it will actually work to your satisfaction against whatever sort of attack you face, before actually buying the service. If they are confident it is so great, they ought to be happy to either price your cost of the service based on its effectiveness or otherwise provide you a very good SLA, clearly stipulate what they can and can't handle, both in terms of type of attack, and volume of attack (realistically, there is some flood volume that will exceed _any_ service's capacity). Make sure they will waive fees, early termination fees at least, fees for "protection they failed to provide" at least, and give you a cancel option/way out, should their technology fail to be as effective as their marketing would have you believe, and make sure they have a burden of proof under the SLA to show their protection service worked properly after an incident, rather than you having to prove it did not. Clearly you would want to discuss the technical details with them and costs, whether some sort of subscription or per-incident; that protection services are only implemented "when activated", indicates there is cost or technical disadvantage during any time you choose to have "protection active" - -JH From jbates at brightok.net Sat Oct 22 20:38:30 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 22 Oct 2011 20:38:30 -0500 Subject: Juniper DOS/Blackhole question Message-ID: <4EA37016.9050402@brightok.net> Considered j-nsp, but this just feels more nanog appropriate. I'm told by one of my NSPs that I'm connected to a juniper. We were dealing with a DOS, and for some reason remote triggered DOS prevention via BGP wasn't working. The NOC said they had to enable multihop to my peering to make it work, otherwise it wouldn't accept the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled? Also, any idea why a Juniper couldn't handle a simple 750mbit/s, 1.5Mpps DOS? Don't get me wrong, it could have been more than that. I was just receiving that much of the DOS and my lower end m120 didn't seem to think it an issue, so I'm curious why I was dropping packets on the link to begin with. Interestingly, I have an OC-12 to another NSP who was also dropping after around 1.2Mpps (last time I asked, they said the oc-12 hit a cisco 7600). Jack From randy_94108 at yahoo.com Sat Oct 22 21:22:41 2011 From: randy_94108 at yahoo.com (Randy) Date: Sat, 22 Oct 2011 19:22:41 -0700 (PDT) Subject: Can this bgp work? In-Reply-To: Message-ID: <1319336561.93236.YahooMailClassic@web80503.mail.mud.yahoo.com> ...sure it will work...you can advertise any-which-way you want! What *exactly* are you trying to accomplish? ..and a previous op mentioned: route-views is your friend. ./Randy --- On Sat, 10/22/11, Christopher Morrow wrote: > From: Christopher Morrow > Subject: Re: Can this bgp work? > To: "Deric Kwok" > Cc: "nanog list" > Date: Saturday, October 22, 2011, 6:14 PM > Check routeviews? > On Oct 22, 2011 9:07 PM, "Deric Kwok" > wrote: > > > Hello > > > > We would like to split our network advertising with > same AS no. in > > different our bgp routers to same or different > upstream provider > > > > eg: > > > > 66.70.0.0/20 in bgpRouterA > > 67.170.0.0/20 in bgpRouterB > > 174.70.0.0/20 in bgpRouterC > > > > ls it working? > > > > Thank you > > > > > From graham at g-rock.net Sat Oct 22 21:30:00 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 22 Oct 2011 21:30:00 -0500 Subject: Can this bgp work? In-Reply-To: <1319336561.93236.YahooMailClassic@web80503.mail.mud.yahoo.com> Message-ID: Deric, just make sure you allow your AS to come back in through the other routers - in case there is an internal route break or if one of these /20's is out in never-never land ... On 10/22/11 9:22 PM, "Randy" wrote: > ...sure it will work...you can advertise any-which-way you want! > What *exactly* are you trying to accomplish? > ..and a previous op mentioned: route-views is your friend. > ./Randy > > --- On Sat, 10/22/11, Christopher Morrow wrote: > >> From: Christopher Morrow >> Subject: Re: Can this bgp work? >> To: "Deric Kwok" >> Cc: "nanog list" >> Date: Saturday, October 22, 2011, 6:14 PM >> Check routeviews? >> On Oct 22, 2011 9:07 PM, "Deric Kwok" >> wrote: >> >>> Hello >>> >>> We would like to split our network advertising with >> same AS no. in >>> different our bgp routers to same or different >> upstream provider >>> >>> eg: >>> >>> 66.70.0.0/20 in bgpRouterA >>> 67.170.0.0/20 in bgpRouterB >>> 174.70.0.0/20 in bgpRouterC >>> >>> ls it working? >>> >>> Thank you >>> >>> >> > From sfouant at shortestpathfirst.net Sat Oct 22 22:14:14 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 22 Oct 2011 23:14:14 -0400 Subject: Juniper DOS/Blackhole question In-Reply-To: <4EA37016.9050402@brightok.net> References: <4EA37016.9050402@brightok.net> Message-ID: Enabling BGP multi-hop is a very common approach with DDoS Mitigation services and also variations of Remote-Triggered Black Holes where the discard route isn't localized on the edge router. This is not because the customer router will be greater than one hop away, but because enabling multi-hop has an additional side effect of disabling next-hop validation. Without this enabled, the edge router will invalidate the ?mitigate? routes received from the customer because the next-hop is not directly reachable via the neighbor. Not sure about the PPS limitations... The PFE ASICs should be able to handle a 750Mbps / 1.5 Mpps DoS pretty easy... HTHs. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 22, 2011, at 9:38 PM, Jack Bates wrote: > Considered j-nsp, but this just feels more nanog appropriate. > > I'm told by one of my NSPs that I'm connected to a juniper. We were dealing with a DOS, and for some reason remote triggered DOS prevention via BGP wasn't working. The NOC said they had to enable multihop to my peering to make it work, otherwise it wouldn't accept the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled? > > Also, any idea why a Juniper couldn't handle a simple 750mbit/s, 1.5Mpps DOS? Don't get me wrong, it could have been more than that. I was just receiving that much of the DOS and my lower end m120 didn't seem to think it an issue, so I'm curious why I was dropping packets on the link to begin with. Interestingly, I have an OC-12 to another NSP who was also dropping after around 1.2Mpps (last time I asked, they said the oc-12 hit a cisco 7600). > > > Jack > From jbates at brightok.net Sat Oct 22 22:26:46 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 22 Oct 2011 22:26:46 -0500 Subject: Juniper DOS/Blackhole question In-Reply-To: References: <4EA37016.9050402@brightok.net> Message-ID: <4EA38976.80909@brightok.net> On 10/22/2011 10:14 PM, Stefan Fouant wrote: > Enabling BGP multi-hop is a very common approach with DDoS Mitigation services and also variations of Remote-Triggered Black Holes where the discard route isn't localized on the edge router. This is not because the customer router will be greater than one hop away, but because enabling multi-hop has an additional side effect of disabling next-hop validation. Without this enabled, the edge router will invalidate the ?mitigate? routes received from the customer because the next-hop is not directly reachable via the neighbor. yeah, I didn't think of that side effect, probably because I don't modify next-hops myself. > Not sure about the PPS limitations... The PFE ASICs should be able to handle a 750Mbps / 1.5 Mpps DoS pretty easy... That's what I'm thinking. My m120 shows 0 problems with the load, but 2 of my transits dropped packets to me without saturating their respective links. I expected more out of NSPs. Jack From morrowc.lists at gmail.com Sat Oct 22 23:24:19 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 23 Oct 2011 00:24:19 -0400 Subject: Juniper DOS/Blackhole question In-Reply-To: <4EA38976.80909@brightok.net> References: <4EA37016.9050402@brightok.net> <4EA38976.80909@brightok.net> Message-ID: On Sat, Oct 22, 2011 at 11:26 PM, Jack Bates wrote: > On 10/22/2011 10:14 PM, Stefan Fouant wrote: >> Not sure about the PPS limitations... The PFE ASICs should be able to >> handle a 750Mbps / 1.5 Mpps DoS pretty easy... > > That's what I'm thinking. My m120 shows 0 problems with the load, but 2 of > my transits dropped packets to me without saturating their respective links. > I expected more out of NSPs. if someone has you on an older oc-12 LC ... say the 4x oc12 ... that doesnt like high pps rates :( From rsnyder at toontown.erial.nj.us Sun Oct 23 02:18:21 2011 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Sun, 23 Oct 2011 03:18:21 -0400 Subject: Comcast security please contact me off list In-Reply-To: References: Message-ID: On Sat, Oct 22, 2011 at 12:56 AM, N Rauhauser wrote: > ?I do some protective service work, one client is the head of a Washington > D.C. NGO that faced a credible death threat last month. Tonight I received > information that the source of this threat traced one of the NGO's > volunteers to her home address via Comcast IP, and the location is a > relatively short drive away from a man who was arrested last month for > criminal harassment almost five hundred miles from his home. > > ?I have some genuine concerns for the physical safety of this Comcast > customer, and I'd like to talk to someone immediately. We've got an annoyed > FBI agent who will confirm the back story on this Monday, but the subjects > know they're under some sort of investigation and I'm afraid of what might > happen if further info leaks over the weekend. Then your FBI agent should probably go through the channels (http://security.comcast.net/get-help/contact-comcast-security.aspx) they have to speak to Comcast, especially if it involves a threat to life and safety. Asking on NANOG for a Comcast contact to give you customer information (which is what it seems like you're asking for) probably isn't going to help and makes it look more like you're trying to social engineer some information than trying to help someone. Bob From saku at ytti.fi Sun Oct 23 02:18:58 2011 From: saku at ytti.fi (Saku Ytti) Date: Sun, 23 Oct 2011 10:18:58 +0300 Subject: Juniper DOS/Blackhole question In-Reply-To: <4EA37016.9050402@brightok.net> References: <4EA37016.9050402@brightok.net> Message-ID: <20111023071858.GA503@pob.ytti.fi> On (2011-10-22 20:38 -0500), Jack Bates wrote: > the route. This seems strange to me. Any idea why a route would be > rejected unless multihop was enabled? RFC4271 states: -- - By default (if none of the above conditions apply), the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute. -- Your provider was rewriting the next-hop to some address they are blackholing inside their network. This caused above check to fail, and route was being considered invalid. EBGP multihop is kludge to kill this check, but also kludge to kill convergence of your BGP session, due to disabling fall over on linkdown. Proper way to disable this check is JunOS 'accept-remote-nexthop' or IOS 'disable-connected-check'. -- ++ytti From jbates at brightok.net Sun Oct 23 08:47:23 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 23 Oct 2011 08:47:23 -0500 Subject: Juniper DOS/Blackhole question In-Reply-To: <20111023071858.GA503@pob.ytti.fi> References: <4EA37016.9050402@brightok.net> <20111023071858.GA503@pob.ytti.fi> Message-ID: <4EA41AEB.1020107@brightok.net> On 10/23/2011 2:18 AM, Saku Ytti wrote: > EBGP multihop is kludge to kill this check, but also kludge to kill > convergence of your BGP session, due to disabling This is what I was worried about. > fall over on linkdown. Proper way to disable this check is JunOS > 'accept-remote-nexthop' or IOS 'disable-connected-check'. Thanks. I'll have them fix it proper then. Jack From steve at pirk.com Sun Oct 23 12:43:26 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Sun, 23 Oct 2011 10:43:26 -0700 Subject: Facebook insecure by design In-Reply-To: References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> <4E88E923.2000006@bogus.com> <4E88EE42.8000407@bogus.com> <093055FBC670440881925307C4117BF2@digitpc> Message-ID: Just about everything on Google pages is https these days, even search if you enable it. If anybody on this thread uses gmail com a you really ought to take a look at google plus. Compare the way user privacy is the primary objective, versus the share everything by default of facebook. I cannot think of anything that could do something like this in the Gmail or Plus products. On Oct 19, 2011 11:22 PM, "Murtaza" wrote: > Going back to the initial security problem identified by Williams, I also > experienced something today. I guess he is right about that. I am behind a > proxy and I just disabled the proxy for "Secure Web" which means HTTPS. > Now guess what I was still able to access facebook while I was not able to > access google. That clearly means there is something wrong. What do you > guys > think? > Ghulam > > On Wed, Oct 5, 2011 at 2:28 AM, Bill.Pilloud > wrote: > > > Is this not the nature of social media? If you want to make sure > something > > is secure (sensitive information), Why is it on social media. If you are > > worried about it being monetised, I think Google has already done that. > > ----- Original Message ----- From: "Joel jaeggli" > > To: "Jimmy Hess" > > Cc: > > Sent: Sunday, October 02, 2011 4:05 PM > > Subject: Re: Facebook insecure by design > > > > > > > > On 10/2/11 15:43 , Joel jaeggli wrote: > >> > >>> On 10/2/11 15:25 , Jimmy Hess wrote: > >>> > >>>> On Sun, Oct 2, 2011 at 4:53 PM, wrote: > >>>> > >>>>> On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: > >>>>> > >>>>>> I'm not sure why lack of TLS is considered to be problem with > >>>>>> Facebook. > >>>>>> The man in the middle is the other side of the connection, tls or > >>>>>> otherwise. > >>>>>> > >>>>> Ooh.. subtle. :) > >>>>> > >>>> > >>>> Man in the Middle (MITM) is a technical term that refers to a rather > >>>> specific kind of attack. > >>>> > >>>> In this case, I believe the proper term would be just "The man". > >>>> [Or "Man at the Other End (MATOE)"]; you either trust Facebook with > >>>> info to send to > >>>> them or you don't, and network security is only for securing the > >>>> transportation of that information > >>>> you opt to send facebook. > >>>> > >>> > >>> alice sends charlie a message using bob's api, bob can observe and > >>> probably monetize the contents. > >>> > >>> Yes, if Alice sends Bob an encrypted message that Bob can read, and > >>>> Bob turns out to > >>>> be untrustworthy, then Bob can sell/re-use the information in an > >>>> abusive/unapproved way for > >>>> personal or economic profit. > >>>> > >>> > >>> charlie is probably untrustworthy, bob is probably moreso (mostly > >>> > >> ^ > >> trustworthy > >> > >>> because bob has more to lose than charlie), alice isn't cognizant of > the > >>> implications of running charlie's app on bob's platform despite the > >>> numerous disclaimers she blindly clicked through on the way there. > >>> > >>> > >>> > >>> -- > >>>> -JH > >>>> > >>>> > >>> > >>> > >> > >> > > > > > From jeroen at unfix.org Sun Oct 23 13:11:47 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 23 Oct 2011 20:11:47 +0200 Subject: Facebook insecure by design In-Reply-To: References: <4E85865F.60700@gmail.com> <4E88857C.7040106@mtcc.com> <240172.1317592435@turing-police.cc.vt.edu> <4E88E923.2000006@bogus.com> <4E88EE42.8000407@bogus.com> <093055FBC670440881925307C4117BF2@digitpc> Message-ID: <4EA458E3.5090405@unfix.org> [hmmm this subject is not really ops now is it...] On 2011-10-23 19:43 , steve pirk [egrep] wrote: > Just about everything on Google pages is https these days, even search if > you enable it. (or just use https://encrypted.google.com which is available for quite some time already) > If anybody on this thread uses gmail com a you really ought to take a look > at google plus. Compare the way user privacy is the primary objective, > versus the share everything by default of facebook. Since when is encrypting a transport (in this case using TLS/SSL) 'user privacy' ? The only thing it is protecting is intermediate networks sniffing or even modifying the traffic and more importantly for the company who gets all your private information: their revenue stream when they sell that data. And really, giving all your private emails to a company that explicitly reads them (even if it is 'automated') to advertise to you and then mentioning 'user privacy' is just ridiculous ;) Greets, Jeroen From jra at baylink.com Sun Oct 23 18:04:27 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 23 Oct 2011 19:04:27 -0400 (EDT) Subject: Facebook insecure by design In-Reply-To: <4EA458E3.5090405@unfix.org> Message-ID: <9899547.5703.1319411067114.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeroen Massar" > On 2011-10-23 19:43 , steve pirk [egrep] wrote: > > Just about everything on Google pages is https these days, even > > search if you enable it. > > (or just use https://encrypted.google.com which is available for quite > some time already) Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo... http://lauren.vortex.com/archive/000906.html Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From steve at pirk.com Sun Oct 23 23:45:33 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Sun, 23 Oct 2011 21:45:33 -0700 Subject: Facebook insecure by design In-Reply-To: <9899547.5703.1319411067114.JavaMail.root@benjamin.baylink.com> References: <4EA458E3.5090405@unfix.org> <9899547.5703.1319411067114.JavaMail.root@benjamin.baylink.com> Message-ID: I follow Lauren on plus, and also on buzz, and we have discussed privacy stuff a lot. The way I look at it, unless you want to host everything yourself, you have to choose "someone" to be your Unix like home directory in the cloud. Of all the internet entities out there, Google has had the best track record of protecting your data. You can even download it all and erase yourself if you want out. Apps accounts and pseudonym accounts are coming soon. It was announced by Vic himself at web 2.0. I need to send that post by Lauren to the gmail account. He always finds good issues. It could be that I am off base. On Oct 23, 2011 4:04 PM, "Jay Ashworth" wrote: > ----- Original Message ----- > > From: "Jeroen Massar" > > > On 2011-10-23 19:43 , steve pirk [egrep] wrote: > > > Just about everything on Google pages is https these days, even > > > search if you enable it. > > > > (or just use https://encrypted.google.com which is available for quite > > some time already) > > Note that Lauren Weinstein has just put out a Privacy Digest posting noting > that the referer behavior differs between https://encrypted.google.com and > https://www.google.com in a way that implies that, again, someone at > Google > may not have gotten the Don't Be Evil memo... > > http://lauren.vortex.com/archive/000906.html > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > From steve at pirk.com Mon Oct 24 00:16:27 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Sun, 23 Oct 2011 22:16:27 -0700 Subject: Facebook insecure by design In-Reply-To: <9899547.5703.1319411067114.JavaMail.root@benjamin.baylink.com> References: <4EA458E3.5090405@unfix.org> <9899547.5703.1319411067114.JavaMail.root@benjamin.baylink.com> Message-ID: That was a most excellent example Jay. I see what the issue is now. This could be related to work Google did to plus shortly after launch. Buzz and now Google+ are https only. Google cooked up a URL processer that took clicks to external content like article links, and massaged the referrer be readable as http to show where the visitor came from. Sanitized of any personal data I assume. The problem they were trying to fix was no one knew any users were coming from Buzz clicks. They fixed that in +. I am thinking something of the same might fix the search issues. It could also be that a Googler saw Lauren's post and the debate has already started. -steve On Oct 23, 2011 4:04 PM, "Jay Ashworth" wrote: > ----- Original Message ----- > > From: "Jeroen Massar" > > > On 2011-10-23 19:43 , steve pirk [egrep] wrote: > > > Just about everything on Google pages is https these days, even > > > search if you enable it. > > > > (or just use https://encrypted.google.com which is available for quite > > some time already) > > Note that Lauren Weinstein has just put out a Privacy Digest posting noting > that the referer behavior differs between https://encrypted.google.com and > https://www.google.com in a way that implies that, again, someone at > Google > may not have gotten the Don't Be Evil memo... > > http://lauren.vortex.com/archive/000906.html > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > From bonomi at mail.r-bonomi.com Mon Oct 24 09:54:40 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 24 Oct 2011 09:54:40 -0500 (CDT) Subject: Facebook insecure by design In-Reply-To: Message-ID: <201110241454.p9OEseXg037575@mail.r-bonomi.com> > Date: Sun, 23 Oct 2011 21:45:33 -0700 > Subject: Re: Facebook insecure by design > Cc: nanog at nanog.org > > The way I look at it, unless you want to host everything yourself, you have > to choose "someone" to be your Unix like home directory in the cloud. Correct. Either it's 'local', or it's "somewhere else" -- by definition. :) > Of all the internet entities out there, Google has had the best track record > of protecting your data. As far as we know, that is. Remember the old saying about 'undiscovered bugs'. > You can even download it all and erase yourself if > you want out. Don't count on it. You may 'disappear' from public view, but that does not necessarily mean the data is truely 'gone'. Specific example -- if you request a USENET posting to be removed, all they do is make it 'invisible' to the world. It is _not_ removed from the databases, or from inernal access/use. From lou at metron.com Mon Oct 24 11:57:38 2011 From: lou at metron.com (Lou Katz) Date: Mon, 24 Oct 2011 09:57:38 -0700 Subject: Facebook insecure by design In-Reply-To: <201110241454.p9OEseXg037575@mail.r-bonomi.com> References: <201110241454.p9OEseXg037575@mail.r-bonomi.com> Message-ID: <20111024165738.GA38346@metron.com> The real question is why the referrer field was not under user control in the first place. Having to never click on a link, but rather to cut and paste it into the address bar is not a satisfactory work-around. Still, why has it not been put under user control, now that we have a better appreciation of the hazards of that information leakage? -- -=[L]=- Reassembled from random thought waves This is not a signature line. From andreas at livejournalinc.com Mon Oct 24 12:54:52 2011 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 24 Oct 2011 10:54:52 -0700 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: We've dealt with these guys too too. There are lots of providers; I've used ones through ISPs and they can work well. Our only issue is that the ISP we were talking with only had XYZ Gb of mitigation, and Prolexic has a ton more capacity (in the hundreds of gigabits when I last checked). Prolexic is the go-to company for handling large-scale DDoSes. We haven't yet tried the service, but they've been extremely professional. Every time we're on the phone it's with engineers that know their stuff. Ultimately you're going to want to have a mix of internal mitigation and one or several providers if you're a big target. I doubt anyone is going to be perfect -- it's simply impossible. Heck, lots of the attacking "bots" are just spyware on legitimate users' PCs, so obviously they will get blocked. My personal experience is that when you're dealing with a DoS at the scale that you need Prolexic, there is simply no one else that can handle that level of traffic. -Andreas On Sat, Oct 22, 2011 at 6:22 PM, Jimmy Hess wrote: > On Wed, Oct 19, 2011 at 8:46 AM, Vlad Galu wrote: > > They say that "When an attack is detected, our protection services are > implemented within minutes. > > Upon activation, a Prolexic customer routes in-bound traffic to the > nearest Prolexic scrubbing center > > where proprietary-filtering techniques, advanced routing, and > patent-pending hardware devices > > remove bot traffic close to the source." > > If that's true, that they have a technology that is so good they will > only describe it as proprietary magic, that will efficiently scrub all > bot traffic and not scrub legitimate traffic, and it really works > every time, and they've persuaded you/made a convincing argument, i'd > be thrilled. But probably there is no way to validate that it will > actually work to your satisfaction against whatever sort of attack > you face, before actually buying the service. > > If they are confident it is so great, they ought to be happy to either > price your cost of the service based on its effectiveness or otherwise > provide you a very good SLA, clearly stipulate what they can and > can't handle, both in terms of type of attack, and volume of attack > (realistically, there is some flood volume that will exceed _any_ > service's capacity). Make sure they will waive fees, early > termination fees at least, fees for "protection they failed to > provide" at least, and give you a cancel option/way out, should their > technology fail to be as effective as their marketing would have you > believe, and make sure they have a burden of proof under the SLA to > show their protection service worked properly after an incident, > rather than you having to prove it did not. > > Clearly you would want to discuss the technical details with them and > costs, whether some sort of subscription or per-incident; that > protection services are only implemented "when activated", indicates > there is cost or technical disadvantage during any time you choose to > have "protection active" > > - > -JH > > From frnkblk at iname.com Mon Oct 24 13:46:48 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 24 Oct 2011 13:46:48 -0500 Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days In-Reply-To: <000001cc5d68$93fc01d0$bbf40570$@iname.com> References: <000001cc5d68$93fc01d0$bbf40570$@iname.com> Message-ID: <010501cc927d$496cb4d0$dc461e70$@iname.com> Good news: access to the v6 version of www.qwest.com came up at 12:30 pm today -- it redirects to www.centurylink.com, but at least it's working. Only www.savvis.com remains in my list of service provider websites that have non-working IPv6. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, August 18, 2011 12:35 AM To: nanog at nanog.org Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days The IPv6 version of www.qwest.com has been down for 10 days. Wget shows a 301 to www.centurylink.com, but that also fails. Emails to the nocs at both companies have gone unanswered. Unless HE is deployed in a web browser, this behavior leads to a bad end-user experience. If anyone can prod either of these two companies that would be much appreciated. Frank nagios:/home/fbulk# wget -6 www.qwest.com --2011-08-18 00:32:40-- http://www.qwest.com/ Resolving www.qwest.com... 2001:428:b21:1::20 Connecting to www.qwest.com|2001:428:b21:1::20|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.centurylink.com/ [following] --2011-08-18 00:32:40-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::22 Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:02-- (try: 2) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:25-- (try: 3) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:49-- (try: 4) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. Etc... From sfouant at shortestpathfirst.net Mon Oct 24 14:29:47 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 24 Oct 2011 15:29:47 -0400 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: <4EA5BCAB.30702@shortestpathfirst.net> On 10/24/2011 1:54 PM, Andreas Echavez wrote: > obviously they will get blocked. My personal experience is that when you're > dealing with a DoS at the scale that you need Prolexic, there is simply no > one else that can handle that level of traffic. Andreas, I think there are a lot of people on this list that would argue with that statement. As was mentioned earlier, AT&T, Verizon, and several others including Verisign have very ample networks capable of handling attacks just as large as Prolexic, if not bigger. One thing to note about Prolexic, where it stands out from some of the others is that it is a completely off-net solution. Many of the other offerings from folks like Verizon require you to have WAN circuits connected to their network in order to avail of such a service (in other words, they will only scrub that which would normally traverse their network on it's way towards your WAN interface). Others like Verisign have (smartly) adopted a similar model to that of Prolexic. They understand that requiring a physical connection into a provider's cloud is a monolithic approach (and certainly runs counter to today's mantra of offering up cloud-based services). Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate From morrowc.lists at gmail.com Mon Oct 24 14:53:07 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Oct 2011 15:53:07 -0400 Subject: Outsourcing DDOS In-Reply-To: <4EA5BCAB.30702@shortestpathfirst.net> References: <4EA5BCAB.30702@shortestpathfirst.net> Message-ID: On Mon, Oct 24, 2011 at 3:29 PM, Stefan Fouant wrote: > On 10/24/2011 1:54 PM, Andreas Echavez wrote: > >> obviously they will get blocked. My personal experience is that when >> you're >> dealing with a DoS at the scale that you need Prolexic, there is simply no >> one else that can handle that level of traffic. > > Andreas, > > I think there are a lot of people on this list that would argue with that > statement. ?As was mentioned earlier, AT&T, Verizon, and several others > including Verisign have very ample networks capable of handling attacks just > as large as Prolexic, if not bigger. > > One thing to note about Prolexic, where it stands out from some of the > others is that it is a completely off-net solution. ?Many of the other > offerings from folks like Verizon require you to have WAN circuits connected > to their network in order to avail of such a service (in other words, they > will only scrub that which would normally traverse their network on it's way > towards your WAN interface). > > Others like Verisign have (smartly) adopted a similar model to that of > Prolexic. ?They understand that requiring a physical connection into a > provider's cloud is a monolithic approach (and certainly runs counter to > today's mantra of offering up cloud-based services). > but... often the cost of scrubbing includes the cost of transit to/from the remote provider, which is why 'cheapest' only counts for an entire process, NOT for 'lookie, I bought the service!'. either way, folks will learn one way or the other which works for them. -chris > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI > Technical Trainer, Juniper Networks > > Follow us on Twitter @JuniperEducate > > From sfouant at shortestpathfirst.net Mon Oct 24 15:01:04 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 24 Oct 2011 16:01:04 -0400 Subject: Outsourcing DDOS In-Reply-To: References: <4EA5BCAB.30702@shortestpathfirst.net> Message-ID: <4EA5C400.9030809@shortestpathfirst.net> On 10/24/2011 3:53 PM, Christopher Morrow wrote: > On Mon, Oct 24, 2011 at 3:29 PM, Stefan Fouant > > but... often the cost of scrubbing includes the cost of transit > to/from the remote provider, which is why 'cheapest' only counts for > an entire process, NOT for 'lookie, I bought the service!'. > > either way, folks will learn one way or the other which works for them. I couldn't agree with you more - often times there are unintended costs, for example, the operational burden of moving your advertisements towards the provider who offers a scrubbing service... Also the more complex it is to use a particular service, the more likely you are to have indirect costs in terms of lost revenue during the outage. All of these things should be properly vetted well in advance, and the additional operational burden should also be factored into the pricing equation. Unfortunately, all too often these additional things aren't factored by the bean counters until it's too late. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate From jbates at brightok.net Mon Oct 24 17:24:21 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 24 Oct 2011 17:24:21 -0500 Subject: Advice on BGP traffic engineering for classified traffic Message-ID: <4EA5E595.5080405@brightok.net> I'm curious if anyone has a pointer on traffic manipulation for classified traffic. Basics, I have a really cheap transit connection that some customers are paying reduced rates to only use that connection (and not my other transits). Though I've considered support for cases where NSP peering disputes break out. While I can advertise their networks out the correct transit for return traffic, I still have to figure out how to handle egress traffic. I'm guessing the crux of it is policy routing based on source address, but I'm interested in ways to engineer it to easy management and scalability. I've considered the possibility of an l3vpn to interconnect customers that are not requiring full routes, and possibly some type of vpls tunnel terminated at the necessary router for customers who need full routes. Thoughts, pointers, suggestions? Jack From andreas at livejournalinc.com Mon Oct 24 17:46:55 2011 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 24 Oct 2011 15:46:55 -0700 Subject: Outsourcing DDOS In-Reply-To: <4EA5BCAB.30702@shortestpathfirst.net> References: <4EA5BCAB.30702@shortestpathfirst.net> Message-ID: Having used some of the largest solutions, I do disagree. After quickly searching google for Verisign, I could find a few documents that claim they have ~350Gb of capacity. On Prolexic's website, they claim to have the largest total mitigation capacity at 375Gb. Now if you're talking about upstream providers (ATT/Verizon), even if your upstream mitigates the traffic, do you really N+1 redundancy during an attack? Do the providers have an SLA guaranteeing mitigation within a certain timeframe? Finally, and most importantly to us, was how much do they charge per attack, or if it a flat "insurance" type agreement where they block unlimited attacks. Total capacity certainly isn't the most important factor, but a sane pricing policy certainly was. -Andreas On Mon, Oct 24, 2011 at 12:29 PM, Stefan Fouant < sfouant at shortestpathfirst.net> wrote: > On 10/24/2011 1:54 PM, Andreas Echavez wrote: > > obviously they will get blocked. My personal experience is that when >> you're >> dealing with a DoS at the scale that you need Prolexic, there is simply no >> one else that can handle that level of traffic. >> > > Andreas, > > I think there are a lot of people on this list that would argue with that > statement. As was mentioned earlier, AT&T, Verizon, and several others > including Verisign have very ample networks capable of handling attacks just > as large as Prolexic, if not bigger. > > One thing to note about Prolexic, where it stands out from some of the > others is that it is a completely off-net solution. Many of the other > offerings from folks like Verizon require you to have WAN circuits connected > to their network in order to avail of such a service (in other words, they > will only scrub that which would normally traverse their network on it's way > towards your WAN interface). > > Others like Verisign have (smartly) adopted a similar model to that of > Prolexic. They understand that requiring a physical connection into a > provider's cloud is a monolithic approach (and certainly runs counter to > today's mantra of offering up cloud-based services). > > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI > Technical Trainer, Juniper Networks > > Follow us on Twitter @JuniperEducate > From brett at the-watsons.org Mon Oct 24 18:45:34 2011 From: brett at the-watsons.org (Brett Watson) Date: Mon, 24 Oct 2011 16:45:34 -0700 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: On Oct 24, 2011, at 10:54 AM, Andreas Echavez wrote: > Prolexic is the go-to company for handling large-scale DDoSes. We haven't > yet tried the service, but they've been extremely professional. Not sure I understand your post. You claim Prolexic are the go-to-guys, and extremely professional? but you haven't used them? I would agree with Stephan's response as well, some of the other providers have as much capacity to deal with attacks (Verisign, Neustar, etc). And it's not about what's "stated" on their marketing slicks, it's about actual capacity, architecture, and "clue." Prolexic has a long (early) history of DDoS mitigation, and I have no reason do doubt they are any worse than they used to be but if you haven't used them, it's just conjecture. I'd be interested to know whom you have experience with and what size of attack you were able to mitigate with them (not being pedantic, but looking for real-world examples and all). -b From morrowc.lists at gmail.com Mon Oct 24 20:12:49 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Oct 2011 21:12:49 -0400 Subject: Outsourcing DDOS In-Reply-To: References: <4EA5BCAB.30702@shortestpathfirst.net> Message-ID: On Mon, Oct 24, 2011 at 6:46 PM, Andreas Echavez wrote: > certain timeframe? Finally, and most importantly to us, was how much do they > charge per attack, or if it a flat "insurance" type agreement where they > block unlimited attacks. for verizon the 'time to mitigate' is gated on you sending a community for the route, how fast can you do that? the charge is a flat cost/month - it was 3250/month at one point (list price). > Total capacity certainly isn't the most important factor, but a sane pricing > policy certainly was. right, that was my point about the off-net services. -chris From andreas at livejournalinc.com Mon Oct 24 20:37:42 2011 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 24 Oct 2011 18:37:42 -0700 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: On Mon, Oct 24, 2011 at 4:45 PM, Brett Watson wrote: > On Oct 24, 2011, at 10:54 AM, Andreas Echavez wrote: > > > Prolexic is the go-to company for handling large-scale DDoSes. We haven't > > yet tried the service, but they've been extremely professional. > > Not sure I understand your post. You claim Prolexic are the go-to-guys, and > extremely professional? but you haven't used them? > > I would agree with Stephan's response as well, some of the other providers > have as much capacity to deal with attacks (Verisign, Neustar, etc). And > it's not about what's "stated" on their marketing slicks, it's about actual > capacity, architecture, and "clue." > Agreed, however our point of contention was that no other providers were willing to write SLAs based on service delivery time. We've used Verizon's service and it took nearly 10-12 hours coordinating with their NOC to get the service up and running, then over a week of troubleshooting packet sizes and so forth to finally get the system working properly. Unfortunately the only way for us to test Prolexic is to come under attack. In the meantime, the provisioning, engineering team, and everyone else has been fantastic. I'm not trying to push one provider over another -- we've just had good communication. Someone with less frequent or smaller attacks may find better value in another service. Prolexic's stated current network capacity is 375Gb. They have *claimed* that they will have 500Gb total by next year. > Prolexic has a long (early) history of DDoS mitigation, and I have no > reason do doubt they are any worse than they used to be but if you haven't > used them, it's just conjecture. > That's all I'm really saying here. It's been a good experience so far -- but only time will tell. Most of these *providers* are just using Arbor networks equipment and a fat pipe. It generally all works the same. Unfortunately it's not a simple task to test several hundred gigabytes of mitigation capacity. > > I'd be interested to know whom you have experience with and what size of > attack you were able to mitigate with them (not being pedantic, but looking > for real-world examples and all). > We were able to mitigate a 20Gb attack through VZB. It was concerning because their total network capacity is 80Gb across ~4 PoPs. Unfortunately we had the issues above, combined with a lot of billing confusion on their part. They asked us to pay more for no reason whatsoever because we really need to *upgrade* our tier to the 1Gb service from the 500Mb (what does that mean)? This conversation with their sales team followed the somewhat large attack stated above. When asked "does the 1Gb tier mean 1Gb of clean traffic, or that you block 1Gb of DDoS", they couldn't answer our question. Anyhow take everything with a grain of salt. Our experience could differ vastly than others, and this isn't mean I have anything against Verizon or anyone else. > -b > -Andreas From andreas at livejournalinc.com Mon Oct 24 20:39:39 2011 From: andreas at livejournalinc.com (Andreas Echavez) Date: Mon, 24 Oct 2011 18:39:39 -0700 Subject: Outsourcing DDOS In-Reply-To: References: Message-ID: > > Unfortunately it's not a simple task to test several hundred gigabytes of > mitigation capacity. > > Correction... Meant gigabits -- we're not at that point yet ;) -A From jra at baylink.com Mon Oct 24 22:47:22 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Oct 2011 23:47:22 -0400 (EDT) Subject: Advice on BGP traffic engineering for classified traffic In-Reply-To: <4EA5E595.5080405@brightok.net> Message-ID: <10431869.5953.1319514438894.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jack Bates" > I'm curious if anyone has a pointer on traffic manipulation for > classified traffic. Based on the remainder of your post, I'm going to go ahead and assume that you don't mean "classified traffic" in the sense that most people would infer from that phrasing. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From dmburgess at linktechs.net Mon Oct 24 23:29:05 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 24 Oct 2011 23:29:05 -0500 Subject: Outgoing SMTP Servers Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice? Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound SMTP connections at the same time. But if the ISP has their own mail servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice? ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" From owen at delong.com Mon Oct 24 23:37:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Oct 2011 21:37:11 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote: > I am curious about what network operators are doing with outbound SMTP > traffic. In the past few weeks we have ran into over 10 providers, > mostly local providers, which block outbound SMTP and require the users > to go THOUGH their mail servers even though those servers are not > responsible for the domains in question! I know other mail servers are > blocking non-reversible mail, however, is this common? And more > importantly, is this an acceptable practice? > It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked. > > > Most of our smaller ISPs that we support; we allow any outbound SMTP > connection, however we do watch residential users for 5+ outbound SMTP > connections at the same time. But if the ISP has their own mail > servers, and users wish to relay though them, we basically tell them to > use their mail server that they contract with. What is the best > practice? > Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us. Owen From dmburgess at linktechs.net Mon Oct 24 23:49:11 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 24 Oct 2011 23:49:11 -0500 Subject: Outgoing SMTP Servers References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA685B0@ltiserver.lti.local> > > On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote: > > > I am curious about what network operators are doing with outbound SMTP > > traffic. In the past few weeks we have ran into over 10 providers, > > mostly local providers, which block outbound SMTP and require the > > users to go THOUGH their mail servers even though those servers are > > not responsible for the domains in question! I know other mail > > servers are blocking non-reversible mail, however, is this common? > > And more importantly, is this an acceptable practice? > > > > It's both unacceptable in my opinion and common. There are even those > misguided souls that will tell you it is best practice, though general > agreement, even among them seems to be that only 25/tcp should be > blocked and that > 465 and 587 should not be blocked. > [dmb] I would agree, for residential customers, if they use the "ISP" domain, then yes they should relay though the ISPs mail server. For business customers and other residential customers that do NOT use the ISP domain, then I think they should use their own mail server that they already pay for. > > > > > > Most of our smaller ISPs that we support; we allow any outbound SMTP > > connection, however we do watch residential users for 5+ outbound SMTP > > connections at the same time. But if the ISP has their own mail > > > servers, and users wish to relay though them, we basically tell them > > to use their mail server that they contract with. What is the best > > practice? > > > > Best practice is to do what works and block as much SPAM as possible > without destroying the internet in the process. There are those who argue > that blocking 25/tcp does not destroy the internet. By and large, they are > the same ones who believe NAT was good for us. > > Owen [dmb] Lots of smaller ISPs out there run thousands of customers though NAT and I can see the need to properly "monitor" the SPAM activity on those IPs, not saying that is right, but I do see the point, in this event. But for ISPs that are handing out publics, I don't see how blocking outbound Port 25 helps, other than makes more support calls for the end users. Keep in mind that, ATT DSL and the local cable co here in STL, both block outbound port 25, but a simple phone call or e-mail to their support and they will remove the block. From nanog at data102.com Mon Oct 24 23:58:15 2011 From: nanog at data102.com (randal k) Date: Mon, 24 Oct 2011 22:58:15 -0600 Subject: Advice on BGP traffic engineering for classified traffic In-Reply-To: <4EA5E595.5080405@brightok.net> References: <4EA5E595.5080405@brightok.net> Message-ID: I have contemplated this exact scenario numerous times on how to provide various "tiers" of blended bandwidth. Ingress is handled by ip assignment + announcements, but egress almost *always* comes back to some sort extra core/distribution device to handle each tier, plus either mpls/l2vpn/dedicated-xcon/spanned-vlan to get the customer on that network. Cludgy at best, imo. I'd also love to hear how other datacenters or ISPs do this. Randal On Mon, Oct 24, 2011 at 4:24 PM, Jack Bates wrote: > I'm curious if anyone has a pointer on traffic manipulation for classified > traffic. Basics, I have a really cheap transit connection that some > customers are paying reduced rates to only use that connection (and not my > other transits). > From jbates at brightok.net Tue Oct 25 00:05:45 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 25 Oct 2011 00:05:45 -0500 Subject: Advice on BGP traffic engineering for classified traffic In-Reply-To: <10431869.5953.1319514438894.JavaMail.root@benjamin.baylink.com> References: <10431869.5953.1319514438894.JavaMail.root@benjamin.baylink.com> Message-ID: <4EA643A9.4060606@brightok.net> On 10/24/2011 10:47 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jack Bates" >> I'm curious if anyone has a pointer on traffic manipulation for >> classified traffic. > Based on the remainder of your post, I'm going to go ahead and assume that > you don't mean "classified traffic" in the sense that most people would infer > from that phrasing. > > Yeah, I was at a loss for terminology, and never could write a good subject line. Does, I need to do least cost routing for a substandard low-cost product work? Hey, I work for a telco, why fight it. :) Jack From swmike at swm.pp.se Tue Oct 25 00:27:43 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 25 Oct 2011 07:27:43 +0200 (CEST) Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: On Mon, 24 Oct 2011, Dennis Burgess wrote: > I am curious about what network operators are doing with outbound SMTP > traffic. Block all TCP/25 and require users to use submit with authentication on TCP/587. -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Tue Oct 25 01:13:19 2011 From: bill at herrin.us (William Herrin) Date: Tue, 25 Oct 2011 02:13:19 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess wrote: > I am curious about what network operators are doing with outbound SMTP > traffic. ?In the past few weeks we have ran into over 10 providers, > mostly local providers, which block outbound SMTP and require the users > to go THOUGH their mail servers even though those servers are not > responsible for the domains in question! ?I know other mail servers are > blocking non-reversible mail, however, is this common? ?And more > importantly, is this an acceptable practice? Hi Dennis, Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense. The SMTP submission port (TCP 587) is authenticated and should generally not be blocked. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From timphp at progressivemarketingnetwork.com Tue Oct 25 03:33:02 2011 From: timphp at progressivemarketingnetwork.com (Tim) Date: Tue, 25 Oct 2011 02:33:02 -0600 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <020101cc92f0$b7abaeb0$27030c10$@com> This sadly is very common. It is getting more common by the day it seems but this practice has started almost a decade ago. An easy work around is to use a custom port as they seem to just block port 25 as a bad port but leave just about everything else open including 2525 which seems to be a common secondary smtp port for hosting companies. From dhc2 at dcrocker.net Tue Oct 25 04:27:37 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 25 Oct 2011 11:27:37 +0200 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <4EA68109.9030601@dcrocker.net> On 10/25/2011 8:13 AM, William Herrin wrote: > Blocking outbound TCP SYN packets on port 25 from non-servers is > considered a BEST PRACTICE ... > The SMTP submission port (TCP 587) is authenticated and should > generally not be blocked. Email Submission Operations: Access and Accountability Requirements IETF BCP It does not explicitly support blocking outbound port 25, since that's controversial, but it /does/ require permitting outbound port 587. d/ > Regards, > Bill Herrin > > -- Dave Crocker Brandenburg InternetWorking bbiw.net From owen at delong.com Tue Oct 25 04:35:31 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 02:35:31 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote: > On Mon, 24 Oct 2011, Dennis Burgess wrote: > >> I am curious about what network operators are doing with outbound SMTP >> traffic. > > Block all TCP/25 and require users to use submit with authentication on TCP/587. > If they are using someone else's mail server for outbound, how, exactly do you control whether or not they use AUTH in the process? Further, if you make them use AUTH somehow, but, you don't force TLS, then, you are doing more harm than good IMHO. Owen From aftab.siddiqui at gmail.com Tue Oct 25 04:51:05 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 25 Oct 2011 14:51:05 +0500 Subject: Outgoing SMTP Servers In-Reply-To: <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> Message-ID: Blocking port/25 is a common practice (!= best practice) for home users/consumers because it makes life a bit simpler in educating the end user. ripe-409 gives some what glimpse of best-practice, not sure how many implements it that way. Regards, Aftab A. Siddiqui On Tue, Oct 25, 2011 at 2:35 PM, Owen DeLong wrote: > > On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote: > > > On Mon, 24 Oct 2011, Dennis Burgess wrote: > > > >> I am curious about what network operators are doing with outbound SMTP > >> traffic. > > > > Block all TCP/25 and require users to use submit with authentication on > TCP/587. > > > > If they are using someone else's mail server for outbound, how, exactly do > you control > whether or not they use AUTH in the process? > > Further, if you make them use AUTH somehow, but, you don't force TLS, then, > you are > doing more harm than good IMHO. > > Owen > > > From owen at delong.com Tue Oct 25 04:49:19 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 02:49:19 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> On Oct 24, 2011, at 11:13 PM, William Herrin wrote: > On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess > wrote: >> I am curious about what network operators are doing with outbound SMTP >> traffic. In the past few weeks we have ran into over 10 providers, >> mostly local providers, which block outbound SMTP and require the users >> to go THOUGH their mail servers even though those servers are not >> responsible for the domains in question! I know other mail servers are >> blocking non-reversible mail, however, is this common? And more >> importantly, is this an acceptable practice? > > Hi Dennis, > > Blocking outbound TCP SYN packets on port 25 from non-servers is > considered a BEST PRACTICE to avoid being the source of snowshoe and > botnet spam. Blocking it from legitimate mail servers... does not make > sense. > > The SMTP submission port (TCP 587) is authenticated and should > generally not be blocked. > Interesting... Most people I know run the same policy on 25 and 587 these days... to-local-domain, no auth needed. relay, auth needed. auth required == TLS required. Anything else on either port seems not best practice to me. Due to the absurd things I've seen done in the world, I actually run that policy on 5 ports: 25, 587 as you would expect. 465 SSL rather than STARTTLS, but, otherwise identical 80 because it works when nothing else does. 443 because sometimes Deep Packet Inspection is a PITA. Of course, using 80 and 443 requires the use of additional IP address resources for those servers rather than being able to also run a web server on the same address, but, this is the consequence of replacing an internet with 64K ports with filters that force the entire internet to operate all services on TCP/80. With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc. Owen From jeroen at unfix.org Tue Oct 25 05:04:47 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Oct 2011 12:04:47 +0200 Subject: Outgoing SMTP Servers In-Reply-To: <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: <4EA689BF.6060206@unfix.org> On 2011-10-25 11:49 , Owen DeLong wrote: [..] > With this combination, I have not encountered a hotel, airport lounge, or > other poorly run environment from which I cannot send mail through my > home server from my laptop/ipad/iphone/etc. Ever heard of this magical thing called a VPN? :) Indeed, that bypasses all those crappy local networks; and yes don't worry your iToy also has more than ample VPN abilities. Set up once and never have to bother about special configurations or getting around stupid filters. Greets, Jeroen From owen at delong.com Tue Oct 25 05:20:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 03:20:18 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <4EA689BF.6060206@unfix.org> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> Message-ID: <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote: > On 2011-10-25 11:49 , Owen DeLong wrote: > [..] >> With this combination, I have not encountered a hotel, airport lounge, or >> other poorly run environment from which I cannot send mail through my >> home server from my laptop/ipad/iphone/etc. > > Ever heard of this magical thing called a VPN? :) Sure, but, why deal with the overhead? Who wants to have to login to a VPN every time just to quickly retrieve or send some email? > > Indeed, that bypasses all those crappy local networks; and yes don't > worry your iToy also has more than ample VPN abilities. > Some do, some don't, and not all networks are any friendlier to VPNs than they are to port 25. > Set up once and never have to bother about special configurations or > getting around stupid filters. > Except where you have to or where there are so many layers of NAT that even VPNs don't work, or... I set up the 5 ports once and don't need any special configurations to get around stupid filters, stuff just works now. Owen From Valdis.Kletnieks at vt.edu Tue Oct 25 05:29:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Oct 2011 06:29:15 -0400 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Tue, 25 Oct 2011 02:35:31 PDT." <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> Message-ID: <18081.1319538555@turing-police.cc.vt.edu> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said: > If they are using someone else's mail server for outbound, how, exactly do you control > whether or not they use AUTH in the process? 1) You don't even really *care* if they do or not, because... 2) if some other site is running with an un-AUTHed open port 587, the miscreants will find it and abuse it just like any other open mail relay. The community will deal with it quick enough so you don't have to. And at that point, it's the open mail relay's IP that ends up on the block lists, not your mail relay's IP. Other people running open port 587s tends to be quite self-correcting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at unfix.org Tue Oct 25 06:15:00 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Oct 2011 13:15:00 +0200 Subject: Outgoing SMTP Servers In-Reply-To: <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> Message-ID: <4EA69A34.4080300@unfix.org> On 2011-10-25 12:20 , Owen DeLong wrote: > > On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote: > >> On 2011-10-25 11:49 , Owen DeLong wrote: >> [..] >>> With this combination, I have not encountered a hotel, airport lounge, or >>> other poorly run environment from which I cannot send mail through my >>> home server from my laptop/ipad/iphone/etc. >> >> Ever heard of this magical thing called a VPN? :) > > Sure, but, why deal with the overhead? Who wants to have to login to a > VPN every time just to quickly retrieve or send some email? On that iToy of yours it is just a flick of a switch, presto. >> Indeed, that bypasses all those crappy local networks; and yes don't >> worry your iToy also has more than ample VPN abilities. >> > > Some do, some don't, and not all networks are any friendlier to VPNs > than they are to port 25. And the final solution then tends to be setting up a VPN on port 443... Which only wastes one IP address, not several for different services. >> Set up once and never have to bother about special configurations or >> getting around stupid filters. >> > > Except where you have to or where there are so many layers of NAT that > even VPNs don't work, or... Unless this 'NAT' is actually a firewall doing DPI on the packets, I can't see any reason why a VPN which just uses TCP over port 443 can't work in that situation. Greets, Jeroen From deric.kwok2000 at gmail.com Tue Oct 25 07:26:25 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 25 Oct 2011 08:26:25 -0400 Subject: the route is not in our bgprouter Message-ID: Hi When we try to reach to outside ip, this route doesn't have in our bgp router How can we check whether it doesn't advertise from our upstream to us? Any web site and tools can help? Thank you From bjorn at mork.no Tue Oct 25 07:43:56 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 25 Oct 2011 14:43:56 +0200 Subject: Outgoing SMTP Servers In-Reply-To: <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> (Owen DeLong's message of "Mon, 24 Oct 2011 21:37:11 -0700") References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> Message-ID: <87aa8p6y2b.fsf@nemi.mork.no> Owen DeLong writes: > It's both unacceptable in my opinion and common. There are even those > misguided souls that will tell you it is best practice, though general agreement, > even among them seems to be that only 25/tcp should be blocked and that > 465 and 587 should not be blocked. It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK) The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local "best practice" whether you like it or not. Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout. Eh, this was the Northern Aurope NOG, wasn't it? Bj?rn From ahebert at pubnix.net Tue Oct 25 07:57:48 2011 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 25 Oct 2011 08:57:48 -0400 Subject: ARIN and Legacy IPv4 Assignement from CA*Net (Canarie) Message-ID: <4EA6B24C.6050300@pubnix.net> Hi, From what we've been seeing there is a lot of those legacy assignement about to be freed. ( Yeah! ) We're having some issue with a few Legacy that where miss-assigned when transfered from CA*Net to ARIN back in the day. ( We kept the control on them since we had access to the POC's and OrgID, which is not the case anymore for some reason ) If anyone has a hint (off-list please) about how to go about fixing those broken assignement, we had no luck finding the process on ARIN. I can only gather that there is no records left from the CA*Net merge :( Thanks. PS: Check your ARIN records if you have subnets in the 198., 199. and 205. just in case. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From patrick.sumby at sohonet.co.uk Tue Oct 25 08:35:34 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Tue, 25 Oct 2011 14:35:34 +0100 Subject: the route is not in our bgprouter In-Reply-To: References: Message-ID: <4EA6BB26.2050203@sohonet.co.uk> If your provider has a looking glass then that is a good start to see if they have the route in their routing tables. http://www.traceroute.org/ is a good start for searching for a looking glass on their website. Have you checked to see if you're actually recieving the route? You may be getting the route but not installing it into your routing table for some reason (eg invalid next hop or a router from another provider is being prefered). Do you have prefix lists inbound from your provider that could be blocking a route? show ip route X.X.X.X and show ip bgp route X.X.X.X will give different information. If you've covered the above and not found the answer then try talking to your provider. Regards Patrick On 25/10/2011 13:26, Deric Kwok wrote: > Hi > > When we try to reach to outside ip, this route doesn't have in our bgp router > > How can we check whether it doesn't advertise from our upstream to us? > > Any web site and tools can help? > > Thank you > From owen at delong.com Tue Oct 25 10:17:28 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 08:17:28 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <18081.1319538555@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> <18081.1319538555@turing-police.cc.vt.edu> Message-ID: On Oct 25, 2011, at 3:29 AM, wrote: > On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said: > >> If they are using someone else's mail server for outbound, how, exactly do you control >> whether or not they use AUTH in the process? > > 1) You don't even really *care* if they do or not, because... > > 2) if some other site is running with an un-AUTHed open port 587, the miscreants will > find it and abuse it just like any other open mail relay. The community will > deal with it quick enough so you don't have to. And at that point, it's the > open mail relay's IP that ends up on the block lists, not your mail relay's IP. > But that applies to port 25 also, so, I'm not understanding the difference. > Other people running open port 587s tends to be quite self-correcting. > At this point, so do open port 25s. Owen From carlosm3011 at gmail.com Tue Oct 25 10:28:05 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 25 Oct 2011 13:28:05 -0200 Subject: Outgoing SMTP Servers In-Reply-To: <87aa8p6y2b.fsf@nemi.mork.no> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> <87aa8p6y2b.fsf@nemi.mork.no> Message-ID: I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email. And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed. regards Carlos On Tue, Oct 25, 2011 at 10:43 AM, Bj?rn Mork wrote: > Owen DeLong writes: > >> It's both unacceptable in my opinion and common. There are even those >> misguided souls that will tell you it is best practice, though general agreement, >> even among them seems to be that only 25/tcp should be blocked and that >> 465 and 587 should not be blocked. > > It is definitely considered best practice in some areas. ?See e.g. > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf > (couldn't find an english original, but the google translation looks OK) > > The document is signed by all major ISPs in Norway as well as the > Norwegian research and education network operator, so it must be > considered a local "best practice" whether you like it or not. > > Note that only port 25/tcp is blocked and that some of the ISPs offer a > per-subscriber optout. > > Eh, this was the Northern Aurope NOG, wasn't it? > > > > > Bj?rn > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From owen at delong.com Tue Oct 25 10:24:09 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 08:24:09 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <4EA69A34.4080300@unfix.org> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: <13C3AB49-1CBA-4620-ADA7-5E7B20CB1E28@delong.com> On Oct 25, 2011, at 4:15 AM, Jeroen Massar wrote: > On 2011-10-25 12:20 , Owen DeLong wrote: >> >> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote: >> >>> On 2011-10-25 11:49 , Owen DeLong wrote: >>> [..] >>>> With this combination, I have not encountered a hotel, airport lounge, or >>>> other poorly run environment from which I cannot send mail through my >>>> home server from my laptop/ipad/iphone/etc. >>> >>> Ever heard of this magical thing called a VPN? :) >> >> Sure, but, why deal with the overhead? Who wants to have to login to a >> VPN every time just to quickly retrieve or send some email? > > On that iToy of yours it is just a flick of a switch, presto. > On anything, a VPN is a diversion of your traffic through a tunnel with additional overhead for encryption and encapsulation headers. >>> Indeed, that bypasses all those crappy local networks; and yes don't >>> worry your iToy also has more than ample VPN abilities. >>> >> >> Some do, some don't, and not all networks are any friendlier to VPNs >> than they are to port 25. > > And the final solution then tends to be setting up a VPN on port 443... > Which only wastes one IP address, not several for different services. > Meh, there are plenty of IP addresses. The shortage is limited to this legacy v4 stuff. When the hotel networks and such catch up to the modern internet, I can stop running these extra addresses on IPv4 and it won't matter. >>> Set up once and never have to bother about special configurations or >>> getting around stupid filters. >>> >> >> Except where you have to or where there are so many layers of NAT that >> even VPNs don't work, or... > > Unless this 'NAT' is actually a firewall doing DPI on the packets, I > can't see any reason why a VPN which just uses TCP over port 443 can't > work in that situation. > You would think, but, I have seen them break. OTOH, most of my VPNs are IPSEC, not SSL, so that's another issue. There would be significant additional overhead in setting up an SSL VPN. Admittedly, it's one-time overhead, but, again, I don't see a reason to bother. Owen From bill at herrin.us Tue Oct 25 10:46:05 2011 From: bill at herrin.us (William Herrin) Date: Tue, 25 Oct 2011 11:46:05 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong wrote: > On Oct 24, 2011, at 11:13 PM, William Herrin wrote: >> Blocking outbound TCP SYN packets on port 25 from non-servers is >> considered a BEST PRACTICE to avoid being the source of snowshoe and >> botnet spam. Blocking it from legitimate mail servers... does not make >> sense. >> >> The SMTP submission port (TCP 587) is authenticated and should >> generally not be blocked. > > Interesting... Most people I know run the same policy on 25 and 587 these > days... Owen, Perhaps you misunderstand the issue. The issue is not relaying mail through someone else's mail server, it's delivering mail to a mailbox served by that mail server. 99.99 etc. percent of the time when that's done directly from a IP address that's supposed to be user PC it's some form of spam. Hence the best practice within the email community is to ask the networking community to block those packets outright. And its why residential ISPs who fail to tend to find their way into Spamcop, Spamhaus and others. Facilitating that sort of network filtering is precisely why authenticated SMTP relaying was assigned port 587 instead of leaving it on port 25. On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo wrote: > I'm curious how a traveller is supposed to get SMTP relay service > when, well, travelling. I am not really sure if I want a VPN for > sending a simple email. That's what the SMTP submission port (TCP 587) is intended for and it's why outbound 587 should not be blocked. In fact, blocking 587 can cause problems with folks who use the Sender Policy Framework to restrict the servers allowed to pass mail from a particular domain outward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Tue Oct 25 10:49:10 2011 From: jcurran at arin.net (John Curran) Date: Tue, 25 Oct 2011 15:49:10 +0000 Subject: ARIN and Legacy IPv4 Assignement from CA*Net (Canarie) In-Reply-To: <4EA6B24C.6050300@pubnix.net> References: <4EA6B24C.6050300@pubnix.net> Message-ID: On Oct 25, 2011, at 12:57 PM, Alain Hebert wrote: > > Hi, > > From what we've been seeing there is a lot of those legacy assignement about to be freed. ( Yeah! ) > > We're having some issue with a few Legacy that where miss-assigned when transfered from CA*Net to ARIN back in the day. > ( We kept the control on them since we had access to the POC's and OrgID, which is not the case anymore for some reason ) > > If anyone has a hint (off-list please) about how to go about fixing those broken assignement, we had no luck finding the process on ARIN. Alain - Please send email to with specifics. You'll need an officer to attest to the error made in the registrations, but it's clear that Pubnix has been the one using the address blocks in question. Thanks, /John John Curran President and CEO ARIN From dmburgess at linktechs.net Tue Oct 25 10:57:24 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 25 Oct 2011 10:57:24 -0500 Subject: Outgoing SMTP Servers References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> <87aa8p6y2b.fsf@nemi.mork.no> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA685C5@ltiserver.lti.local> > > I'm curious how a traveller is supposed to get SMTP relay service when, well, > travelling. I am not really sure if I want a VPN for sending a simple email. > > And I can understand (although I am not convinced that doing so is such a > great idea) blocking 25/tcp outgoing, as most botnets will try that method of > delivery. However, I do believe that outgoing 465 SHOULD always be > allowed. > > regards > > Carlos > [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port. > On Tue, Oct 25, 2011 at 10:43 AM, Bj?rn Mork wrote: > > Owen DeLong writes: > > > >> It's both unacceptable in my opinion and common. There are even those > >> misguided souls that will tell you it is best practice, though > >> general agreement, even among them seems to be that only 25/tcp > >> should be blocked and that > >> 465 and 587 should not be blocked. > > > > It is definitely considered best practice in some areas. ?See e.g. > > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c > > ontent/uploads/2010/10/bransjenorm-SPAM.pdf > > (couldn't find an english original, but the google translation looks > > OK) > > > > The document is signed by all major ISPs in Norway as well as the > > Norwegian research and education network operator, so it must be > > considered a local "best practice" whether you like it or not. > > > > Note that only port 25/tcp is blocked and that some of the ISPs offer > > a per-subscriber optout. > > > > Eh, this was the Northern Aurope NOG, wasn't it? > > > > > > > > > > Bj?rn > > > > > > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > ========================= From dave at mvn.net Tue Oct 25 11:05:24 2011 From: dave at mvn.net (David E. Smith) Date: Tue, 25 Oct 2011 11:05:24 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685C5@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> <87aa8p6y2b.fsf@nemi.mork.no> <13175F96BDC3B34AB1425BAE905B3CE50BA685C5@ltiserver.lti.local> Message-ID: On Tue, Oct 25, 2011 at 10:57, Dennis Burgess wrote: > > [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY > network. Your domain has a mail server out on the net that if you > authenticate to, I am sure will relay your mail, and the reverse DNS and SPF > records would match then as well. Why does the local internet provide NEED > to relay though their server, regardless of the port. > > Not every domain actually has a mail server that allows remote authentication/relay. People hosting small vanity domains with cheap hosting providers might not. Maybe people using small ISPs with less-than-top-notch staff. Heck, maybe there's just a short-term issue with the mail server, and you still want/need to send something out right now, so you use your ISP's mail system. David Smith MVN.net From randy at psg.com Tue Oct 25 11:07:56 2011 From: randy at psg.com (Randy Bush) Date: Tue, 25 Oct 2011 09:07:56 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> <87aa8p6y2b.fsf@nemi.mork.no> Message-ID: > I'm curious how a traveller is supposed to get SMTP relay service > when, well, travelling. I am not really sure if I want a VPN for > sending a simple email. vpn i use openvpn when roaming, i am often on poorly protected wireless. i openvpn to home randy From jml at packetpimp.org Tue Oct 25 11:58:29 2011 From: jml at packetpimp.org (Jason LeBlanc) Date: Tue, 25 Oct 2011 12:58:29 -0400 Subject: Senate Bill S.968 Message-ID: <4EA6EAB5.2060305@packetpimp.org> Anyone read this? http://en.wikipedia.org/wiki/Protect_IP_Act More attempts to regulate Internet usage. Not in favor. Jason From owen at delong.com Tue Oct 25 11:55:58 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 09:55:58 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> On Oct 25, 2011, at 8:46 AM, William Herrin wrote: > On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong wrote: >> On Oct 24, 2011, at 11:13 PM, William Herrin wrote: >>> Blocking outbound TCP SYN packets on port 25 from non-servers is >>> considered a BEST PRACTICE to avoid being the source of snowshoe and >>> botnet spam. Blocking it from legitimate mail servers... does not make >>> sense. >>> >>> The SMTP submission port (TCP 587) is authenticated and should >>> generally not be blocked. >> >> Interesting... Most people I know run the same policy on 25 and 587 these >> days... > > Owen, > > Perhaps you misunderstand the issue. The issue is not relaying mail > through someone else's mail server, it's delivering mail to a mailbox > served by that mail server. 99.99 etc. percent of the time when that's > done directly from a IP address that's supposed to be user PC it's > some form of spam. Hence the best practice within the email community > is to ask the networking community to block those packets outright. > And its why residential ISPs who fail to tend to find their way into > Spamcop, Spamhaus and others. Facilitating that sort of network > filtering is precisely why authenticated SMTP relaying was assigned > port 587 instead of leaving it on port 25. > Wouldn't the right place for that form of rejection to occur be at the mail server in question? Precluding users doing legitimate things just because there are users who do illegitimate things is damaging to the internet and I will continue to route around it. I reject lots of residential connections to my port 25 services every day. However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine. > > On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo > wrote: >> I'm curious how a traveller is supposed to get SMTP relay service >> when, well, travelling. I am not really sure if I want a VPN for >> sending a simple email. > > That's what the SMTP submission port (TCP 587) is intended for and > it's why outbound 587 should not be blocked. In fact, blocking 587 can > cause problems with folks who use the Sender Policy Framework to > restrict the servers allowed to pass mail from a particular domain > outward. > So the spammers move to 587 and problem solved. Owen From mmcbride at westhost.com Tue Oct 25 12:27:45 2011 From: mmcbride at westhost.com (Matt McBride) Date: Tue, 25 Oct 2011 17:27:45 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> Message-ID: We use Mailchannels to route all outbound mail through it, which does a decent job of keeping garbage off the Internet and SBLs/RBLs clean. It is dependent on PBR so there is overhead to manage it but the product runs on our own hardware. -Matt -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, October 25, 2011 10:56 AM To: William Herrin Cc: nanog at nanog.org Subject: Re: Outgoing SMTP Servers On Oct 25, 2011, at 8:46 AM, William Herrin wrote: > On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong wrote: >> On Oct 24, 2011, at 11:13 PM, William Herrin wrote: >>> Blocking outbound TCP SYN packets on port 25 from non-servers is >>> considered a BEST PRACTICE to avoid being the source of snowshoe and >>> botnet spam. Blocking it from legitimate mail servers... does not make >>> sense. >>> >>> The SMTP submission port (TCP 587) is authenticated and should >>> generally not be blocked. >> >> Interesting... Most people I know run the same policy on 25 and 587 these >> days... > > Owen, > > Perhaps you misunderstand the issue. The issue is not relaying mail > through someone else's mail server, it's delivering mail to a mailbox > served by that mail server. 99.99 etc. percent of the time when that's > done directly from a IP address that's supposed to be user PC it's > some form of spam. Hence the best practice within the email community > is to ask the networking community to block those packets outright. > And its why residential ISPs who fail to tend to find their way into > Spamcop, Spamhaus and others. Facilitating that sort of network > filtering is precisely why authenticated SMTP relaying was assigned > port 587 instead of leaving it on port 25. > Wouldn't the right place for that form of rejection to occur be at the mail server in question? Precluding users doing legitimate things just because there are users who do illegitimate things is damaging to the internet and I will continue to route around it. I reject lots of residential connections to my port 25 services every day. However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine. > > On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo > wrote: >> I'm curious how a traveller is supposed to get SMTP relay service >> when, well, travelling. I am not really sure if I want a VPN for >> sending a simple email. > > That's what the SMTP submission port (TCP 587) is intended for and > it's why outbound 587 should not be blocked. In fact, blocking 587 can > cause problems with folks who use the Sender Policy Framework to > restrict the servers allowed to pass mail from a particular domain > outward. > So the spammers move to 587 and problem solved. Owen From tayeb.meftah at gmail.com Mon Oct 24 11:18:08 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 24 Oct 2011 19:18:08 +0300 Subject: HE.Net 6TO4 relay Message-ID: hello HE.NET did you drop the 6to4 delegated prefix 192.88.99.0/24 ? if yes please would you drop it from your BGP routing table anounced ? thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6573 (20111025) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From brian.peter.dickson at gmail.com Tue Oct 25 13:05:00 2011 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Tue, 25 Oct 2011 14:05:00 -0400 Subject: Outgoing SMTP Servers Message-ID: Owen wrote: >On Oct 25, 2011, at 3:29 AM, wrote: > >> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said: >> >>> If they are using someone else's mail server for outbound, how, exactly do you control >>> whether or not they use AUTH in the process? >> >> 1) You don't even really *care* if they do or not, because... >> >> 2) if some other site is running with an un-AUTHed open port 587, the miscreants will >> find it and abuse it just like any other open mail relay. The community will >> deal with it quick enough so you don't have to. And at that point, it's the >> open mail relay's IP that ends up on the block lists, not your mail relay's IP. >> >But that applies to port 25 also, so, I'm not understanding the difference. > >> Other people running open port 587s tends to be quite self-correcting. >> > >At this point, so do open port 25s. > >Owen I'll try to explain with text stick-diagrams... The players are: G - good user B - botnet host I - ISP O - open relay S - mail-submission relay V - victim SMTP/mailbox host It's all about how port-25 traffic containing SPAM gets to machine "V". (Or not, which is the preferred situation.) Possible routes include: B.25 -> (I allows 25) -> O -> V (classic open relay) [SPAM] B.25 -> (I allows 25) -> V (new mode, and what William Herrin is talking about) [SPAM] B.587 -> (I !allow 25) -> V (but that makes no sense - how does B authenticate to the victim? She doesn't!!) [BLOCKED] B.587 -> (I !allow 25) -> S (ditto - not an open unauthenticated relay, only allows authenticated relaying!!!) [BLOCKED] Meanwhile, we have: G.587 -> (I !allow 25) -> S.g.587/.25 (mail submission gateway for G) -> V.25 [NOT-SPAM && NOT-BLOCKED] S.g is either G's enterprise mail server, or G's home mail server, or G's ISP themselves, or some other S to which G can authenticate. S.g receives on 587, and sends on 25, and is a generally reputable port-25 host (whatever that means). So, basically, not blocking 587 and blocking 25 removes all the avenues for direct botnet spam. Authenticating botnet sources become trackable on auth-hosts, and easy to shut down. Is there some path not listed above that could allow a spammer (botnet host) behind the ISP to send email, without having a relay host to which it can authenticate, that I'm not seeing? Brian From ravi at cow.org Tue Oct 25 13:18:23 2011 From: ravi at cow.org (Ravi Pina) Date: Tue, 25 Oct 2011 14:18:23 -0400 Subject: Vancouver, BC providers Message-ID: <20111025181823.GA56866@neu.cow.org> Hi, I was looking for some metro-e options in Vancouver, BC CA specifically in the Downtown/Gastown area. I'm finding the area isn't the most built up so options are very thin. We already have service through Level3, but would like a secondary one. It doesn't have to be tier1 or even terrestrial service so much as reliable and vouched for. Any tips would be appreciated. Thanks, -r From deleskie at gmail.com Tue Oct 25 13:21:13 2011 From: deleskie at gmail.com (jim deleskie) Date: Tue, 25 Oct 2011 15:21:13 -0300 Subject: Vancouver, BC providers In-Reply-To: <20111025181823.GA56866@neu.cow.org> References: <20111025181823.GA56866@neu.cow.org> Message-ID: I'd expect you could find, Rogers, Telus, Shaw and Bell all there. -jim On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina wrote: > Hi, > > I was looking for some metro-e options in Vancouver, BC CA > specifically in the Downtown/Gastown area. ?I'm finding the area > isn't the most built up so options are very thin. > > We already have service through Level3, but would like a > secondary one. ?It doesn't have to be tier1 or even terrestrial > service so much as reliable and vouched for. > > Any tips would be appreciated. > > Thanks, > > -r > > > From ravi at cow.org Tue Oct 25 13:27:38 2011 From: ravi at cow.org (Ravi Pina) Date: Tue, 25 Oct 2011 14:27:38 -0400 Subject: Vancouver, BC providers In-Reply-To: References: <20111025181823.GA56866@neu.cow.org> Message-ID: <20111025182738.GB56866@neu.cow.org> I suppose I could have been a little more clear on what I've already found. Sorry. The last mile for the Level3 is coming on Telus (after a punch to the face and gut for build out fee) so I'd like someone else. Shaw does not offer service without what I suspect is another punch to the face for a build out. Bell didn't return any of my inquiries via email of voice message. -r On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote: > I'd expect you could find, Rogers, Telus, Shaw and Bell all there. > > > -jim > > On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina wrote: > > Hi, > > > > I was looking for some metro-e options in Vancouver, BC CA > > specifically in the Downtown/Gastown area. ?I'm finding the area > > isn't the most built up so options are very thin. > > > > We already have service through Level3, but would like a > > secondary one. ?It doesn't have to be tier1 or even terrestrial > > service so much as reliable and vouched for. > > > > Any tips would be appreciated. > > > > Thanks, > > > > -r > > > > > > From erik.soosalu at calyxinc.com Tue Oct 25 13:30:33 2011 From: erik.soosalu at calyxinc.com (Erik Soosalu) Date: Tue, 25 Oct 2011 14:30:33 -0400 Subject: Vancouver, BC providers In-Reply-To: <20111025182738.GB56866@neu.cow.org> References: <20111025181823.GA56866@neu.cow.org> <20111025182738.GB56866@neu.cow.org> Message-ID: <0B224A2FE01CC54C860290D42474BF600510F132@exchange.nff.local> May not suit your needs, but I've used Terago with some success for secondary links. Thanks, Erik Soosalu -----Original Message----- From: Ravi Pina [mailto:ravi at cow.org] Sent: Tuesday, October 25, 2011 2:28 PM To: jim deleskie Cc: nanog at nanog.org Subject: Re: Vancouver, BC providers I suppose I could have been a little more clear on what I've already found. Sorry. The last mile for the Level3 is coming on Telus (after a punch to the face and gut for build out fee) so I'd like someone else. Shaw does not offer service without what I suspect is another punch to the face for a build out. Bell didn't return any of my inquiries via email of voice message. -r On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote: > I'd expect you could find, Rogers, Telus, Shaw and Bell all there. > > > -jim > > On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina wrote: > > Hi, > > > > I was looking for some metro-e options in Vancouver, BC CA > > specifically in the Downtown/Gastown area. ?I'm finding the area > > isn't the most built up so options are very thin. > > > > We already have service through Level3, but would like a > > secondary one. ?It doesn't have to be tier1 or even terrestrial > > service so much as reliable and vouched for. > > > > Any tips would be appreciated. > > > > Thanks, > > > > -r > > > > > > From lyndon at orthanc.ca Tue Oct 25 13:39:11 2011 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Tue, 25 Oct 2011 11:39:11 -0700 Subject: Vancouver, BC providers In-Reply-To: <20111025182738.GB56866@neu.cow.org> Message-ID: > The last mile for the Level3 is coming on Telus (after a punch to > the face and gut for build out fee) so I'd like someone else. > Shaw does not offer service without what I suspect is another > punch to the face for a build out. Bell didn't return any of my > inquiries via email of voice message. You will pay for buildout no matter who you talk to. Somebody already mentioned Terago. I can't vouch for how good their service or coverage is downtown, but they're definately worth a call if you can't afford the cost of the fibre pull. --lyndon From ryan at deadfrog.net Tue Oct 25 13:40:14 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Tue, 25 Oct 2011 13:40:14 -0500 Subject: Vancouver, BC providers In-Reply-To: <20111025182738.GB56866@neu.cow.org> References: <20111025181823.GA56866@neu.cow.org> <20111025182738.GB56866@neu.cow.org> Message-ID: <47256B31-3CA7-4F6E-A6EA-55860AAA5E35@deadfrog.net> Sounds like a possible candidate for some of the last mile wireless equipment available. The problem is the wireless equipment may cost more than the punch to the face and gut. How much bandwidth are you talking? You're looking at somewhere around $16k for a 300 Mbps Motorola PTP 800 solution at 18 or 23 GHz. BridgeWave has some 1 Gbps stuff out there for about $30k at 80 GHz, but falls out during very heavy rains at 2 miles link distance. BridgeWave just recently announced some 1 Gbps radio links at 18 and 23 but that's all I know about them. Ryan On Oct 25, 2011, at 1:27 PM, Ravi Pina wrote: > I suppose I could have been a little more clear on what I've > already found. Sorry. > > The last mile for the Level3 is coming on Telus (after a punch to > the face and gut for build out fee) so I'd like someone else. > Shaw does not offer service without what I suspect is another > punch to the face for a build out. Bell didn't return any of my > inquiries via email of voice message. > > -r > > On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote: >> I'd expect you could find, Rogers, Telus, Shaw and Bell all there. >> >> >> -jim >> >> On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina wrote: >>> Hi, >>> >>> I was looking for some metro-e options in Vancouver, BC CA >>> specifically in the Downtown/Gastown area. I'm finding the area >>> isn't the most built up so options are very thin. >>> >>> We already have service through Level3, but would like a >>> secondary one. It doesn't have to be tier1 or even terrestrial >>> service so much as reliable and vouched for. >>> >>> Any tips would be appreciated. >>> >>> Thanks, >>> >>> -r >>> >>> >>> > From cjp at 0x1.net Tue Oct 25 13:43:00 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Tue, 25 Oct 2011 14:43:00 -0400 Subject: Colocation providers and ACL requests Message-ID: Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: deny udp any a.b.c.d/24 eq 80 ?to refuse and tell us we must subscribe to their managed DDOS product? -cjp From mleber at he.net Tue Oct 25 13:42:59 2011 From: mleber at he.net (Mike Leber) Date: Tue, 25 Oct 2011 11:42:59 -0700 Subject: HE.Net 6TO4 relay In-Reply-To: References: Message-ID: <4EA70333.1060705@he.net> On 10/24/11 9:18 AM, Meftah Tayeb wrote: > hello HE.NET > did you drop the 6to4 delegated prefix 192.88.99.0/24 ? > if yes please would you drop it from your BGP routing table anounced ? > thank you > Meftah Tayeb > IT Consulting Hi! For issues like this please email ipv6 at he.net or noc at he.net with IPv4 and IPv6 traceroutes to the addresses involved. We are running and announcing 6to4 relays globally. We did recently turn on IPv6 RPF facing our 6to4 relays. This was done for basic network security reasons. There has been no change in traffic levels through our 6to4 relays, however it does appear to have affected a very limited number of people (I know of 1 other we already helped, you would be the second if this is your issue) that were using our 6to4 boxes to de-encapsulate packets with IPv6 source addresses not in the IPv6 6to4 range. If this was you, the fix is to either: 1) interconnect natively with us and announce your IPv6 address space to us via BGP (and don't use 6to4) 2) use your own already existing native IPv6 connectivity with your address space (and don't use 6to4) 3) make packets that you send to our 6to4 relays source from your 6to4 interface with your IPv6 6to4 address or 4) request a IPv6 BGP tunnel and run BGP so that you can announce your address space to us (and don't use 6to4). If you email us we can work with you to diagnose your specific situation. Mike. From keegan.holley at sungard.com Tue Oct 25 13:46:38 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 25 Oct 2011 14:46:38 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: Depends on the provider. Many just do not want to manage hundreds of customer ACL's on access routers. Especially when it would compete with a managed service (firewall, IDP, DDOS) of some sort. Some still are under the impression that ACL's are software based and their giant $100k+ edge box would crash if they configured them for any reason. 2011/10/25 Christopher Pilkington > Is it common in the industry for a colocation provider, when requested to > put an egress ACL facing us such as: > > deny udp any a.b.c.d/24 eq 80 > > ?to refuse and tell us we must subscribe to their managed DDOS product? > > -cjp > > > > From brandon.galbraith at gmail.com Tue Oct 25 13:50:37 2011 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 25 Oct 2011 13:50:37 -0500 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley wrote: > Depends on the provider. Many just do not want to manage hundreds of > customer ACL's on access routers. Especially when it would compete with a > managed service (firewall, IDP, DDOS) of some sort. Some still are under > the impression that ACL's are software based and their giant $100k+ edge > box > would crash if they configured them for any reason. > > Conversely, some don't want to be paid for bare colocation (at bare colocation prices) and have to then support 1000+ rules (yes, 1000+) with 10-20 change requests per day. YMMV/slippery slope/service scope/etc. From tayeb.meftah at gmail.com Mon Oct 24 12:17:38 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 24 Oct 2011 20:17:38 +0300 Subject: HE.Net 6TO4 relay References: <4EA70333.1060705@he.net> Message-ID: Dear Mike i would say thank you a lot for your valuable reply :) Alex brock allready replied to my query issue is only in Chicago, New york is perfectly up and runing :) Thank you ! ----- Original Message ----- From: "Mike Leber" To: Sent: Tuesday, October 25, 2011 9:42 PM Subject: Re: HE.Net 6TO4 relay > > On 10/24/11 9:18 AM, Meftah Tayeb wrote: >> hello HE.NET >> did you drop the 6to4 delegated prefix 192.88.99.0/24 ? >> if yes please would you drop it from your BGP routing table anounced ? >> thank you >> Meftah Tayeb >> IT Consulting > > Hi! > > For issues like this please email ipv6 at he.net or noc at he.net with IPv4 and > IPv6 traceroutes to the addresses involved. > > We are running and announcing 6to4 relays globally. > > We did recently turn on IPv6 RPF facing our 6to4 relays. This was done > for basic network security reasons. > > There has been no change in traffic levels through our 6to4 relays, > however it does appear to have affected a very limited number of people (I > know of 1 other we already helped, you would be the second if this is your > issue) that were using our 6to4 boxes to de-encapsulate packets with IPv6 > source addresses not in the IPv6 6to4 range. > > If this was you, the fix is to either: > > 1) interconnect natively with us and announce your IPv6 address space to > us via BGP (and don't use 6to4) > 2) use your own already existing native IPv6 connectivity with your > address space (and don't use 6to4) > 3) make packets that you send to our 6to4 relays source from your 6to4 > interface with your IPv6 6to4 address > or 4) request a IPv6 BGP tunnel and run BGP so that you can announce your > address space to us (and don't use 6to4). > > If you email us we can work with you to diagnose your specific situation. > > Mike. > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6573 (20111025) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6573 (20111025) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From cjp at 0x1.net Tue Oct 25 13:53:58 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Tue, 25 Oct 2011 14:53:58 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: <5B2D20A1-AABF-409B-BE60-220732D5CAD6@0x1.net> On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote: > On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley wrote: > >> Depends on the provider. Many just do not want to manage hundreds of >> > Conversely, some don't want to be paid for bare colocation (at bare > colocation prices) and have to then support 1000+ rules (yes, 1000+) with This is a large colo provider on the Upper West Side of Manhattan, so I (naively) expected more of them. It looks like this will be their final nail though. -cjp From paul4004 at gmail.com Tue Oct 25 14:07:36 2011 From: paul4004 at gmail.com (PC) Date: Tue, 25 Oct 2011 13:07:36 -0600 Subject: Colocation providers and ACL requests In-Reply-To: <5B2D20A1-AABF-409B-BE60-220732D5CAD6@0x1.net> References: <5B2D20A1-AABF-409B-BE60-220732D5CAD6@0x1.net> Message-ID: Why not put the ACL on your ingress side at your switch or router? I would typically not expect a colo provider to provide this service unless I'm paying extra for it. The smaller they are, the more likely they are to do so to keep you happy, but I certainly wouldn't be asking this request unless it was some 11th hour DOS-prevention request. Even then, they may not want to install this ACL as ultimately they should be billing you for this UDP traffic (which this ACL, may prevent their billing system from metering). On Tue, Oct 25, 2011 at 12:53 PM, Christopher Pilkington wrote: > On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote: > > > On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley < > keegan.holley at sungard.com>wrote: > > > >> Depends on the provider. Many just do not want to manage hundreds of > >> > > Conversely, some don't want to be paid for bare colocation (at bare > > colocation prices) and have to then support 1000+ rules (yes, 1000+) with > > This is a large colo provider on the Upper West Side of Manhattan, so I > (naively) expected more of them. It looks like this will be their final > nail though. > > -cjp > > > From keegan.holley at sungard.com Tue Oct 25 14:08:20 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 25 Oct 2011 15:08:20 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: 2011/10/25 Brandon Galbraith > On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley wrote: > >> Depends on the provider. Many just do not want to manage hundreds of >> customer ACL's on access routers. Especially when it would compete with a >> managed service (firewall, IDP, DDOS) of some sort. Some still are under >> the impression that ACL's are software based and their giant $100k+ edge >> box >> would crash if they configured them for any reason. >> >> > Conversely, some don't want to be paid for bare colocation (at bare > colocation prices) and have to then support 1000+ rules (yes, 1000+) with > 10-20 change requests per day. YMMV/slippery slope/service scope/etc. > They are no worse than route filters or bandwidth increases, or IP address requests/changes. The provider should be able to do a temporary filter if the customer needs it though rather than forcing them to wait weeks or months to install a managed service/device. I agree permanent custom ACL's with indefinite growth/management could be considered a managed service and should either be an additional charge or not allowed at all. From jfbeam at gmail.com Tue Oct 25 14:31:55 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 25 Oct 2011 15:31:55 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> Message-ID: On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong wrote: > Wouldn't the right place for that form of rejection to occur be at the > mail server in question? In a perfect world, yes. When you find a perfect world, send us an invite. > I reject lots of residential connections... The real issue here is *KNOWING* who is residential or not. Only the ISP knows for sure; and they rarely tell others. The various blocklists are merely guessing. Using a rDNS name is an even worse guess. > However, senders who authenticate legitimately or legitimate sources > of email (and yes, some spam sources too) connect just fine. Authenticated sources can be traced and shutoff. If a random cablemodem user has some bot spewing spam, the only way to cut off the spam is to either (gee) block outbound port 25, or turn their connection off entirely. As a responsible admin, I'll take the least disruptive path. (I'll even preemptively do so.) --Ricky From jfbeam at gmail.com Tue Oct 25 14:46:55 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 25 Oct 2011 15:46:55 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EA69A34.4080300@unfix.org> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: On Tue, 25 Oct 2011 07:15:00 -0400, Jeroen Massar wrote: > On that iToy of yours it is just a flick of a switch, presto. Where "flick of a switch" is actually several steps... Settings -> Network -> VPN... there's your switch. Wait for it to connect Go back to mail, refresh... And one's VPN profile has to be setup in advance. Plus, it doesn't always work. I gather you've never been in a network where an IPSec VPN wouldn't connect. I've seen it too many times. (I've even seen ISPs where it didn't work. Apparently GRE isn't IP to them.) An SSL VPN will often get around that, but it's additional hardware/software/setup/licenses/etc. (For a Cisco ASA, it's an additional word in your vpn setup, and a license... base "demo" is only 2 connections.) It's *MUCH* easier to setup the mail server on ports 465 and 587, require auth and tls. Done right, it's 100% transparent to the traveling user. Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.) --Ricky From a.harrowell at gmail.com Tue Oct 25 14:52:46 2011 From: a.harrowell at gmail.com (Alex Harrowell) Date: Tue, 25 Oct 2011 20:52:46 +0100 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: Ricky Beam wrote: >Works perfectly even in networks where a VPN doesn't and the idiot >hotel >intercepts port 25 (not blocks, redirects to *their* server.) > >--Ricky Why do they do that? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From bonomi at mail.r-bonomi.com Tue Oct 25 15:14:33 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 25 Oct 2011 15:14:33 -0500 (CDT) Subject: Outgoing SMTP Servers In-Reply-To: Message-ID: <201110252014.p9PKEXrw049195@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Tue Oct 25 14:53:32 2011 > Subject: Re: Outgoing SMTP Servers > From: Alex Harrowell > Date: Tue, 25 Oct 2011 20:52:46 +0100 > To: Ricky Beam , Jeroen Massar > Cc: nanog at nanog.org > > Ricky Beam wrote: > > >Works perfectly even in networks where a VPN doesn't and the idiot > >hotel > >intercepts port 25 (not blocks, redirects to *their* server.) > > > >--Ricky > > Why do they do that? Because some "quarter-asswit"[1] sold them that it was a good idea -- maybe on the basis tht it was: "easy" to to rate-limit -- supposedly an anti-spam measure; "easy" to 'forward' all the patron traffic to a relay server of the hotel's choice, so that, -if- it is spam, the outside world sees it coming from an already segregated address-space; "easy" to implement a holding queue, so that if they _do_ detect spam, they can drop _all_ the spam messages, even those sent before the spam threshold was detected.; etc., etc., ad nauseum. [1] "half-assed half-wit", reduced to a single term. From mike at mikejones.in Tue Oct 25 16:03:20 2011 From: mike at mikejones.in (Mike Jones) Date: Tue, 25 Oct 2011 22:03:20 +0100 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: On 25 October 2011 20:52, Alex Harrowell wrote: > Ricky Beam wrote: > >>Works perfectly even in networks where a VPN doesn't and the idiot >>hotel >>intercepts port 25 (not blocks, redirects to *their* server.) >> >>--Ricky > > Why do they do that? > My home ISP run an open relay on port 25 with IP-based authentication, so I might configure my laptops email client to send email via smtp.myisp.com port 25 (many/most? residential ISPs have unauthenticated relays, even ISPs that tell you to use authentication often have another server next to it that doesn't need authentication for customer IP space) If the hotel simply blocks port 25 then my email is broken, if they allow it then my email is broken (as my ISP doesn't let the hotel relay through their mail servers), however if the hotel redirects 25 to their own open relays then in theory my email should work fine. They could always tell people "there is a relay at 10.0.0.25 so you can change your settings to use that", however by redirecting all port 25 traffic there they are effectively forcibly auto-configuring anyone who was already configured to send via an unauthenticated server on port 25. They are probably acting under the assumption that the only people using 25 are using it for unauthenticated access, I believe most servers that do use authentication tell users to use alternate ports so this is probably a reasonable assumption. Compared to straight blocking of port 25 it's probably better as long as the relay it is redirecting you to works properly so you don't have to try and diagnose issues - However considering the quality of the average hotel network I suspect most of them that are trying to do this probably have it set to redirect to a dead server anyway. - Mike From owen at delong.com Tue Oct 25 16:56:17 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 15:56:17 -0600 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> No no no no no. The problem with your theory below is that: 1. It is by far best for users to authenticate to send mail. 2. Your "solution" works only for unencrypted unauthenticated users that ignore the certificate presented by the mail server. Put another way, your mechanism rewards those doing the wrong thing while punishing those of us sending our email via encrypted and authenticated mechanisms. That's a very bad thing. Owen Sent from my iPhone On Oct 25, 2011, at 15:03, Mike Jones wrote: > On 25 October 2011 20:52, Alex Harrowell wrote: >> Ricky Beam wrote: >> >>> Works perfectly even in networks where a VPN doesn't and the idiot >>> hotel >>> intercepts port 25 (not blocks, redirects to *their* server.) >>> >>> --Ricky >> >> Why do they do that? >> > > My home ISP run an open relay on port 25 with IP-based authentication, > so I might configure my laptops email client to send email via > smtp.myisp.com port 25 (many/most? residential ISPs have > unauthenticated relays, even ISPs that tell you to use authentication > often have another server next to it that doesn't need authentication > for customer IP space) > > If the hotel simply blocks port 25 then my email is broken, if they > allow it then my email is broken (as my ISP doesn't let the hotel > relay through their mail servers), however if the hotel redirects 25 > to their own open relays then in theory my email should work fine. > > They could always tell people "there is a relay at 10.0.0.25 so you > can change your settings to use that", however by redirecting all port > 25 traffic there they are effectively forcibly auto-configuring anyone > who was already configured to send via an unauthenticated server on > port 25. They are probably acting under the assumption that the only > people using 25 are using it for unauthenticated access, I believe > most servers that do use authentication tell users to use alternate > ports so this is probably a reasonable assumption. > > Compared to straight blocking of port 25 it's probably better as long > as the relay it is redirecting you to works properly so you don't have > to try and diagnose issues - However considering the quality of the > average hotel network I suspect most of them that are trying to do > this probably have it set to redirect to a dead server anyway. > > - Mike From bill at herrin.us Tue Oct 25 17:16:10 2011 From: bill at herrin.us (William Herrin) Date: Tue, 25 Oct 2011 18:16:10 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong wrote: > Put another way, your mechanism rewards those >doing the wrong thing while punishing those of us >sending our email via encrypted and authenticated >mechanisms. Owen, If you're doing the "right" thing, sending email via encrypted, authenticated mechanisms, then you're doing it TCP ports 587 or 443. Where Mike's mechanism obstructs you not at all. If you're still doing the wrong thing, trying to talk to remote SMTP servers on TCP port 25, why should his mechanisms not punish you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dotis at mail-abuse.org Tue Oct 25 18:37:37 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 25 Oct 2011 16:37:37 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <3576DC1F-8595-42EB-9FC1-74C43B1BAED7@delong.com> Message-ID: <4EA74841.8070408@mail-abuse.org> On 10/25/11 12:31 PM, Ricky Beam wrote: > On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong > wrote: > > Wouldn't the right place for that form of rejection to occur be at > > the mail server in question? > In a perfect world, yes. When you find a perfect world, send us an > invite. > > I reject lots of residential connections... > > The real issue here is *KNOWING* who is residential or not. Only > the ISP knows for sure; and they rarely tell others. The various > blocklists are merely guessing. Using a rDNS name is an even worse > guess. Agreed. Don't expect a comprehensive list based upon rDNS containing specific host names with IPv6. That would represent a never ending process to collect. > > However, senders who authenticate legitimately or legitimate > > sources of email (and yes, some spam sources too) connect just > > fine. > Authenticated sources can be traced and shutoff. If a random > cablemodem user has some bot spewing spam, the only way to cut off > the spam is to either (gee) block outbound port 25, or turn their > connection off entirely. As a responsible admin, I'll take the > least disruptive path. (I'll even preemptively do so.) Blocking ports is not free, but don't expect all DSL providers to unblock port 25 unless it is for a business account. Price differentials help pay for port blocking. In a perfect world, all SMTP transactions would cryptographically authenticate managing domains for the MTA. With less effort and resources (than that needed to check block lists) IPv6 could continue to work through LSNs aimed at helping those refusing to offer IPv6 connectivity. Blocking at the prefix requires block list resources 65k times greater than what is currently needed for IPv4. IPv6 announcements seem likely to expand another 6 fold fairly soon as well. In comparison, cryptographic authentication would be more practical, but a hybrid Kerberos scheme supported by various third-party service providers could reduce the overhead. Is it time for AuthenticatedMTP? -Doug From bill at herrin.us Tue Oct 25 18:55:26 2011 From: bill at herrin.us (William Herrin) Date: Tue, 25 Oct 2011 19:55:26 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: On Tue, Oct 25, 2011 at 2:43 PM, Christopher Pilkington wrote: > Is it common in the industry for a colocation provider, when > requested to put an egress ACL facing us such as: > > ?deny udp any a.b.c.d/24 eq 80 > > ?to refuse and tell us we must subscribe to their > managed DDOS product? Christopher, That seems reasonable to me. You're buying colo and transit, not firewall service. If you want firewall service, that's extra. If you do decide to move, I suggest a carrier neutral facility so that you can change transit providers without moving your equipment. The easier it is for you to walk away, the more accommodating vendors tend to be. Seeing much port 80 UDP traffic? My curiosity is piqued. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From paul at paulgraydon.co.uk Tue Oct 25 19:15:19 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 25 Oct 2011 14:15:19 -1000 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: <4EA75117.4070508@paulgraydon.co.uk> On 10/25/2011 08:43 AM, Christopher Pilkington wrote: > Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: > > deny udp any a.b.c.d/24 eq 80 > > ?to refuse and tell us we must subscribe to their managed DDOS product? > > -cjp > > For colo? No, filtering is the customers concern, unless failure to do so is causing a problem for the colo network. Such services are almost always paid for add-ons to a colo package. The colocation business is usually fairly low on the profit margin with most companies trying to get away with the bare minimum possible over and above the basics. From owen at delong.com Tue Oct 25 19:15:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 17:15:26 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: On Oct 25, 2011, at 3:16 PM, William Herrin wrote: > On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong wrote: >> Put another way, your mechanism rewards those >> doing the wrong thing while punishing those of us >> sending our email via encrypted and authenticated >> mechanisms. > > Owen, > > If you're doing the "right" thing, sending email via encrypted, > authenticated mechanisms, then you're doing it TCP ports 587 or 443. > Where Mike's mechanism obstructs you not at all. > Depends. Some hotel admins aren't so bright. That's the problem. Not everyone hears block outbound SMTP on port 25, they hear block outbound SMTP and stop listening. Boom, 25, 465, 587 all get turned off. Worse, if they redirect 25, then, it can still cause problems with many clients because they will try 25 first assuming that if it is broken it will fail. There''s nothing wrong with that approach IMHO. There's no reason one can't send email over 25 just as well as 587 as long as they're authenticating and doing it over an encrypted channel. My client generally tries in this order: 25, 587, 465, 443, 80. If people merely break things by blocking SMTP on one or more ports, then it works. If they do stupid pet tricks like redirecting all connections to other addresses to their own server, then it breaks horribly. > If you're still doing the wrong thing, trying to talk to remote SMTP > servers on TCP port 25, why should his mechanisms not punish you? > It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated remote users to send on your own port 25 for relay purposes. This is the problem... I don't buy your idea of what constitutes doing the wrong thing and neither do the developers of many email clients. Owen From jeroen at mompl.net Tue Oct 25 19:28:13 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 25 Oct 2011 17:28:13 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> Message-ID: <4EA7541D.3060607@mompl.net> Owen DeLong wrote: > It's both unacceptable in my opinion and common. There are even those > misguided souls that will tell you it is best practice, though general agreement, > even among them seems to be that only 25/tcp should be blocked and that > 465 and 587 should not be blocked. From my consumer POV. If you get a static IP with your provider, whether it is home internet or co-location, there should not be anything blocked. You're paying extra for the static IP in the case of home internet and the least you can expect is no blocking. Otherwise what's the point? You can always block/cancel later in case of abuse obviously. Of course this (and the below) does not apply in case of dynamically assigned IPs to a pool of home internet users. > Best practice is to do what works and block as much SPAM as possible without > destroying the internet in the process. There are those who argue that blocking > 25/tcp does not destroy the internet. By and large, they are the same ones who > believe NAT was good for us. There shouldn't be any spam filtering or blocking on a static IP at the ISP level. The ISP should limit itself to filtering at their own mail servers. Greetings, Jeroen -- Earthquake Magnitude: 3.6 Date: Tuesday, October 25, 2011 18:20:24 UTC Location: Arizona Latitude: 34.8137; Longitude: -112.5391 Depth: 5.00 km From morrowc.lists at gmail.com Tue Oct 25 19:53:19 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Oct 2011 20:53:19 -0400 Subject: Senate Bill S.968 In-Reply-To: <4EA6EAB5.2060305@packetpimp.org> References: <4EA6EAB5.2060305@packetpimp.org> Message-ID: On Tue, Oct 25, 2011 at 12:58 PM, Jason LeBlanc wrote: > Anyone read this? > > http://en.wikipedia.org/wiki/Protect_IP_Act > > More attempts to regulate Internet usage. > > Not in favor. folk ought to reach out to the largest opponent on this: Senator Wyden and see if he's got names of staffers in your local senators' offices to call/chat/etc... i also ended up giving a short preso on this topic at the last nanog, slides: (focused on what you may have to do/think-about if/when something like this becomes a law) and there was a decent write up on it in the LATimes some time ago: -chris From keegan.holley at sungard.com Tue Oct 25 20:21:15 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 25 Oct 2011 21:21:15 -0400 Subject: Colocation providers and ACL requests In-Reply-To: <4EA75117.4070508@paulgraydon.co.uk> References: <4EA75117.4070508@paulgraydon.co.uk> Message-ID: I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers. 2011/10/25 Paul Graydon > On 10/25/2011 08:43 AM, Christopher Pilkington wrote: > >> Is it common in the industry for a colocation provider, when requested to >> put an egress ACL facing us such as: >> >> deny udp any a.b.c.d/24 eq 80 >> >> ?to refuse and tell us we must subscribe to their managed DDOS product? >> >> -cjp >> >> >> For colo? No, filtering is the customers concern, unless failure to do > so is causing a problem for the colo network. Such services are almost > always paid for add-ons to a colo package. The colocation business is > usually fairly low on the profit margin with most companies trying to get > away with the bare minimum possible over and above the basics. > > > From jra at baylink.com Tue Oct 25 20:42:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 25 Oct 2011 21:42:46 -0400 (EDT) Subject: Colocation providers and ACL requests In-Reply-To: Message-ID: <14193854.152.1319593366540.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Keegan Holley" > I'm assuming colo means hosting, and the OP misspoke. Most colo providers > don't provide active network for colo (as in power and rack only) customers. Most? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From deric.kwok2000 at gmail.com Tue Oct 25 20:49:05 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 25 Oct 2011 21:49:05 -0400 Subject: the route is not in our bgprouter In-Reply-To: <4EA6BB26.2050203@sohonet.co.uk> References: <4EA6BB26.2050203@sohonet.co.uk> Message-ID: Hi Our upstream provider said that destination network is blocking our ip. Now my question is how we can know it If this network is blocking us, the traceroute should reach out our bgp router to go further nodes before that network, right 2nd question is how they block us to not allow the route to advertise from our upstream to our bgp router. ls it possible? Thank you so much On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby wrote: > If your provider has a looking glass then that is a good start to see if > they have the route in their routing tables. http://www.traceroute.org/ is a > good start for searching for a looking glass on their website. > > Have you checked to see if you're actually recieving the route? You may be > getting the route but not installing it into your routing table for some > reason (eg invalid next hop or a router from another provider is being > prefered). Do you have prefix lists inbound from your provider that could be > blocking a route? > > show ip route X.X.X.X > and > show ip bgp route X.X.X.X > > will give different information. > > If you've covered the above and not found the answer then try talking to > your provider. > > Regards > Patrick > > > On 25/10/2011 13:26, Deric Kwok wrote: >> >> Hi >> >> When we try to reach to outside ip, this route doesn't have in our bgp >> router >> >> How can we check whether it doesn't advertise from our upstream to us? >> >> Any web site and tools can help? >> >> Thank you >> > > > From morrowc.lists at gmail.com Tue Oct 25 20:58:42 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Oct 2011 21:58:42 -0400 Subject: the route is not in our bgprouter In-Reply-To: References: <4EA6BB26.2050203@sohonet.co.uk> Message-ID: deric, you really ought to hire a consultant for this sort of thing... just sayin! On Tue, Oct 25, 2011 at 9:49 PM, Deric Kwok wrote: > Hi > > Our upstream provider said that destination network is blocking our ip. > > Now my question is how we can know it you can't really, if they do things right. (Aside from just not getting there) > If this network is blocking us, the traceroute should reach out our > bgp router to go further nodes before that network, right presumably, unless the destination is a direct peer. > 2nd question is how they block us to not allow the route to advertise > from our upstream to our bgp router. probably they just don't accept your route... why do you think your route isn't propogated beyond your border(s)? > ls it possible? > > Thank you so much > > > > On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby > wrote: >> If your provider has a looking glass then that is a good start to see if >> they have the route in their routing tables. http://www.traceroute.org/ is a >> good start for searching for a looking glass on their website. >> >> Have you checked to see if you're actually recieving the route? You may be >> getting the route but not installing it into your routing table for some >> reason (eg invalid next hop or a router from another provider is being >> prefered). Do you have prefix lists inbound from your provider that could be >> blocking a route? >> >> show ip route X.X.X.X >> and >> show ip bgp route X.X.X.X >> >> will give different information. >> >> If you've covered the above and not found the answer then try talking to >> your provider. >> >> Regards >> Patrick >> >> >> On 25/10/2011 13:26, Deric Kwok wrote: >>> >>> Hi >>> >>> When we try to reach to outside ip, this route doesn't have in our bgp >>> router >>> >>> How can we check whether it doesn't advertise from our upstream to us? >>> >>> Any web site and tools can help? >>> >>> Thank you >>> >> >> >> > > From joly at punkcast.com Tue Oct 25 21:00:56 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 25 Oct 2011 22:00:56 -0400 Subject: Senate Bill S.968 In-Reply-To: References: <4EA6EAB5.2060305@packetpimp.org> Message-ID: effective FUD site http://demandprogress.org/ On Tue, Oct 25, 2011 at 8:53 PM, Christopher Morrow wrote: > On Tue, Oct 25, 2011 at 12:58 PM, Jason LeBlanc > wrote: > > Anyone read this? > > > > http://en.wikipedia.org/wiki/Protect_IP_Act > > > > More attempts to regulate Internet usage. > > > > Not in favor. > > folk ought to reach out to the largest opponent on this: > Senator Wyden > > and see if he's got names of staffers in your local senators' offices > to call/chat/etc... > > i also ended up giving a short preso on this topic at the last nanog, > slides: > > (focused on what you may have to do/think-about if/when something like > this becomes a law) > > and there was a decent write up on it in the LATimes some time ago: > > > -chris > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From blake at ispn.net Tue Oct 25 21:19:15 2011 From: blake at ispn.net (Blake Hudson) Date: Tue, 25 Oct 2011 21:19:15 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: <4EA76E23.5030202@ispn.net> I didn't see anyone address this from the service provider abuse department perspective. I think larger ISP's got sick and tired of dealing with abuse reports or having their IP space blocked because of their own (infected) residential users sending out spam. The solution for them was to block the spam. The cheapest/easiest way to do this was to block TCP 25 between subs and the internet, thus starting a trend. If 587 becomes popular, spammers will move on and the same ISPs that blocked 25 will follow suit. A better solution would have been to prevent infection or remove infected machines from the network(strong abuse policies, monitoring, give out free antivirus software, etc). Unfortunately, several major players (ATT, for example) went down the road of limiting internet access. Now that they've had a taste, some of them feel they can block other ports or applications like p2p (Comcast), Netflix (usage based billing on Bell, ATT, others). Unfortunately, I don't see the trend reversing. I'm afraid that Internet freedoms are likely to continue to decline and an "Unlimited" Internet experience won't exist at the residential level in 5+ years. --Blake From nanog at namor.ca Tue Oct 25 21:25:06 2011 From: nanog at namor.ca (J) Date: Tue, 25 Oct 2011 21:25:06 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <4EA76E23.5030202@ispn.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <4EA76E23.5030202@ispn.net> Message-ID: <4EA76F82.9040508@namor.ca> Blake Hudson wrote: > If > 587 becomes popular, spammers will move on and the same ISPs that > blocked 25 will follow suit. I don't see this happening as easily. Authenticated means an easier shutdown of an account, rather than some form of port block/etc. > A better solution would have been to prevent infection or remove > infected machines from the network(strong abuse policies, monitoring, > give out free antivirus software, etc). We have 2/3 of that. Antivirus helps some, but has some side-effects on the helpdesk, if they're also the first response tier. I find it strange mentioning 'monitoring' alongside 'freedoms', though. > Unfortunately, I don't see the trend reversing. I'm afraid that Internet > freedoms are likely to continue to decline and an "Unlimited" Internet > experience won't exist at the residential level in 5+ years. I'll agree with that. From blake at ispn.net Tue Oct 25 21:35:20 2011 From: blake at ispn.net (Blake Hudson) Date: Tue, 25 Oct 2011 21:35:20 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <4EA76F82.9040508@namor.ca> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <4EA76E23.5030202@ispn.net> <4EA76F82.9040508@namor.ca> Message-ID: <4EA771E8.5030303@ispn.net> J wrote the following on 10/25/2011 9:25 PM: > Blake Hudson wrote: >> If >> 587 becomes popular, spammers will move on and the same ISPs that >> blocked 25 will follow suit. > I don't see this happening as easily. Authenticated means an easier > shutdown of an account, rather than some form of port block/etc. An infected machine can just as easily send out mail on port 587 as it can using port 25. It's not hard for bot net hearders to come up with a list of valid credentials stolen from email clients, via key loggers, or simply guessed through probability. I see it every day. I will shutdown a compromised account on my end, but that doesn't stop ATT's infected subscriber from spamming 100 other servers using 100 other stolen credentials. I may also send an abuse report to ATT if they have an infected machine trying to perform a dictionary attack or brute force logins against my port 587 SMTP server. ATT's going to deal with the abuse reports as cheaply as possible. If they receive enough, I have no doubt they'll repeat past mistakes. From graham at apolix.co.za Tue Oct 25 23:12:57 2011 From: graham at apolix.co.za (Graham Beneke) Date: Wed, 26 Oct 2011 06:12:57 +0200 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: <4EA788C9.9080203@apolix.co.za> On 25/10/2011 23:03, Mike Jones wrote: > On 25 October 2011 20:52, Alex Harrowell wrote: >> Ricky Beam wrote: >> >>> Works perfectly even in networks where a VPN doesn't and the idiot >>> hotel >>> intercepts port 25 (not blocks, redirects to *their* server.) >>> >>> --Ricky >> >> Why do they do that? >> > > If the hotel simply blocks port 25 then my email is broken, if they > allow it then my email is broken (as my ISP doesn't let the hotel > relay through their mail servers), however if the hotel redirects 25 > to their own open relays then in theory my email should work fine. This only works if the MUA is configured to send to an un-AUTH'd relay normally. It normally fails spectacularly when the MUA tries to present AUTH that the relay doesn't understand or accept. I know of at least one large consumer ISP that does this across their network. Their argument was that it caused less of a support overhead when they implemented since no one had to change any settings (in theory). The reality is that the support overhead just transfers to the hosting/mail provider. "I send mail via your server and you are rejecting it." And then the hosting provider gets to explain how the IAP is in fact mangling their customers mail. Spam from mis-configured and compromised hosts is a big issue and on an access network. Even worse with dynamically allocated IPs. Users dial up and inherit blacklistings from previous customers and often entire prefixes will be listed by the RBL if the snoeshow effect is big enough. I dislike the idea of blocking port 25 (though it has been effective in dealing with major outbreaks.) We ended up building an new product that works as an appliance. All port 25 is piped through and the packets are passed on un-touched. Spamminess is scored and with some clever integration with RADIUS, the score is applied to a username. If the threshold is exceeded then the user is dynamically blocked or directed to a honeypot (depending on the requirements). And if the user redials then the block follows them. After deploying that our abuse desk went quiet ;-) -- Graham Beneke From graham at apolix.co.za Tue Oct 25 23:29:04 2011 From: graham at apolix.co.za (Graham Beneke) Date: Wed, 26 Oct 2011 06:29:04 +0200 Subject: Outgoing SMTP Servers In-Reply-To: <4EA771E8.5030303@ispn.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <4EA76E23.5030202@ispn.net> <4EA76F82.9040508@namor.ca> <4EA771E8.5030303@ispn.net> Message-ID: <4EA78C90.9070403@apolix.co.za> On 26/10/2011 04:35, Blake Hudson wrote: > An infected machine can just as easily send out mail on port 587 as it > can using port 25. It's not hard for bot net hearders to come up with a > list of valid credentials stolen from email clients, via key loggers, or > simply guessed through probability. I see it every day. The difference is that it is the relay that accepts the spam on 587 that ends up on the blacklists. A mail server with a sysadmin that might care and probably sees business impact in not fixing the problem. As apposed to an end user that doesn't give a hoot. Compromised mail authentication details are quick and easy to take down. A server mis-configured as an open relay on 587 is a one time fix. End users infected with nasties are a support desk blackhole. Hours of time explaining to moms and pops how to download anti-virus and install it and configure it and run it... -- Graham Beneke From bill at herrin.us Tue Oct 25 23:33:37 2011 From: bill at herrin.us (William Herrin) Date: Wed, 26 Oct 2011 00:33:37 -0400 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong wrote: > On Oct 25, 2011, at 3:16 PM, William Herrin wrote: >> If you're doing the "right" thing, sending email via encrypted, >> authenticated mechanisms, then you're doing it TCP ports 587 or 443. >> Where Mike's mechanism obstructs you not at all. >> > Depends. Some hotel admins aren't so bright. That's the problem. Not > everyone hears block outbound SMTP on port 25, they hear block outbound > SMTP and stop listening. Boom, 25, 465, 587 all get turned off. Sure. But that's not Mike's mechanism. It's ignorant hotel guy's mechanism. Don't penalize Mike because some other fool does something similar but wrong. >> If you're still doing the wrong thing, trying to talk to remote SMTP >> servers on TCP port 25, why should his mechanisms not punish you? > > It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated > remote users to send on your own port 25 for relay purposes. Sure it is. Same way it's wrong to have an open relay or an unsecured proxy. It isn't 1995 any more. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Oct 25 23:44:11 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Oct 2011 21:44:11 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: On Oct 25, 2011, at 9:33 PM, William Herrin wrote: > On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong wrote: >> On Oct 25, 2011, at 3:16 PM, William Herrin wrote: >>> If you're doing the "right" thing, sending email via encrypted, >>> authenticated mechanisms, then you're doing it TCP ports 587 or 443. >>> Where Mike's mechanism obstructs you not at all. >>> >> Depends. Some hotel admins aren't so bright. That's the problem. Not >> everyone hears block outbound SMTP on port 25, they hear block outbound >> SMTP and stop listening. Boom, 25, 465, 587 all get turned off. > > Sure. But that's not Mike's mechanism. It's ignorant hotel guy's > mechanism. Don't penalize Mike because some other fool does something > similar but wrong. > Mike recommends a tactic that leads to idiot hotel admins doing bad things. You bet I'll criticize it for that. His mechanism breaks things anyway. I'll criticize it for that too. > >>> If you're still doing the wrong thing, trying to talk to remote SMTP >>> servers on TCP port 25, why should his mechanisms not punish you? >> >> It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated >> remote users to send on your own port 25 for relay purposes. > > Sure it is. Same way it's wrong to have an open relay or an unsecured > proxy. It isn't 1995 any more. > As I said, we can agree to disagree about what is wrong. I know your position. I still don't agree with it. Owen From rdrake at direcpath.com Wed Oct 26 00:29:58 2011 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Oct 2011 01:29:58 -0400 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> <18081.1319538555@turing-police.cc.vt.edu> Message-ID: <4EA79AD6.9000106@direcpath.com> On 10/25/2011 11:17 AM, Owen DeLong wrote: > But that applies to port 25 also, so, I'm not understanding the difference. > >> Other people running open port 587s tends to be quite self-correcting. >> > At this point, so do open port 25s. The differences is in intentions from the user. All SMTP servers are supposed to accept incoming email to their domain on port 25, if they get a connection from a random IP they can check spf, dkim and dns blacklists but that's all they can do to see the reputation of the sender. Blocking port 25 is an ISP based list of who is allowed to send SMTP. Port 587 is supposed to only be used for MUA-MTA communications. If mx.hello.com gets a 587 connection from anyone and they say "mail from: " the server can drop that as wrong. Yes it's nasty and dumb, but it works better than spf, DKIM and other technology right now. Maybe spf could be extended into reverse zones and who they're permitted to send mail for (too many ISP's don't let even business users update reverse records), maybe spf or a protocol like it will become required in the future so you know who can be trusted when they connect, or reputation or greylisting will take off, except for having to store reputation about all IP's and all /64s so the database isn't easily maintained. I think spf with dkim (with caveats worked out) would be the best solution but anything that requires a flag day with SMTP basically isn't gonna happen. > > Owen Robert From rdrake at direcpath.com Wed Oct 26 00:53:26 2011 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Oct 2011 01:53:26 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EA76E23.5030202@ispn.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <4EA76E23.5030202@ispn.net> Message-ID: <4EA7A056.4080109@direcpath.com> On 10/25/2011 10:19 PM, Blake Hudson wrote: > I didn't see anyone address this from the service provider abuse > department perspective. I think larger ISP's got sick and tired of > dealing with abuse reports or having their IP space blocked because of > their own (infected) residential users sending out spam. The solution > for them was to block the spam. The cheapest/easiest way to do this was > to block TCP 25 between subs and the internet, thus starting a trend. If > 587 becomes popular, spammers will move on and the same ISPs that > blocked 25 will follow suit. Actually, it doesn't work that way because of what submission is designed to do. I just posted another email about it so I won't repeat it, but basically you should think of blocking port 25 as a list of who's authorized to send emails, not as a port we just killed for fun and we're waiting for the spammers next move. > > A better solution would have been to prevent infection or remove > infected machines from the network(strong abuse policies, monitoring, > give out free antivirus software, etc). Unfortunately, several major > players (ATT, for example) went down the road of limiting internet > access. Now that they've had a taste, some of them feel they can block > other ports or applications like p2p (Comcast), Netflix (usage based > billing on Bell, ATT, others). As an ISP, I liked seeing abuse complaints drop to near zero when we did this. We spent about a month fixing some people who don't use webmail (most regular customers don't use an MUA anymore) and had our share of third-party MTA's that refused to turn on submission (no idea why, these were usually business-class comp accounts so we moved them to a business pool and dropped their acls) but overall we probably had less than 100 calls from doing this and it made our lives easier. Now I know you said you wanted us to be preventative and to treat the problem, but that's just impractical. We got 5000 abuse emails a month for (at the time) ~20k customers. Were 1/4 of them spamming? No, but the ones that were spamming generated automated reports from everyone. None of them were ever legitimate spammers. They were all users who clicked on a funny puppy picture their mom sent, or some other thing that set their computer on fire and had it spitting out gobs of porno links to everyone it could find. So it wasn't a set of problem users, it was just a random sampling of everyone's not-so-PC-savvy relatives. So, lets say we wrote software to collate those reports and got it down to 30 legitimate people (if we're lucky). Do we block their IP's and wait for them to call in then send them to geek squad? Do we try to fix their infected PC over the phone? At this point, no matter what we do they're going to get sent to a tier 2 tech which means at least 2 phone calls and whatever revenue we might have gotten from them is gone for quite a while. We can have one guy tied up all day every day trying to process abuse issues or we can just shut down port 25 and the problem magically disappears. Is their laptop uninfected? No, but they can no longer infect any other customer in our network or anyone elses network, thus reducing global infections. We've made the world a better place and saved ourselves some money. Unfortunately, the first coffee shop they go to that doesn't block port 25 is going to be a new spam source but we can't save them all. It may be possible in the future we'll have a more convenient method to police PC's but the network access controls that exist right now aren't flexible enough to allow different networks to set different policies, so if it's a work laptop and they have a domain administrator then 802.1x might not be possible, and mandating they have firewall or anti-virus turned on (or a specific version/that it's updated, etc) might not be possible. Most customers rail against controls anyway. You don't want port 25 blocked so how would you feel if we mandated you install our ad-ware mcafee client and scanned your computer every 15 minutes? And when you think about it, if the big boys gave up and blocked port 25 and stopped offering free anti-virus and a backrub when you call in, how can we afford to compete with that? > > Unfortunately, I don't see the trend reversing. I'm afraid that Internet > freedoms are likely to continue to decline and an "Unlimited" Internet > experience won't exist at the residential level in 5+ years. I hope that you're exaggerating for effect, but you might be right. Small providers have trouble competing right now because of all the advantages the carriers have in the market. Some of the ways small providers can distinguish themselves is through support, or offering things a big player won't. So in some cases it's better to find a regional ISP and go with them because they may work with you, and they may be a little more lenient with some things. I don't think port 25 is worth making a stand on though, there are better battles to fight (rate limiting) that actually mean something to the customer experience. > > --Blake > Robert From mike at mikejones.in Wed Oct 26 01:56:25 2011 From: mike at mikejones.in (Mike Jones) Date: Wed, 26 Oct 2011 07:56:25 +0100 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: On 26 October 2011 05:44, Owen DeLong wrote: > Mike recommends a tactic that leads to idiot hotel admins doing bad things. > You bet I'll criticize it for that. > > His mechanism breaks things anyway. I'll criticize it for that too. > Just to clarify, I was merely pointing out a possible argument behind someone doing it that way. For a hotel wifi type network I would consider it a valid option that is arguably (to some) better than straight blocking for the average user, for other types of networks with more long term user bases I would be very surprised if there was any justification for redirecting as opposed to simply blocking. If someone were asking for my advice on deploying a network like that I would have to point out that the extra effort required to deploy/support it is unlikely to be worth it. Blocking port 25 is unlikely to cause much of a problem compared to a single incident with that SMTP server that your hotel now needs to maintain. In a perfect world we would all have as many static globally routed IP addresses as we want with nothing filtered, in the real world a residential ISP who gives their customers globally routable IPv4 addresses for each computer (ie. a CPE that supports multiple computers without NAT) with no filtering at all is probably going to have to hire more support staff to deal with it, even before people from this list start null routing their IP space for being a rogue ISP that clearly doesn't give a damn etc :) Perhaps our next try with IPv6 can be a perfect world where hosts are secure enough for open end to end connectivity and infected machines are rarely a problem? IPv6 enabled systems are more secure than a lot of the systems we have floating around on IPv4 networks, but I still think we're going to end up with port blocking becoming reasonably common on IPv6 as well once that starts getting widely deployed to residential users. - Mike From patrick.sumby at sohonet.co.uk Wed Oct 26 05:26:01 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Wed, 26 Oct 2011 11:26:01 +0100 Subject: the route is not in our bgprouter In-Reply-To: References: <4EA6BB26.2050203@sohonet.co.uk> Message-ID: <4EA7E039.1060203@sohonet.co.uk> > On Tue, Oct 25, 2011 at 9:49 PM, Deric Kwok wrote: >> Our upstream provider said that destination network is blocking our ip. >> >> Now my question is how we can know it > > you can't really, if they do things right. (Aside from just not getting there) Have you tried contacting the destination network. I assume you have a customer that wants to talk to their customer? Its in both your interests to see why things aren't working. > >> If this network is blocking us, the traceroute should reach out our >> bgp router to go further nodes before that network, right > > presumably, unless the destination is a direct peer. > >> 2nd question is how they block us to not allow the route to advertise >> from our upstream to our bgp router. > > probably they just don't accept your route... why do you think your > route isn't propogated beyond your border(s)? > What is your prefix that you're announcing? Is it from a new range an potentially bogon filtered somehwere? What is the destination you're trying to get to? What do you see in BGP looking glasses for that IP. They could be doing something stupid/evil like putting your AS in their path. >> ls it possible? >> >> Thank you so much >> >> >> >> On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby >> wrote: >>> If your provider has a looking glass then that is a good start to see if >>> they have the route in their routing tables. http://www.traceroute.org/ is a >>> good start for searching for a looking glass on their website. >>> >>> Have you checked to see if you're actually recieving the route? You may be >>> getting the route but not installing it into your routing table for some >>> reason (eg invalid next hop or a router from another provider is being >>> prefered). Do you have prefix lists inbound from your provider that could be >>> blocking a route? >>> >>> show ip route X.X.X.X >>> and >>> show ip bgp route X.X.X.X >>> >>> will give different information. >>> >>> If you've covered the above and not found the answer then try talking to >>> your provider. >>> >>> Regards >>> Patrick >>> >>> >>> On 25/10/2011 13:26, Deric Kwok wrote: >>>> >>>> Hi >>>> >>>> When we try to reach to outside ip, this route doesn't have in our bgp >>>> router >>>> >>>> How can we check whether it doesn't advertise from our upstream to us? >>>> >>>> Any web site and tools can help? >>>> >>>> Thank you >>>> >>> >>> >>> >> >> From carlosm3011 at gmail.com Wed Oct 26 07:55:04 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 26 Oct 2011 10:55:04 -0200 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685C5@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> <87aa8p6y2b.fsf@nemi.mork.no> <13175F96BDC3B34AB1425BAE905B3CE50BA685C5@ltiserver.lti.local> Message-ID: My point exactly, I am perfectly happy authenticating and relaying through either my MX at the office or with Google's SMTP server. But I just can't do that if SMTPoSSL ports are blocked by some lazy net admin. And I definitely hate it when I have to "pay" (in terms of delay and overhead) the price of a VPN in order to just send a couple of emails. cheers Carlos On Tue, Oct 25, 2011 at 1:57 PM, Dennis Burgess wrote: > >> >> I'm curious how a traveller is supposed to get SMTP relay service when, well, >> travelling. I am not really sure if I want a VPN for sending a simple email. >> >> And I can understand (although I am not convinced that doing so is such a >> great idea) blocking 25/tcp outgoing, as most botnets will try that method of >> delivery. However, I do believe that outgoing 465 SHOULD always be >> allowed. >> >> regards >> >> Carlos >> > > [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. ?Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. ?Why does the local internet provide NEED to relay though their server, regardless of the port. > >> On Tue, Oct 25, 2011 at 10:43 AM, Bj?rn Mork wrote: >> > Owen DeLong writes: >> > >> >> It's both unacceptable in my opinion and common. There are even those >> >> misguided souls that will tell you it is best practice, though >> >> general agreement, even among them seems to be that only 25/tcp >> >> should be blocked and that >> >> 465 and 587 should not be blocked. >> > >> > It is definitely considered best practice in some areas. ?See e.g. >> > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c >> > ontent/uploads/2010/10/bransjenorm-SPAM.pdf >> > (couldn't find an english original, but the google translation looks >> > OK) >> > >> > The document is signed by all major ISPs in Norway as well as the >> > Norwegian research and education network operator, so it must be >> > considered a local "best practice" whether you like it or not. >> > >> > Note that only port 25/tcp is blocked and that some of the ISPs offer >> > a per-subscriber optout. >> > >> > Eh, this was the Northern Aurope NOG, wasn't it? >> > >> > >> > >> > >> > Bj?rn >> > >> > >> >> >> >> -- >> -- >> ========================= >> Carlos M. Martinez-Cagnazzo >> http://www.labs.lacnic.net >> ========================= > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From owen at delong.com Wed Oct 26 08:24:23 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Oct 2011 07:24:23 -0600 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <9B6CE594-E968-408E-8BD1-74A96580F526@delong.com> Message-ID: > > > > In a perfect world we would all have as many static globally routed IP > addresses as we want with nothing filtered, in the real world a > residential ISP who gives their customers globally routable IPv4 > addresses for each computer (ie. a CPE that supports multiple > computers without NAT) with no filtering at all is probably going to > have to hire more support staff to deal with it, even before people > from this list start null routing their IP space for being a rogue ISP > that clearly doesn't give a damn etc :) Agreed that we should get to the point where everyone can have thousands of static globally routed subsets as soon as possible. The technology already exists and I use it wherever it is available. I have 65,536 static globally routed subsets available in my network, though I do not currently use that many. The reason we don't all have that yet is merely delay and inaction by those who have not yet implemented current IP technologies. > > Perhaps our next try with IPv6 can be a perfect world where hosts are > secure enough for open end to end connectivity and infected machines > are rarely a problem? IPv6 enabled systems are more secure than a lot > of the systems we have floating around on IPv4 networks, but I still > think we're going to end up with port blocking becoming reasonably > common on IPv6 as well once that starts getting widely deployed to > residential users. > Firewalls are perfectly valid and I have no general objection to filtering packets based on the policy set by a site. What I object to is having someone I pay to move my packets tell me that they won't move some of those packets because they feel it is some form of best practice to eliminate my perfectly valid packets in order to prevent someone else from committing some form of abuse on the same protocol. I object even more strenuously to someone who redirects my packets for their intended destination to some man in the middle attack destination of their choosing. Redirecting someones SMTP is a man I. The middle attack. It is every bit as evil as any other form of network abuse or hijacking. Owen From leigh.porter at ukbroadband.com Wed Oct 26 08:54:58 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 26 Oct 2011 13:54:58 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <020101cc92f0$b7abaeb0$27030c10$@com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local>, <020101cc92f0$b7abaeb0$27030c10$@com> Message-ID: <7DB36F1A-6972-42EA-80DE-315C1C3DEB9B@ukbroadband.com> On 25 Oct 2011, at 09:34, "Tim" wrote: > This sadly is very common. It is getting more common by the day it seems but > this practice has started almost a decade ago. > > An easy work around is to use a custom port as they seem to just block port > 25 as a bad port but leave just about everything else open including 2525 > which seems to be a common secondary smtp port for hosting companies. I use port 80 which has not failed me so far ;-) -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From cjp at 0x1.net Wed Oct 26 09:07:45 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Wed, 26 Oct 2011 10:07:45 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: <4EA75117.4070508@paulgraydon.co.uk> Message-ID: On Tue, Oct 25, 2011 at 9:21 PM, Keegan Holley wrote: > I'm assuming colo means hosting, and the OP misspoke. ?Most colo providers > don't provide active network for colo (as in power and rack only) customers. Yes, hosting. I did indeed misspeak. From caldcv at gmail.com Wed Oct 26 09:12:33 2011 From: caldcv at gmail.com (Chris) Date: Wed, 26 Oct 2011 10:12:33 -0400 Subject: XSServer / Taking down a spam friendly provider Message-ID: Hello I run a few Wordpress sites here and there, but I'm amazed at the amount of spam that comes from xsserver.eu's clients. Their abuse department is non-responsive: they do not even have auto responders to emails and the offending IP addresses keep spamming weeks after my email. I have CC'd my abuse complaints to Hurricane Electric, with no luck either, so I'm stuck Before somebody screams the path of least resistance of "just install Akismet or (insert spam plugin here)", that type of thinking just makes spam even worse because we just keep large, possibly stale, databases of IP addresses that may or may not be active spammers and does not address the issue. Does anyone have any recommendations of where to go next because I'm just limited to doing a whois on the IP address, emailing the abuse contact and tracerouting. Examples of the offending IPs are: 109.230.216.225 109.230.220.34 109.230.217.166 109.230.220.95 A prime offender is hellomotow.net, who provides "SEO" services with automated spamming tools. hellomotow.net has spammed me in the past from IP addresses like this so I believe XSServer is becoming the new McColo / AlphaRed / ThePlanet (back in the day, their abuse dept is very responsive now) I'm not asking for you to do the footwork for me, unless you want, but just needed some advice from folks more knowledgeable than myself. -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From rps at maine.edu Wed Oct 26 09:29:45 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 26 Oct 2011 10:29:45 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> Message-ID: We provide service to about 1,000 public schools and libraries in the state of Maine. For those users, we block SMTP (port 25 only) traffic unless it goes through our smarthost for incoming mail, and our mail-relay for outgoing mail. Otherwise we would be constantly ending up on blacklists, as many of our users who attempt to run their own servers configure them to be open relays, or don't secure host systems and have them turn into botnets. To make it a little more desirable we do provide a web UI to manage mail domains, including letting them configure whether or not they want to filter spam and some controls to how sensitive that is (kind of like postini). Recently, we've been rolling out Linux-based CPE instead of routers; those provide them with a local firewall. We've designed the firewall to filter outgoing SMTP by default, but they can configure a list of IP addresses to bypass that. In this situation, they can run their mail server directly on their network without making use of smarthost or mail-relay, can manage exceptions, but still have a base-level of protection against spam bots by default. We have found that many of our users have come to prefer using our relay servers as when something isn't working we can provide them with logging information to help them track down the problem and they tend to spend less time responding to spam incidents. Whether or not this model could work commercially, I'm not sure... I think we end up doing a lot more hand-holding than the typical ISP given our audience. As for our mail servers, both smarhost and mail-relay hosts we have them point to actually point to several mail servers, and we do perform base level greylisting and subscribe to a few blacklists before mail is relayed or checked for spam and viruses. On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess wrote: > I am curious about what network operators are doing with outbound SMTP > traffic. ?In the past few weeks we have ran into over 10 providers, > mostly local providers, which block outbound SMTP and require the users > to go THOUGH their mail servers even though those servers are not > responsible for the domains in question! ?I know other mail servers are > blocking non-reversible mail, however, is this common? ?And more > importantly, is this an acceptable practice? > > > > Most of our smaller ISPs that we support; we allow any outbound SMTP > connection, however we do watch residential users for 5+ outbound SMTP > connections at the same time. ?But if the ISP has their own mail > servers, and users wish to relay though them, we basically tell them to > use their mail server that they contract with. ?What is the best > practice? > > > > > > ----------------------------------------------------------- > Dennis Burgess, Mikrotik Certified Trainer > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 ?Website: > http://www.linktechs.net > LIVE On-Line Mikrotik Training > - Author of "Learn RouterOS" > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From keegan.holley at sungard.com Wed Oct 26 09:29:06 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 26 Oct 2011 10:29:06 -0400 Subject: Colocation providers and ACL requests In-Reply-To: <14193854.152.1319593366540.JavaMail.root@benjamin.baylink.com> References: <14193854.152.1319593366540.JavaMail.root@benjamin.baylink.com> Message-ID: 2011/10/25 Jay Ashworth > ----- Original Message ----- > > From: "Keegan Holley" > > > I'm assuming colo means hosting, and the OP misspoke. Most colo providers > > don't provide active network for colo (as in power and rack only) > customers. > > Most? > > I'm sure there are exceptions to that rule. It's better than "YMMV". From jra at baylink.com Wed Oct 26 09:37:23 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 26 Oct 2011 10:37:23 -0400 (EDT) Subject: Colocation providers and ACL requests In-Reply-To: Message-ID: <26408157.222.1319639843740.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Keegan Holley" > > ----- Original Message ----- > > > From: "Keegan Holley" > > > > > I'm assuming colo means hosting, and the OP misspoke. Most colo > > > providers > > > don't provide active network for colo (as in power and rack only) > > customers. > > > > Most? > > I'm sure there are exceptions to that rule. It's better than "YMMV". Perhaps I look at a different category of colo provider, then, but I'm accustomed to seeing it be well up into double-digit percentage of the ones I've ever looked at. "Hosting", to me, means "provider's hardware", not just "local blended bandwidth". Cheers, -- jr 'so many things are just me' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From steve at pirk.com Wed Oct 26 11:24:04 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Wed, 26 Oct 2011 09:24:04 -0700 Subject: Facebook insecure by design In-Reply-To: <201110241454.p9OEseXg037575@mail.r-bonomi.com> References: <201110241454.p9OEseXg037575@mail.r-bonomi.com> Message-ID: On Oct 24, 2011 7:55 AM, "Robert Bonomi" wrote: > > > > You can even download it all and erase yourself if > > you want out. > > Don't count on it. You may 'disappear' from public view, but that does > not necessarily mean the data is truely 'gone'. Specific example -- if you > request a USENET posting to be removed, all they do is make it 'invisible' > to the world. It is _not_ removed from the databases, or from inernal > access/use. > > That is a very good point, and one of the things that is being tested now that Buzz is going into archive mode. Users are given the option of backing up their posts on Buzz, and then deleting their Buzz content. Many like myself will just leave it there. It is a year+ of history, and what I posted publicly can stay public. It is supposed to remove all your Buzz content from the service and I believe it includes the content shared only with certain individuals. It does not completely erase it, because I believe email copies of the posts and comments that people had sent to their Gmail accounts will remain with those users. Deleting a product like your Picasa web albums is permanent as far as I know, but I will definitely ask some people on the Picasa team. Deleting your search history and other Dashboard items is supposed to be permanent, but as you pointed out, we are taking Google's word for it. --steve From bonomi at mail.r-bonomi.com Wed Oct 26 12:07:10 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 26 Oct 2011 12:07:10 -0500 (CDT) Subject: Facebook insecure by design Message-ID: <201110261707.p9QH7AWW056979@mail.r-bonomi.com> > From: "steve pirk [egrep]" > Date: Wed, 26 Oct 2011 09:24:04 -0700 > Subject: Re: Facebook insecure by design > > On Oct 24, 2011 7:55 AM, "Robert Bonomi" wrote: > > > > > > > You can even download it all and erase yourself if > > > you want out. > > > > Don't count on it. You may 'disappear' from public view, but that does > > not necessarily mean the data is truely 'gone'. Specific example -- if > you > > request a USENET posting to be removed, all they do is make it 'invisible' > > to the world. It is _not_ removed from the databases, or from inernal > > access/use. > > > > > > That is a very good point, and one of the things that is being tested now > that Buzz is going into archive mode. Users are given the option of backing > up their posts on Buzz, and then deleting their Buzz content. Many like > myself will just leave it there. It is a year+ of history, and what I posted > publicly can stay public. > > It is supposed to remove all your Buzz content from the service and I > believe it includes the content shared only with certain individuals. It > does not completely erase it, because I believe email copies of the posts > and comments that people had sent to their Gmail accounts will remain with > those users. > > Deleting a product like your Picasa web albums is permanent as far as I > know, but I will definitely ask some people on the Picasa team. Deleting > your search history and other Dashboard items is supposed to be permanent, > but as you pointed out, we are taking Google's word for it. > I _don't_ know, but I *strongly* suspect that things like search history _are_ kept -- although 'detached' from any identification of the original person. That kind of information is simply 'too valuable' -- for pattern recognition, say -- to entirely discard. I also suspect it remains as part of lots of aggregate demographics, etc. I wouldn't be surrised if they kept statistal data on 'who deletes what'. From nicolai-nanog at chocolatine.org Wed Oct 26 12:35:18 2011 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Wed, 26 Oct 2011 12:35:18 -0500 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: Message-ID: <20111026173518.GA13500@vectra.student.iastate.edu> On Wed, Oct 26, 2011 at 10:12:33AM -0400, Chris wrote: > Before somebody screams the path of least resistance of "just install > Akismet or (insert spam plugin here)", that type of thinking just > makes spam even worse because we just keep large, possibly stale, > databases of IP addresses that may or may not be active spammers and > does not address the issue. > > Does anyone have any recommendations > Examples of the offending IPs are: > 109.230.216.225 > 109.230.220.34 > 109.230.217.166 > 109.230.220.95 All four addresses are in the Spamhaus sbl-xbl list. It would take ~10 lines of python in your cgi program to work this out. Nicolai From caldcv at gmail.com Wed Oct 26 12:47:03 2011 From: caldcv at gmail.com (Chris) Date: Wed, 26 Oct 2011 13:47:03 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: Message-ID: For folks who do not understand, I'm trying to "McColo" XSServer so their lack of response in regards to abuse is gone rather than the suggestions of scripting (guess you didn't read the full text of the email) or you pushing a product on me because you work for the ISP that the product is hosted on. Everybody remembers McColo going down and being dropped from uplinks in 2008 then all the spam disappeared, right? On Wed, Oct 26, 2011 at 10:12 AM, Chris wrote: > Hello > > I run a few Wordpress sites here and there, but I'm amazed at the > amount of spam that comes from xsserver.eu's clients. Their abuse > department is non-responsive: they do not even have auto responders to > emails and the offending IP addresses keep spamming weeks after my > email. > > I have CC'd my abuse complaints to Hurricane Electric, with no luck > either, so I'm stuck > > Before somebody screams the path of least resistance of "just install > Akismet or (insert spam plugin here)", that type of thinking just > makes spam even worse because we just keep large, possibly stale, > databases of IP addresses that may or may not be active spammers and > does not address the issue. > > Does anyone have any recommendations of where to go next because I'm > just limited to doing a whois on the IP address, emailing the abuse > contact and tracerouting. > > Examples of the offending IPs are: > 109.230.216.225 > 109.230.220.34 > 109.230.217.166 > 109.230.220.95 > > A prime offender is hellomotow.net, who provides "SEO" services with > automated spamming tools. hellomotow.net has spammed me in the past > from IP addresses like this so I believe XSServer is becoming the new > McColo / AlphaRed / ThePlanet (back in the day, their abuse dept is > very responsive now) > > I'm not asking for you to do the footwork for me, unless you want, but > just needed some advice from folks more knowledgeable than myself. > > -- > --C > > "The dumber people think you are, the more surprised they're going to > be when you kill them." - Sir William Clayton > From henry at AegisInfoSys.com Wed Oct 26 12:57:02 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Wed, 26 Oct 2011 13:57:02 -0400 Subject: Outgoing SMTP Servers In-Reply-To: Message-ID: <20111026175702.GA21521@nntp.AegisInfoSys.com> On Wed, Oct 26, 2011 at 19:24:23PM -0600, Owen DeLong wrote: > Firewalls are perfectly valid and I have no general objection to > filtering packets based on the policy set by a site. What I object to is > having someone I pay to move my packets tell me that they won't move > some of those packets because they feel it is some form of best practice > to eliminate my perfectly valid packets in order to prevent someone else > from committing some form of abuse on the same protocol. > > I object even more strenuously to someone who redirects my packets for > their intended destination to some man in the middle attack destination > of their choosing. Would it be useful to slice this analysis into component parts, e.g. "Residential" (dynamic), "small" (single/handful, e.g. small business, colo, hosted web, VPS), and large (/24 and up), as what is defined as "moving packets" may be viewed significantly differently? For instance, what Residential customers are paying for seems to not necessarily be (strictly speaking) "just moving all of your packets", at least according to residential ToS' that I've read lately. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From Gavin.Pearce at 3seven9.com Wed Oct 26 15:10:41 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Wed, 26 Oct 2011 21:10:41 +0100 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: Message-ID: On Wed, Oct 26, 2011 at 10:12:33AM -0400, Chris wrote: > Does anyone have any recommendations of where to go next because I'm > just limited to doing a whois on the IP address, emailing the abuse > contact and tracerouting. Chris, Can't help much - but can say we find ourselves in a similar boat. As a rule of thumb, we systematically block, log, and report *every* spam, virus & brute force etc attempt we receive against any of our devices. In the past three years, only one company has ever responded to an abuse request (CampaignMonitor to name & honour them), though there are definitely some other good guys out there (a large number of them on this list)! [We don't apply the above logic for spam sent to email destinations, for obvious reasons] G From jfbeam at gmail.com Wed Oct 26 16:06:57 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 26 Oct 2011 17:06:57 -0400 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell wrote:> > Why do they do that? You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.) Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*." MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which is the job of an MTA not MUA.) The only people who can effectively police this is the ISP. Individual mail server admins and RBL maintainers can only guess and be reactionary, which is often wrong, still lets spam through, and becomes stale rather quickly. --Ricky From jvanoppen at spectrumnet.us Wed Oct 26 16:12:07 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Wed, 26 Oct 2011 21:12:07 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> Message-ID: On our retail footprint we block outbound traffic from customers with dynamic IPs towards port 25, our support tells them to use their ISP's port 587 server.... That being said, since all of our home users have 50 mbit/sec or greater upload speeds we are pretty paranoid about the amount of spam that could be originated. We don't block anything on static assignments. Honestly, even as a very geeky user, I probably would not have noticed the block and I can confirm that it is massively important to lowering our spam footprint as a network. I asked our support people, and none of them had ever really had an issue with this policy in terms of keeping customers. I agree with Ricky's current comment on this thread, blocking is unfortunately necessary on the modern consumer portions of the internet. Thanks, John van Oppen -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, October 24, 2011 9:37 PM To: Dennis Burgess Cc: nanog at nanog.org Subject: Re: Outgoing SMTP Servers On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote: > I am curious about what network operators are doing with outbound SMTP > traffic. In the past few weeks we have ran into over 10 providers, > mostly local providers, which block outbound SMTP and require the users > to go THOUGH their mail servers even though those servers are not > responsible for the domains in question! I know other mail servers are > blocking non-reversible mail, however, is this common? And more > importantly, is this an acceptable practice? > It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked. > > > Most of our smaller ISPs that we support; we allow any outbound SMTP > connection, however we do watch residential users for 5+ outbound SMTP > connections at the same time. But if the ISP has their own mail > servers, and users wish to relay though them, we basically tell them to > use their mail server that they contract with. What is the best > practice? > Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us. Owen From dave at temk.in Wed Oct 26 17:05:55 2011 From: dave at temk.in (Dave Temkin) Date: Wed, 26 Oct 2011 18:05:55 -0400 Subject: [NANOG-announce] NANOG54 (San Diego, Feb 5-8 2012): Call for Presentations and Registration Now Open! Message-ID: <4EA88443.30307@temk.in> All, After a fantastic meeting in Philadelphia we're getting ready to provide you with another content rich meeting at the Westin Gaslamp Quarter in San Diego. Registration is now open for the meeting, and you can take advantage of the Early Bird Registration Discount and save $75 by registering before December 5th, 2011. Please see http://www.nanog.org/meetings/nanog54/nanog54_registration.html for more details. --- The NANOG54 CFP is available at: http://www.nanog.org/meetings/nanog54/callforpresentations.html Please keep these key dates in mind: Presentation Abstracts and Draft Slides Due: December 5th, 2011 Final Slides Due: December 19th, 2011 The NANOG Program Committee intends on having a draft program published by December 20th, 2011 and the final agenda published by January 16, 2012. --- Thanks, -Dave Temkin (for the NANOG Program Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From marka at isc.org Wed Oct 26 17:11:41 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 27 Oct 2011 09:11:41 +1100 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Wed, 26 Oct 2011 17:06:57 EDT." References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> Message-ID: <20111026221141.CD45515FDD78@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell > wrote:> > > Why do they do that? > > You'd have to ask them. Or more accurately, you'd need to ask their > system integrator -- I've never seen an "in house" network run like that. > (and for the record, they were charging for that shitty network access.) > > Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a > modern consumer internet. (Translation: It f'ing works.) This is the ISP > saying, "You aren't a mail *server*." MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality. Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email. > MUA's (mail clients) should only be > connecting to specified MSA's or MTA's (mail *servers*). They should > never be connecting to random MTA's (presumably for direct delivery, which > is the job of an MTA not MUA.) The only people who can effectively police > this is the ISP. Total utter BS. > Individual mail server admins and RBL maintainers can > only guess and be reactionary, which is often wrong, still lets spam > through, and becomes stale rather quickly. > > --Ricky > -- 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 Wed Oct 26 17:18:37 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 26 Oct 2011 17:18:37 -0500 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: Message-ID: <20111026171837.0dafce03@petrie.dereferenced.org> On Wed, 26 Oct 2011 13:47:03 -0400 Chris wrote: > For folks who do not understand, I'm trying to "McColo" XSServer so > their lack of response in regards to abuse is gone rather than the > suggestions of scripting (guess you didn't read the full text of the > email) or you pushing a product on me because you work for the ISP > that the product is hosted on. Everybody remembers McColo going down > and being dropped from uplinks in 2008 then all the spam disappeared, > right? McColo and Atrivo were disconnected for much larger sins than spamming someone's wordpress blog. William From kloch at kl.net Wed Oct 26 17:19:37 2011 From: kloch at kl.net (Kevin Loch) Date: Wed, 26 Oct 2011 18:19:37 -0400 Subject: Advice on BGP traffic engineering for classified traffic In-Reply-To: <4EA5E595.5080405@brightok.net> References: <4EA5E595.5080405@brightok.net> Message-ID: <4EA88779.5080402@kl.net> Jack Bates wrote: > I'm curious if anyone has a pointer on traffic manipulation for > classified traffic. > > Basics, I have a really cheap transit connection that some customers are > paying reduced rates to only use that connection (and not my other > transits). Though I've considered support for cases where NSP peering > disputes break out. While I can advertise their networks out the correct > transit for return traffic, I still have to figure out how to handle > egress traffic. > > I'm guessing the crux of it is policy routing based on source address, > but I'm interested in ways to engineer it to easy management and > scalability. I've considered the possibility of an l3vpn to interconnect > customers that are not requiring full routes, and possibly some type of > vpls tunnel terminated at the necessary router for customers who need > full routes. > > Thoughts, pointers, suggestions? One simple way to do this is with two routers each with a different table. One for your expensive transit and one for your cheap transit. Each customer's vlan is on both routers with vrrp preference set to the desired router for non-bgp customers. expensive transit customers have the ability to failover to the cheap router. you may or not want to allow the reverse to occur. - Kevin From lorell at hathcock.org Wed Oct 26 17:38:43 2011 From: lorell at hathcock.org (Lorell Hathcock) Date: Wed, 26 Oct 2011 17:38:43 -0500 Subject: CACHEbox question Message-ID: Anyone using a CACHEbox? I need to know if they can operate as a layer 2 bridge/proxy. Sent from my iPhone From leigh.porter at ukbroadband.com Wed Oct 26 17:43:56 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 26 Oct 2011 22:43:56 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <20111026221141.CD45515FDD78@drugs.dv.isc.org> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> , <20111026221141.CD45515FDD78@drugs.dv.isc.org> Message-ID: On 26 Oct 2011, at 23:13, "Mark Andrews" wrote: > > In message , "Ricky Beam" writes: >> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell >> wrote:> >>> Why do they do that? >> >> You'd have to ask them. Or more accurately, you'd need to ask their >> system integrator -- I've never seen an "in house" network run like that. >> (and for the record, they were charging for that shitty network access.) >> >> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a >> modern consumer internet. (Translation: It f'ing works.) This is the ISP >> saying, "You aren't a mail *server*." > > MTA == Mail Transfer Agent. You don't have to be a *server* to be > a MTA. Blocking SMTP also prevents your customers running encrypted > mail sessions to prevent nosy ISP's and others looking at what they > are sending. With DNSSEC now being deployed and DANE being > standardised, running a SMTP session with STARTTLS is being a > reality. > This is what I used to do. Any outgoing port 25 was sunk into a pool of SMTP proxies that I wrote. These proxies would look for signs of authentication and if they found them, the session would be proxied to the original destination SMTP server from the same IP address of the originating host. Anything else was proxied to the pool of Ironports which would rate limit and otherwise SPAM examine the mail. That way people using authenticated servers would be allowed through on the assumption that in all likelihood they were OK. Others who do not auth or are SPAM bots would be scrubbed and rate limited quite severely. Our own customers were encouraged to use our outbound SMTP hosts which would either authenticate them if external or just allow them if internal, but with the SPAM scrubbing and less severe rate limiting enabled, Customers who need a higher volume of outbound mail can call us and authenticate to the SMTP servers and we can set them a bespoke profile for rate limiting and message size etc etc. That worked rather well because people's email got out and SPAM was largely stopped. The Ironports were darn good boxes if a little pricey, -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From up at 3.am Wed Oct 26 18:42:14 2011 From: up at 3.am (up at 3.am) Date: Wed, 26 Oct 2011 19:42:14 -0400 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <3070789B-ECE7-458F-B89C-4E2B39C265AA@delong.com> Message-ID: <2394011ab0b48cbabfa08ba9d9e09aeb.squirrel@ssl.pil.net> > On our retail footprint we block outbound traffic from customers with dynamic IPs > towards port 25, our support tells them to use their ISP's port 587 server.... > That being said, since all of our home users have 50 mbit/sec or greater upload > speeds we are pretty paranoid about the amount of spam that could be originated. > > We don't block anything on static assignments. Honestly, even as a very geeky > user, I probably would not have noticed the block and I can confirm that it is > massively important to lowering our spam footprint as a network. > > I asked our support people, and none of them had ever really had an issue with > this policy in terms of keeping customers. I agree with Ricky's current comment > on this thread, blocking is unfortunately necessary on the modern consumer > portions of the internet. Exactly. Just like not having wide open SMTP relays became "unfortunately necessary" over a dozen years ago. It's just the way it is and there is a solution for it. From blakjak at blakjak.net Wed Oct 26 19:04:49 2011 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 27 Oct 2011 13:04:49 +1300 Subject: Outgoing SMTP Servers In-Reply-To: <20111026221141.CD45515FDD78@drugs.dv.isc.org> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <20111026221141.CD45515FDD78@drugs.dv.isc.org> Message-ID: <4EA8A021.9000805@blakjak.net> On 27/10/11 11:11, Mark Andrews wrote: > In message , "Ricky Beam" writes: >> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell >> wrote:> >>> Why do they do that? >> You'd have to ask them. Or more accurately, you'd need to ask their >> system integrator -- I've never seen an "in house" network run like that. >> (and for the record, they were charging for that shitty network access.) >> >> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a >> modern consumer internet. (Translation: It f'ing works.) This is the ISP >> saying, "You aren't a mail *server*." > MTA == Mail Transfer Agent. You don't have to be a *server* to be > a MTA. Blocking SMTP also prevents your customers running encrypted > mail sessions to prevent nosy ISP's and others looking at what they > are sending. With DNSSEC now being deployed and DANE being > standardised, running a SMTP session with STARTTLS is being a > reality. Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to prevent customers running encrypted mail sessions? If SMTP = 25/TCP and encrypted mail sessions run on another port, they're not blocked? > Now most people don't care about this but you shouldn't have to get > a business grade service just to have secure email sessions and if > you want to run a SMTP server to do that you are not changing the > amount of traffic going over the connection so why the hell should > a ISP care. IMAP, POP, SMTP all have about the same overhead for > inbound email. The majority of consumers will use the SMTP service their ISP provides and not look twice. Surely anyone wanting to use something different will either a) run their own mail server, requiring a static IP address and simply requiring the ISP to flick a switch which says 'ok, you're not blocked for 25/TCP anymore' or b) use an alternative SMTP server on port != 25/TCP with their own authentication layer and responsibility thereof. Sometimes I feel like contributors to NANOG see themselves as typical users. IT Engineers are anything but typical when you compare to mom-and-pop-interwebs-user, and it's those very users who're likely to wind up with malware that'll be firing to random external SMTP servers via 25/TCP, delivering spam which is quite effectively blocked by a 25/TCP block. I've seen recently SMTP-AUTH sessions exploited (user/pass credentials borrowed) for spam purposes, but at least this is an order of magnitude more difficult for the spammer, and more easily tracked by the ISP than having to do IP/Time based records checks. >> MUA's (mail clients) should only be >> connecting to specified MSA's or MTA's (mail *servers*). They should >> never be connecting to random MTA's (presumably for direct delivery, which >> is the job of an MTA not MUA.) The only people who can effectively police >> this is the ISP. > Total utter BS. Why? It's a reasonable position; end users in the generic sense are sending to whatever their client has set up for SMTP, fire-and-forget. Again, I feel like folks are taking their relatively complicated use-cases and treating them as the norm. Mark. From caldcv at gmail.com Wed Oct 26 19:22:53 2011 From: caldcv at gmail.com (Chris) Date: Wed, 26 Oct 2011 20:22:53 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: <20111026171837.0dafce03@petrie.dereferenced.org> References: <20111026171837.0dafce03@petrie.dereferenced.org> Message-ID: > McColo and Atrivo were disconnected for much larger sins than spamming > someone's wordpress blog. Many of you do not understand the scope of "just spamming a Wordpress blog". This is a huge business. Shady "SEO" companies are charging individuals at least $250 per month to use their spam tools of choice to spam forums and Wordpress blogs. I got one of the major players on the run right now because he cannot seem to keep his "business page" hosted with a company longer than a few weeks and I keep playing whack-a-mole with him. Guess what? Innocent people's websites are being deranked on Google for hiring these guys with their shady backlink services and their money is being taken. Yes I know they got what they deserved, but it's so obvious with these backlink guys using cheap virtual private servers for a month, getting shutdown and getting a new IP address that something needs to be done. XSServer could have simply amused me with a default auto reply to make it look like they are doing something. > Will your host allow you to block IP ranges? Not the solution I was looking for because blocking IP ranges and using scripts / services / etc like Akismet or others is simply ignoring the problem, not solving it. For folks who say hosting companies are not helpful: Linode, Amazon, BurstNET, Ubiquity Servers and others are extremely responsive to abuse complaints. -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From marka at isc.org Wed Oct 26 20:01:16 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 27 Oct 2011 12:01:16 +1100 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Thu, 27 Oct 2011 13:04:49 +1300." <4EA8A021.9000805@blakjak.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <20111026221141.CD45515FDD78@drugs.dv.isc.org> <4EA8A021.9000805@blakjak.net> Message-ID: <20111027010116.1517B160050F@drugs.dv.isc.org> In message <4EA8A021.9000805 at blakjak.net>, Mark Foster writes: > On 27/10/11 11:11, Mark Andrews wrote: > > In message , "Ricky Beam" writes: > >> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell > > >> wrote:> > >>> Why do they do that? > >> You'd have to ask them. Or more accurately, you'd need to ask their > >> system integrator -- I've never seen an "in house" network run like that. > > >> (and for the record, they were charging for that shitty network access.) > >> > >> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a > >> modern consumer internet. (Translation: It f'ing works.) This is the ISP > >> saying, "You aren't a mail *server*." > > MTA == Mail Transfer Agent. You don't have to be a *server* to be > > a MTA. Blocking SMTP also prevents your customers running encrypted > > mail sessions to prevent nosy ISP's and others looking at what they > > are sending. With DNSSEC now being deployed and DANE being > > standardised, running a SMTP session with STARTTLS is being a > > reality. > > Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to > prevent customers running encrypted mail sessions? > If SMTP = 25/TCP and encrypted mail sessions run on another port, > they're not blocked? It's encrypted email direct to MX. With that I can know that the email has been delivered to their mail exchangers. > > Now most people don't care about this but you shouldn't have to get > > a business grade service just to have secure email sessions and if > > you want to run a SMTP server to do that you are not changing the > > amount of traffic going over the connection so why the hell should > > a ISP care. IMAP, POP, SMTP all have about the same overhead for > > inbound email. > The majority of consumers will use the SMTP service their ISP provides > and not look twice. > Surely anyone wanting to use something different will either > > a) run their own mail server, requiring a static IP address and simply > requiring the ISP to flick a switch which says 'ok, you're not blocked > for 25/TCP anymore' And lots of ISP's don't offer those knobs in the misguided view that individuals don't need them. > b) use an alternative SMTP server on port != 25/TCP with their own > authentication layer and responsibility thereof. Which is just a non-starter. > Sometimes I feel like contributors to NANOG see themselves as typical > users. IT Engineers are anything but typical when you compare to > mom-and-pop-interwebs-user, and it's those very users who're likely to > wind up with malware that'll be firing to random external SMTP servers > via 25/TCP, delivering spam which is quite effectively blocked by a > 25/TCP block. As I said, most don't need it but for the few that do it should be available and shouldn't require one to get a business service. It's like ISP's that won't deliver business grade services to homes. Just because someone doesn't meet you pre-conceptions of their need it doesn't mean that what they need is unreasonable. > I've seen recently SMTP-AUTH sessions exploited (user/pass credentials > borrowed) for spam purposes, but at least this is an order of magnitude > more difficult for the spammer, and more easily tracked by the ISP than > having to do IP/Time based records checks. > >> MUA's (mail clients) should only be > >> connecting to specified MSA's or MTA's (mail *servers*). They should > >> never be connecting to random MTA's (presumably for direct delivery, which > > >> is the job of an MTA not MUA.) The only people who can effectively police > > >> this is the ISP. > > Total utter BS. > > Why? It's a reasonable position; end users in the generic sense are > sending to whatever their client has set up for SMTP, fire-and-forget. > Again, I feel like folks are taking their relatively complicated > use-cases and treating them as the norm. It's ths whole attitude that end users are incapable on doing thing correctly. Most user are prefectly fine with having their mail go through a ISP's servers but there are exceptions and when people start say "only a ISP can do this" or "only business need this" by BS detector goes off because individuals do need to do the same sorts of things. Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Wed Oct 26 20:17:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 26 Oct 2011 21:17:12 -0400 (EDT) Subject: Outgoing SMTP Servers In-Reply-To: <20111026221141.CD45515FDD78@drugs.dv.isc.org> Message-ID: <24975215.280.1319678232058.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > Now most people don't care about this but you shouldn't have to get > a business grade service just to have secure email sessions and if > you want to run a SMTP server to do that you are not changing the > amount of traffic going over the connection so why the hell should > a ISP care. IMAP, POP, SMTP all have about the same overhead for > inbound email. They shouldn't care. Such users (probably 1% or less, though we tend, due to nerdview, to forget that) are collateral damage to what they're *trying* to do, which is to block the 99% of the traffic with that profile, which is bot spam. This has nothing to do with bandwidth; that's a strawman. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From scott at doc.net.au Wed Oct 26 21:57:23 2011 From: scott at doc.net.au (Scott Howard) Date: Wed, 26 Oct 2011 19:57:23 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> Message-ID: On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui wrote: > Blocking port/25 is a common practice (!= best practice) for home > users/consumers because it makes life a bit simpler in educating the end > user. > MAAWG have considered this a best practice for residential/dynamic IPs since 2005 - http://www.uceprotect.net/downloads/MAAWGPort25English.pdf The FTC and numerous other government agreed the same year - http://www.ftc.gov/bcp/edu/microsites/spam/zombie/letter_english.pdf (The URL in the pdf no longer works - it's not http://www.ftc.gov/bcp/edu/microsites/spam/zombie/) Anyone not yet past the denial stage on this one needs to get themselves a copy of RFC 5068 and start reading. Scott. From jeff-kell at utc.edu Wed Oct 26 22:07:12 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 26 Oct 2011 23:07:12 -0400 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <6F877A0C-5CAB-4856-86C6-3408518BFD71@delong.com> Message-ID: <4EA8CAE0.4040909@utc.edu> On 10/26/2011 10:57 PM, Scott Howard wrote: > On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui wrote: > >> Blocking port/25 is a common practice (!= best practice) for home >> users/consumers because it makes life a bit simpler in educating the end >> user. And it's not just 25. I'm on Charter, and they're blocking 135-139, 445, and 1434 too. Give Netalyzr a shot from your ISP. Jeff From scott at doc.net.au Wed Oct 26 22:07:58 2011 From: scott at doc.net.au (Scott Howard) Date: Wed, 26 Oct 2011 20:07:58 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong wrote: > Interesting... Most people I know run the same policy on 25 and 587 these > days... > > to-local-domain, no auth needed. > relay, auth needed. > > auth required == TLS required. > > Anything else on either port seems not best practice to me. > RFC 5068 covers the best practice, and it's not what you've got above. Allowing unauthenticated inbound mail on port 587 defeats the entire purpose of blocking port 25 - the front door is now closed to spammers, but you've left the back door open! (Security through obscurity saves you here in that spammers rarely use port 587 - yet). There isn't a single situations where you should be expecting an unauthenticated inbound message on the 'Submission' port (is, 587) As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it! Scott. From owen at delong.com Wed Oct 26 23:41:44 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Oct 2011 21:41:44 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: On Oct 26, 2011, at 8:07 PM, Scott Howard wrote: > On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong wrote: > Interesting... Most people I know run the same policy on 25 and 587 these > days... > > to-local-domain, no auth needed. > relay, auth needed. > > auth required == TLS required. > > Anything else on either port seems not best practice to me. > > RFC 5068 covers the best practice, and it's not what you've got above. > > Allowing unauthenticated inbound mail on port 587 defeats the entire purpose of blocking port 25 - the front door is now closed to spammers, but you've left the back door open! (Security through obscurity saves you here in that spammers rarely use port 587 - yet). There isn't a single situations where you should be expecting an unauthenticated inbound message on the 'Submission' port (is, 587) > I still believe that that RFC is not correct. That blocking port 25 has too much collateral damage and is not a best practice. As such, you are correct, I am not following RFC 5068. A certain amount of spam does hit my system, but, the hosts that deliver it are identified and blocked reasonably quickly. > As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it! > Blocking outbound port 25 would not reduce the already infinitesimal volume of spam leaving my network in the least. It would, however, block a lot of legitimate traffic. No thanks. Owen From nenolod at systeminplace.net Thu Oct 27 00:52:41 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 27 Oct 2011 00:52:41 -0500 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: <20111026171837.0dafce03@petrie.dereferenced.org> Message-ID: <20111027005241.33b1f951@petrie.dereferenced.org> On Wed, 26 Oct 2011 20:22:53 -0400 Chris wrote: > > McColo and Atrivo were disconnected for much larger sins than > > spamming someone's wordpress blog. > > Many of you do not understand the scope of "just spamming a Wordpress > blog". I do understand the scope of shady SEO companies. > This is a huge business. Shady "SEO" companies are charging > individuals at least $250 per month to use their spam tools of choice > to spam forums and Wordpress blogs. I got one of the major players on > the run right now because he cannot seem to keep his "business page" > hosted with a company longer than a few weeks and I keep playing > whack-a-mole with him. McColo and Atrivo were not terminated because of spam. If you believe they are, then you are simply misinformed. Atrivo and McColo were terminated over their network being used extensively for botnet control centers. Really! Not spam! > Guess what? Innocent people's websites are being deranked on Google > for hiring these guys with their shady backlink services and their > money is being taken. Bummer. Indeed, it sucks to be them. Newsflash: only morons hire "SEO companies." Perhaps Google is just working on increasing relevance quality by penalizing them for being morons. I would say it is a brilliant strategy, myself. > Yes I know they got what they deserved, but it's so obvious with > these backlink guys using cheap virtual private servers for a month, > getting shutdown and getting a new IP address that something needs to > be done. Ok, and when they go to another budget VPS provider other than XSServer? I am just wondering if you have a strategy for that scenario. Will you come and whine on NANOG about that provider too? > > XSServer could have simply amused me with a default auto reply to make > it look like they are doing something. Wow, thanks for the pro tip. You're telling me that if I just replace my abuse at systeminplace.net contact with an autoresponder that most people will just assume that we are "doing something" and I can go and spend all my time on hookers and booze instead of terminating spammers? Shit. Why didn't anyone tell me earlier? > > > Will your host allow you to block IP ranges? > > Not the solution I was looking for because blocking IP ranges and > using scripts / services / etc like Akismet or others is simply > ignoring the problem, not solving it. > > For folks who say hosting companies are not helpful: Linode, Amazon, > BurstNET, Ubiquity Servers and others are extremely responsive to > abuse complaints. > William From bjorn at mork.no Thu Oct 27 02:10:43 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 27 Oct 2011 09:10:43 +0200 Subject: Outgoing SMTP Servers In-Reply-To: <20111027010116.1517B160050F@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 27 Oct 2011 12:01:16 +1100") References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <4EA689BF.6060206@unfix.org> <569C8AFC-CAC4-47DA-9664-7E2227F51305@delong.com> <4EA69A34.4080300@unfix.org> <20111026221141.CD45515FDD78@drugs.dv.isc.org> <4EA8A021.9000805@blakjak.net> <20111027010116.1517B160050F@drugs.dv.isc.org> Message-ID: <871uty52q4.fsf@nemi.mork.no> Mark Andrews writes: > In message <4EA8A021.9000805 at blakjak.net>, Mark Foster writes: > >> Why? It's a reasonable position; end users in the generic sense are >> sending to whatever their client has set up for SMTP, fire-and-forget. >> Again, I feel like folks are taking their relatively complicated >> use-cases and treating them as the norm. > > It's ths whole attitude that end users are incapable on doing thing > correctly. Most user are prefectly fine with having their mail > go through a ISP's servers but there are exceptions and when people > start say "only a ISP can do this" or "only business need this" by > BS detector goes off because individuals do need to do the same > sorts of things. Yes. Moving behind the BS, it's most likely a well calculated difference between designing a product for 99% of the users or going for the full 100%. The problem is that some of the less technical ISP staff, who often are involved in product definitons or financial and marketing decisions, will think that 99% is "everyone" :-) FWIW, we've been running a 25/tcp filter by default for a few years now, offering a knob to turn it off from the start. The knob is one of very few settings the users are offered in their self-service web UI, along with "change my password", "upgrade my account" and similar. Disabling the filter is of course free of charge. And when initially enabling the filter, all users were informed about the possibility to turn it off. Current status is that approx 1% of our users have disabled the filter so far. I assume most of them did so because they actually need access to port 25/tcp, but some may have just turned it off to see what happened and forgot about it. Filters will rarely be enabled again when first disabled, as disabled filters naturally are unnoticable. This makes the number of users disabling any given filter service aggregate over time. Anyway, that's the number we see. YMMV Whether that 1% of users are important to you or not will probably depend on a lot of factors. But I believe it's safe to say that those users can be classified as "power users", who will have a much higher tendency to buy more expensive products and to discuss their their ISP experiences with other power users. This makes them a lot more valuable than the number itself would indicate. Bj?rn From bjorn at mork.no Thu Oct 27 02:37:21 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 27 Oct 2011 09:37:21 +0200 Subject: Outgoing SMTP Servers In-Reply-To: (Owen DeLong's message of "Wed, 26 Oct 2011 21:41:44 -0700") References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: <87wrbq3mxa.fsf@nemi.mork.no> Owen DeLong writes: > On Oct 26, 2011, at 8:07 PM, Scott Howard wrote: > >> As much as some ISPs still resist blocking port 25 for residential >> customers, it does have a major impact on the volume of spam leaving >> your network. I've worked with numerous ISPs as they have gone >> through the process of blocking port 25 outbound. In every case the >> number of end-user complaints has been low enough to be basically >> considered background noise, but the benefits have been significant - >> including one ISP who removed not only themselves but also their >> entire country from most of the 'Top 10 Spammers' list when they did >> it! >> > > Blocking outbound port 25 would not reduce the already infinitesimal > volume of spam leaving my network in the least. It would, however, > block a lot of legitimate traffic. > > No thanks. I understand that. But you may want to say "Yes, please" to having port 25 blocked by default while having the ability to turn that filter off. As a residential user, the IP address you use to connect to MXs will inevitably be one carved out of a pool allocated to residential users. This is completely independent of whether you are using IPv4 or IPv6, or having static or dynamic addresses. You buy a residential product => you get a residential address. What that means to you, is that the filters running on all the MXs around the world will classify *you* based on the observed behaviour of all the residential customers of your ISP (among other factors of course, but that's not relevant for this discussion). If your ISP offers an open port 25 to everyone policy, then you may experience that your legitimate traffic drowns in a large volume of worm or virus initiated traffic, making a number of MXs drop your traffic with the rest of the bunch. If, on the other hand, your ISP block port 25 by default and let you disable the filter, then your traffic will probably account for a significant part of the traffic the MXs of the world see from that address pool. This increases the probability that they classify the pool as "friendly", and end up accepting your traffic. Most MXs will probably have a sane enough policy to make them accept your mail in either case. But some won't. And as I'm sure you are aware of: You can influence your local policy by choosing your ISP, but you can rarely influence the policies of the MXs you want to talk to. That's why you would want to say "yes, please" to the "filter by default but offer a disable knob" service. Bj?rn From nderitualex at gmail.com Thu Oct 27 03:45:06 2011 From: nderitualex at gmail.com (Alex Nderitu) Date: Thu, 27 Oct 2011 11:45:06 +0300 Subject: Recommendation for customer monitoring network tool/portal for a large ISP Message-ID: <4EA91A12.9050000@gmail.com> Hello, What solutions do you guys in the fixed network business/ISPs use to provide customer portals for network KPI reporting to customers in a fixed network on real time basis. The KPI in question are network availability, utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc in a multi vendor environment. What would you recommend especially in the licensed/supported options and not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale well for hundreds of thousand of clients. We have been using Orion NPM and it pretty much does the job but would wish to move to something more scalable for SP environment. Regards, Alex. From leigh.porter at ukbroadband.com Thu Oct 27 03:49:01 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 27 Oct 2011 08:49:01 +0000 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: <4EA91A12.9050000@gmail.com> References: <4EA91A12.9050000@gmail.com> Message-ID: I looked at Statseeker a while back and it was very good. -- Leigh On 27 Oct 2011, at 09:47, "Alex Nderitu" wrote: > Hello, > What solutions do you guys in the fixed network business/ISPs use to provide customer portals for network KPI reporting to customers in a fixed network on real time basis. The KPI in question are network availability, utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc in a multi vendor environment. > > > What would you recommend especially in the licensed/supported options and not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale well for hundreds of thousand of clients. > > We have been using Orion NPM and it pretty much does the job but would wish to move to something more scalable for SP environment. > > Regards, > Alex. > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jeffg at opennms.org Thu Oct 27 08:54:17 2011 From: jeffg at opennms.org (Jeff Gehlbach) Date: Thu, 27 Oct 2011 09:54:17 -0400 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: <4EA91A12.9050000@gmail.com> References: <4EA91A12.9050000@gmail.com> Message-ID: <4EA96289.70806@opennms.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2011 04:45 AM, Alex Nderitu wrote: > What would you recommend especially in the licensed/supported > options and not the free ones like Zabbix, Cacti, MRTG etc. Those free options you mentioned are in fact licensed -- here's the license for Zabbix: http://bit.ly/sBCGJR Cacti and MRTG are distributed under the same license. Zabbix, at least, is supported commercially by a company consisting of grown-ups who know what they're doing. They can get their platform to do really cool things and to scale better than you could do, because they know the platform better than anybody else. I work for another company that has a similar relationship to a different free-software management platform; see the domain part of my e-mail address if you care which one it is. Whichever platform you choose, you should be prepared to spend far more on consulting (or pricey headcount) than on acquisition or maintenance of hardware and software. For any platform to scale to the extent you're talking about, it's going to require extensive expert customization as well as constant care and feeding. I've been managing networks in-house and in consulting roles for over a decade, and this rule always applies. My point in all this is that, while most free-software platforms suck at scaling up because they're not designed for huge scale, you should not dismiss this entire class of platforms out of hand any more than you would dismiss all proprietary offerings on account of Orion NPM missing the mark. - -jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6pYoMACgkQB3953+hexDo54ACgow6HS+JNtHlNk6aIL5Zs7Fmg Ja4AnRpsqJsxZCHMWzndpvrG8IN7h3FU =DlBY -----END PGP SIGNATURE----- From bjohnson at drtel.com Thu Oct 27 08:53:34 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 27 Oct 2011 13:53:34 +0000 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: I find that large network providers have less issues with this issue. As a small regional provider, implementing a "sane" port 25 filter has saved us a lot of money and customer headaches over the years. Our costs would be much higher if we could not save labor hours by implementing this. Possibly making service costs even more prohibitive. Pre implementation of these filters we had lower customer satisfaction, and were contemplating hiring more people to handle the labor load, due to UCE issues. It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users. But this thread has been interesting to follow. :) - Brian J. >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Wednesday, October 26, 2011 11:42 PM >To: Scott Howard >Cc: nanog at nanog.org >Subject: Re: Outgoing SMTP Servers > > >On Oct 26, 2011, at 8:07 PM, Scott Howard wrote: > >> On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong >wrote: >> Interesting... Most people I know run the same policy on 25 and 587 these >> days... >> >> to-local-domain, no auth needed. >> relay, auth needed. >> >> auth required == TLS required. >> >> Anything else on either port seems not best practice to me. >> >> RFC 5068 covers the best practice, and it's not what you've got above. >> >> Allowing unauthenticated inbound mail on port 587 defeats the entire >purpose of blocking port 25 - the front door is now closed to spammers, but >you've left the back door open! (Security through obscurity saves you here in >that spammers rarely use port 587 - yet). There isn't a single situations where >you should be expecting an unauthenticated inbound message on the >'Submission' port (is, 587) >> >I still believe that that RFC is not correct. That blocking port 25 has too much >collateral damage >and is not a best practice. > >As such, you are correct, I am not following RFC 5068. A certain amount of >spam does hit my >system, but, the hosts that deliver it are identified and blocked reasonably >quickly. > >> As much as some ISPs still resist blocking port 25 for residential customers, it >does have a major impact on the volume of spam leaving your network. I've >worked with numerous ISPs as they have gone through the process of >blocking port 25 outbound. In every case the number of end-user complaints >has been low enough to be basically considered background noise, but the >benefits have been significant - including one ISP who removed not only >themselves but also their entire country from most of the 'Top 10 Spammers' >list when they did it! >> > >Blocking outbound port 25 would not reduce the already infinitesimal volume >of spam leaving my network in the least. It would, however, block a lot of >legitimate traffic. > >No thanks. > >Owen From keegan.holley at sungard.com Thu Oct 27 10:00:23 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 27 Oct 2011 11:00:23 -0400 Subject: Colocation providers and ACL requests In-Reply-To: <26408157.222.1319639843740.JavaMail.root@benjamin.baylink.com> References: <26408157.222.1319639843740.JavaMail.root@benjamin.baylink.com> Message-ID: 2011/10/26 Jay Ashworth > ----- Original Message ----- > > From: "Keegan Holley" > > > > ----- Original Message ----- > > > > From: "Keegan Holley" > > > > > > > I'm assuming colo means hosting, and the OP misspoke. Most colo > > > > providers > > > > don't provide active network for colo (as in power and rack only) > > > customers. > > > > > > Most? > > > > I'm sure there are exceptions to that rule. It's better than "YMMV". > > Perhaps I look at a different category of colo provider, then, but I'm > accustomed to seeing it be well up into double-digit percentage of the ones > I've ever looked at. > > "Hosting", to me, means "provider's hardware", not just "local blended > bandwidth". > > > I think you may have misunderstood me. I mean local blended bandwidth to be a colo provider offering extra services. Hosting is provider hardware and there should be a certain level of quality to the services and operation. A colo provider providing the same service as either courtesy access or a low cost alternative to access from an ISP wouldn't be held to the same standard for obvious reasons. There's also "virtual hosting" which can be nothing other than "local blended bandwidth". But none of those webfarm types would be on a list like this.... right?? ;) From Valdis.Kletnieks at vt.edu Thu Oct 27 10:23:33 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 Oct 2011 11:23:33 -0400 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Thu, 27 Oct 2011 13:53:34 -0000." References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> Message-ID: <21422.1319729013@turing-police.cc.vt.edu> On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said: > It is interesting that some people who fully understand that the Internet is > composed of many networks run by people with different interests can say what > is best for the Internet as a whole. How my organization (or yours or anybody > else's) runs our network, is between us and our paying users. The fact that a behavior is "best" for your network does in no way, shape, or form, say anything about what's best for the Internet as a whole. In fact, it's well-understood that there are entire classes of behaviors that are optimal for single actors, but fail when deployed widely. https://en.wikipedia.org/wiki/Tragedy_of_the_commons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bonomi at mail.r-bonomi.com Thu Oct 27 12:50:22 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 27 Oct 2011 12:50:22 -0500 (CDT) Subject: Outgoing SMTP Servers In-Reply-To: <21422.1319729013@turing-police.cc.vt.edu> Message-ID: <201110271750.p9RHoMCT065493@mail.r-bonomi.com> On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said: > It is interesting that some people who fully understand that the Internet is > composed of many networks run by people with different interests can say what > is best for the Internet as a whole. How my organization (or yours or anybody > else's) runs our network, is between us and our paying users. That claim is true *ONLY* to the extent that 'how your organization runs your network' does _not_ have an adverse effect on other peoples networks. The fact of the matter is that you do not have a viable business without the collective 'tolerance'/'approval' of the rest of the world. You, and your organization, need them far more than they need you. _How_ you pro-actively ensure spam does not exit from your network IS your business. That you *do* do so _is_ within the action purveiw of the 'rest of the world'. "Doing so" requires that you _actively_ monitor the behavior of your customers and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately upon detection, such abusive behavior by your customers. One of the 'easiest', and most _cost-effective_ ways of doing so *is* to force all outgoing mail from your customers through a 'choke point' for examination/filtering/blckcing. The simplest way of doing that, *without* running afoul of 'wiretapping' statutes. is to require, by policy and by blocking direct external access, that customer out-bound email traffic go through your servers, and doing the necessary 'inspection' there. From bjohnson at drtel.com Thu Oct 27 13:17:22 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 27 Oct 2011 18:17:22 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <21422.1319729013@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> Message-ID: >-----Original Message----- >From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >Sent: Thursday, October 27, 2011 10:24 AM >To: Brian Johnson >Cc: nanog at nanog.org >Subject: Re: Outgoing SMTP Servers > >On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said: > >> It is interesting that some people who fully understand that the Internet is >> composed of many networks run by people with different interests can say >what >> is best for the Internet as a whole. How my organization (or yours or >anybody >> else's) runs our network, is between us and our paying users. > >The fact that a behavior is "best" for your network does in no way, shape, or >form, say anything about what's best for the Internet as a whole. In fact, >it's well-understood that there are entire classes of behaviors that are >optimal for single actors, but fail when deployed widely. > >https://en.wikipedia.org/wiki/Tragedy_of_the_commons So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent (and a little sophomoric). :) From bjohnson at drtel.com Thu Oct 27 13:24:22 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 27 Oct 2011 18:24:22 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <201110271750.p9RHoMCT065493@mail.r-bonomi.com> References: <21422.1319729013@turing-police.cc.vt.edu> <201110271750.p9RHoMCT065493@mail.r-bonomi.com> Message-ID: >-----Original Message----- >From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] >Sent: Thursday, October 27, 2011 12:50 PM >To: nanog at nanog.org >Subject: Re: Outgoing SMTP Servers > > >On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said: > >> It is interesting that some people who fully understand that the Internet is >> composed of many networks run by people with different interests can say >what >> is best for the Internet as a whole. How my organization (or yours or >anybody >> else's) runs our network, is between us and our paying users. > >That claim is true *ONLY* to the extent that 'how your organization runs >your network' does _not_ have an adverse effect on other peoples networks. > >The fact of the matter is that you do not have a viable business without >the collective 'tolerance'/'approval' of the rest of the world. > OK. >You, and your organization, need them far more than they need you. > Argumentative and unnecessary. >_How_ you pro-actively ensure spam does not exit from your network IS your >business. > >That you *do* do so _is_ within the action purveiw of the 'rest of the world'. > Judge me as you will. My customers will determine if I change this policy. Their judgment is all that matters in this circumstance as the external Internet community has the access that the Internet community needs relative to this instance. >"Doing so" requires that you _actively_ monitor the behavior of your >customers >and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately >upon detection, such abusive behavior by your customers. > >One of the 'easiest', and most _cost-effective_ ways of doing so *is* to >force all outgoing mail from your customers through a 'choke point' for >examination/filtering/blckcing. > >The simplest way of doing that, *without* running afoul of 'wiretapping' >statutes. is to require, by policy and by blocking direct external access, >that customer out-bound email traffic go through your servers, and doing >the necessary 'inspection' there. > > I think you support my position, but I could be convinced otherwise. :) Be careful with you punctuation. I got lost a few times there :) - Brian From rsk at gsp.org Thu Oct 27 13:43:09 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Thu, 27 Oct 2011 14:43:09 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: <20111026171837.0dafce03@petrie.dereferenced.org> Message-ID: <20111027184309.GA28820@gsp.org> On Wed, Oct 26, 2011 at 08:22:53PM -0400, Chris wrote: > For folks who say hosting companies are not helpful: Linode, Amazon, > BurstNET, Ubiquity Servers and others are extremely responsive to > abuse complaints. Burstnet is one of the filthiest sewers on the entire Internet. Has been for many years. They are vehemently pro-spam. See, for example: http://groups.google.com/group/news.admin.net-abuse.email/msg/fba14415f70e08c8 They are thus not a good counterexample to use in this case. ---rsk From cliff.bowles at apollogrp.edu Thu Oct 27 13:51:55 2011 From: cliff.bowles at apollogrp.edu (Cliff Bowles) Date: Thu, 27 Oct 2011 11:51:55 -0700 Subject: BGP AS question Message-ID: <1A5C3257AD8D4946A4B497A6FAF5017423F99B6A4E@EXCH07-01.apollogrp.edu> Greetings. We have a few facilities within a 30 mile radius, and each has an ISP link. We use P2P links at the edge to make certain traffic sourcing from one facility, and destined to the Public IPs at another, stay on the "dirty" links rather than punting out to the ISP. All sites use the same BGP AS. Recently, we were required to turn up an additional facility in a short time frame. It also uses the same BGP AS. However, it does not have a dirty cross-connect link. So, even though this facility has unique /24 public IP blocks, it still has the same AS. One thing we are noticing is that some ISPs don't seem to have a problem allowing this traffic, and some do. I suspect some don't like traffic with the same source and destination BGP AS, even though the prefixes are different at each location. But other ISPs seem to permit this with no problem. My question is: is normal BGP default behavior to permit or to allow this type of traffic? Also, would it be easier to ask the ISP to make an exception, or to buy another AS for the rogue facility? Thanks. Clifford W Bowles, Technical Director Apollo Group | IT Services | Network Engineering 4025 S. Riverpoint Parkway | CF-C201 | Phoenix, AZ 85040 phone: 602-557-6762 | fax: 602-557-6607 | email: cliff.bowles at apollogrp.edu ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From Gabriel.McCall at thyssenkrupp.com Thu Oct 27 14:13:06 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Thu, 27 Oct 2011 15:13:06 -0400 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: <4EA91A12.9050000@gmail.com> References: <4EA91A12.9050000@gmail.com> Message-ID: I'm getting ready to do an eval of Monolith Software's monitoring/management product. They have some very nice multi-tenant dashboarding and reporting capabilities and are extremely scalable. -Gabriel -----Original Message----- From: Alex Nderitu [mailto:nderitualex at gmail.com] Sent: Thursday, October 27, 2011 4:45 AM To: nanog at nanog.org Subject: Recommendation for customer monitoring network tool/portal for a large ISP Hello, What solutions do you guys in the fixed network business/ISPs use to provide customer portals for network KPI reporting to customers in a fixed network on real time basis. The KPI in question are network availability, utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc in a multi vendor environment. What would you recommend especially in the licensed/supported options and not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale well for hundreds of thousand of clients. We have been using Orion NPM and it pretty much does the job but would wish to move to something more scalable for SP environment. Regards, Alex. From mike-nanog at tiedyenetworks.com Thu Oct 27 14:30:58 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 27 Oct 2011 12:30:58 -0700 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: References: Message-ID: <4EA9B172.5000202@tiedyenetworks.com> Greetings, I have been given the opportunity to teach the mechanics of the Internet to a group of 6 - 12'th grade students, and as an engineer and owner of an ISP I have it in mind to really get into this and show these kids how, really, all this stuff works and to make it fun and exciting. I can't take them on a tour of an ATT central office to show off one of my DSLAMs for example, nor can I really show them what a colocation or IX looks like since they are too far away to drive. I was hoping any of you would be kind enough to provide pictures of these types of environments, especially rack mounted switch/router hardware, fiber optic cabling short and long haul, international undersea cable anchor points, or anything else that would make for a good slide presentation in this context. These kids are in a very rural community where marijuana is the main source of income (followed by meth), and have little access to adults doing this type of stuff in the real world. My focus will also include introducing these kids to the concept of having something better such as a career in information technology and talking about ways they themselves might get involved and on track that way, so these photographs would be extremely helpful to light their young minds and get them thinking about their futures. Thank you all. Mike- From bill at herrin.us Thu Oct 27 14:31:28 2011 From: bill at herrin.us (William Herrin) Date: Thu, 27 Oct 2011 15:31:28 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <201110271750.p9RHoMCT065493@mail.r-bonomi.com> References: <21422.1319729013@turing-police.cc.vt.edu> <201110271750.p9RHoMCT065493@mail.r-bonomi.com> Message-ID: On Thu, Oct 27, 2011 at 1:50 PM, Robert Bonomi wrote: > On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said: >> As a small regional provider, implementing a "sane" port 25 filter has >> saved us a lot of money and customer headaches over the years. >> >> It is interesting that some people who fully understand that the Internet is >> composed of many networks run by people with different interests can say what >> is best for the Internet as a whole. How my organization (or yours or anybody >> else's) runs our network, is between us and our paying users. > > That claim is true *ONLY* to the extent that 'how your organization runs > your network' does _not_ have an adverse effect on other peoples networks. What I *prevent* from entering or leaving my network is *my business*, between me and my customers. What I allow to leave my network can become yours. As with all rules, there's at least one exception: the monopoly or duopoly vendor has an obligation to ensure that restrictions don't abuse his position in the market. Nevertheless, "Mr. Small Business, you shouldn't be blocking that packet, it's bad for the Internet," is not for you or anyone else to say. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From chip.gwyn at gmail.com Thu Oct 27 14:40:28 2011 From: chip.gwyn at gmail.com (chip) Date: Thu, 27 Oct 2011 15:40:28 -0400 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: <4EA9B172.5000202@tiedyenetworks.com> References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: Mike, You might be able to glean some interesting pictures from: http://www.reddit.com/r/cableporn http://www.reddit.com/r/datacenter http://www.flickr.com/groups/cableporn/ * That's actual cables and racks and such, not cinemax late night video =) --chip On Thu, Oct 27, 2011 at 3:30 PM, Mike wrote: > Greetings, > > ? ? ? ?I have been given the opportunity to teach the mechanics of the > Internet to a group of 6 - 12'th grade students, and as an engineer and > owner of an ISP I have it in mind to really get into this and show these > kids how, really, all this stuff works and to make it fun and exciting. I > can't take them on a tour of an ATT central office to show off one of my > DSLAMs for example, nor can I really show them what a colocation or IX looks > like since they are too far away to drive. I was hoping any of you would be > kind enough to provide pictures of these types of environments, especially > rack mounted switch/router hardware, fiber optic cabling short and long > haul, international undersea cable anchor points, or anything else that > would make for a good slide presentation in this context. These kids are in > a very rural community where marijuana is the main source of income > (followed by meth), and have little access to adults doing this type of > stuff in the real world. My focus will also include introducing these kids > to the concept of having something better such as a career in information > technology and talking about ways they themselves might get involved and on > track that way, so these photographs would be extremely helpful to light > their young minds and get them thinking about their futures. > > Thank you all. > > Mike- > > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From bill at herrin.us Thu Oct 27 14:46:33 2011 From: bill at herrin.us (William Herrin) Date: Thu, 27 Oct 2011 15:46:33 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: <20111027005241.33b1f951@petrie.dereferenced.org> References: <20111026171837.0dafce03@petrie.dereferenced.org> <20111027005241.33b1f951@petrie.dereferenced.org> Message-ID: On Thu, Oct 27, 2011 at 1:52 AM, William Pitcock wrote: > On Wed, 26 Oct 2011 20:22:53 -0400 > Chris wrote: >> This is a huge business. Shady "SEO" companies are charging >> individuals at least $250 per month to use their spam tools of choice >> to spam forums and Wordpress blogs. I got one of the major players on >> the run right now because he cannot seem to keep his "business page" >> hosted with a company longer than a few weeks and I keep playing >> whack-a-mole with him. > > McColo and Atrivo were not terminated because of spam. ?If you believe > they are, then you are simply misinformed. ?Atrivo and McColo were > terminated over their network being used extensively for botnet > control centers. William, Atrivo and McColo were terminated _late_. As an industry, might we not consider finding a reasonable way to do a more effective job identifying and dealing with shops who can't seem to keep out the customers who use those facilities to hurt and abuse the rest of us? If we fail to adequately self-regulate, the courts and entities like the U.S. Congress will surely find a way to do it for us. And they won't care nearly as much about the technical constraints as we do. I make no judgment about XSServer and offer no solution. I merely suggest that Chris has posed a legitimate operational problem that our community may wish to redress while the while the details of such a choice are still in our hands. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From godomus27 at gmail.com Thu Oct 27 14:54:47 2011 From: godomus27 at gmail.com (Godonou Dossou) Date: Thu, 27 Oct 2011 15:54:47 -0400 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: References: <4EA91A12.9050000@gmail.com> Message-ID: <8BD3A690-87F8-4D0F-A50A-9AB93AAA2CD0@gmail.com> You can all so look at Zenoss Sent from my iPhone On 2011-10-27, at 4:47 AM, Leigh Porter wrote: > I looked at Statseeker a while back and it was very good. > > -- > Leigh > > > On 27 Oct 2011, at 09:47, "Alex Nderitu" wrote: > >> Hello, >> What solutions do you guys in the fixed network business/ISPs use to provide customer portals for network KPI reporting to customers in a fixed network on real time basis. The KPI in question are network availability, utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc in a multi vendor environment. >> >> >> What would you recommend especially in the licensed/supported options and not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale well for hundreds of thousand of clients. >> >> We have been using Orion NPM and it pretty much does the job but would wish to move to something more scalable for SP environment. >> >> Regards, >> Alex. >> >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From chip.gwyn at gmail.com Thu Oct 27 14:59:00 2011 From: chip.gwyn at gmail.com (chip) Date: Thu, 27 Oct 2011 15:59:00 -0400 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: <4EA91A12.9050000@gmail.com> References: <4EA91A12.9050000@gmail.com> Message-ID: Might want to check out NimSoft as well. Multitenancy built in. http://www.nimsoft.com/solutions On Thu, Oct 27, 2011 at 4:45 AM, Alex Nderitu wrote: > Hello, > What solutions do you guys in the fixed network business/ISPs use to provide > customer portals for network KPI reporting to customers in a fixed network > on real time basis. The KPI in question are network availability, > utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc > in a multi vendor environment. > > > What would you recommend especially in the licensed/supported options and > not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale > well for hundreds of thousand of clients. > > We have been using Orion NPM and it pretty much does the job but would wish > to move to something more scalable for SP environment. > > Regards, > Alex. > > > > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From jason at lixfeld.ca Thu Oct 27 15:05:22 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 27 Oct 2011 16:05:22 -0400 Subject: Recommendation for customer monitoring network tool/portal for a large ISP In-Reply-To: <4EA91A12.9050000@gmail.com> References: <4EA91A12.9050000@gmail.com> Message-ID: We've just deployed Intermapper to do all of our device polling, link status and topology mapping. Works very well and looks real pretty. For graphing, we use cacti with the Discovery and Autom8 plugins. For SNMP trap parsing, we use SNMPTT. We're currently evaluating Splunk to eat the SNMP trap and syslog data from our gear and do cool stuff with it. Last on my list of tools to try is Cisco NCM as a replacement for RANCID. RANCID is amazing, but when we have hundreds of devices with exactly the same base configs on them, something a little more sophisticated than RANCID is required to keep all of those configs in sync. On 2011-10-27, at 4:45 AM, Alex Nderitu wrote: > Hello, > What solutions do you guys in the fixed network business/ISPs use to provide customer portals for network KPI reporting to customers in a fixed network on real time basis. The KPI in question are network availability, utilization, memory/cpu of managed routers/firewall, jitter, packet loss etc in a multi vendor environment. > > > What would you recommend especially in the licensed/supported options and not the free ones like Zabbix, Cacti, MRTG etc. This solution should scale well for hundreds of thousand of clients. > > We have been using Orion NPM and it pretty much does the job but would wish to move to something more scalable for SP environment. > > Regards, > Alex. > > > From lstewart at superb.net Thu Oct 27 15:10:10 2011 From: lstewart at superb.net (Landon Stewart) Date: Thu, 27 Oct 2011 13:10:10 -0700 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: <4EA9B172.5000202@tiedyenetworks.com> References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: I'd probably lift some images from google images personally... EG: data center - Google Search http://bit.ly/u9fPMd On 27 October 2011 12:30, Mike wrote: > Greetings, > > I have been given the opportunity to teach the mechanics of the > Internet to a group of 6 - 12'th grade students, and as an engineer and > owner of an ISP I have it in mind to really get into this and show these > kids how, really, all this stuff works and to make it fun and exciting. I > can't take them on a tour of an ATT central office to show off one of my > DSLAMs for example, nor can I really show them what a colocation or IX looks > like since they are too far away to drive. I was hoping any of you would be > kind enough to provide pictures of these types of environments, especially > rack mounted switch/router hardware, fiber optic cabling short and long > haul, international undersea cable anchor points, or anything else that > would make for a good slide presentation in this context. These kids are in > a very rural community where marijuana is the main source of income > (followed by meth), and have little access to adults doing this type of > stuff in the real world. My focus will also include introducing these kids > to the concept of having something better such as a career in information > technology and talking about ways they themselves might get involved and on > track that way, so these photographs would be extremely helpful to light > their young minds and get them thinking about their futures. > > Thank you all. > > Mike- > > -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From paul at paulgraydon.co.uk Thu Oct 27 15:14:49 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 27 Oct 2011 10:14:49 -1000 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: <4EA9BBB9.70309@paulgraydon.co.uk> Loads of good images on Flickr too: http://www.flickr.com/groups/datacenter/ On 10/27/2011 10:10 AM, Landon Stewart wrote: > I'd probably lift some images from google images personally... > > EG: data center - Google Search http://bit.ly/u9fPMd > > On 27 October 2011 12:30, Mike wrote: > >> Greetings, >> >> I have been given the opportunity to teach the mechanics of the >> Internet to a group of 6 - 12'th grade students, and as an engineer and >> owner of an ISP I have it in mind to really get into this and show these >> kids how, really, all this stuff works and to make it fun and exciting. I >> can't take them on a tour of an ATT central office to show off one of my >> DSLAMs for example, nor can I really show them what a colocation or IX looks >> like since they are too far away to drive. I was hoping any of you would be >> kind enough to provide pictures of these types of environments, especially >> rack mounted switch/router hardware, fiber optic cabling short and long >> haul, international undersea cable anchor points, or anything else that >> would make for a good slide presentation in this context. These kids are in >> a very rural community where marijuana is the main source of income >> (followed by meth), and have little access to adults doing this type of >> stuff in the real world. My focus will also include introducing these kids >> to the concept of having something better such as a career in information >> technology and talking about ways they themselves might get involved and on >> track that way, so these photographs would be extremely helpful to light >> their young minds and get them thinking about their futures. >> >> Thank you all. >> >> Mike- >> >> > From alex-lists-nanog at yuriev.com Thu Oct 27 16:16:18 2011 From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com) Date: Thu, 27 Oct 2011 17:16:18 -0400 Subject: Fiber in Atlantic City, NJ Message-ID: <20111027211617.GM14470@corp.zubrcom.net> Hello, If anyone has/knows of contacts among the fiber providers in Atlantic City, NJ as close to the Broadwalk as possible ( especially those that might have a leg to Philadelphia, PA ), could you kindly reply off list? Thank you, Alex From morrowc.lists at gmail.com Thu Oct 27 16:29:19 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Oct 2011 17:29:19 -0400 Subject: Fiber in Atlantic City, NJ In-Reply-To: <20111027211617.GM14470@corp.zubrcom.net> References: <20111027211617.GM14470@corp.zubrcom.net> Message-ID: On Thu, Oct 27, 2011 at 5:16 PM, wrote: > Hello, > > If anyone has/knows of contacts among the fiber providers in Atlantic City, > NJ as close to the Broadwalk as possible ( especially those that might have > a leg to Philadelphia, PA ), could you kindly reply off list? sounds like quite the gamble... not sure I'd roll the dice on this business plan... From Valdis.Kletnieks at vt.edu Thu Oct 27 16:38:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 Oct 2011 17:38:17 -0400 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Thu, 27 Oct 2011 18:17:22 -0000." References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> Message-ID: <33536.1319751497@turing-police.cc.vt.edu> On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said: > So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent. So I point out the tragedy of the commons, you agree with it, but the Wikipedia reference that talks about the same exact thing isn't pertinent? How does that follow? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From drew.linsalata at gmail.com Thu Oct 27 16:40:31 2011 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 27 Oct 2011 17:40:31 -0400 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: <4EA9B172.5000202@tiedyenetworks.com> References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: I did this at career day last spring for my daughter's fifth grade class. They were a bit young to get too deep into the nitty gritty, but they completely ate up the presentation and it was really gratifying to get notes and emails (all voluntarily sent) from some of the kids talking about how much they learned. All the kids love the Internet and using computers and other related gadgets, so I was a total hit. I'm sure you will be too. Enjoy the experience. On Thu, Oct 27, 2011 at 3:30 PM, Mike wrote: Greetings, > > I have been given the opportunity to teach the mechanics of the > Internet to a group of 6 - 12'th grade students, ..... > > > From pete at altadena.net Thu Oct 27 20:29:18 2011 From: pete at altadena.net (Pete Carah) Date: Thu, 27 Oct 2011 21:29:18 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <33536.1319751497@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> Message-ID: <4EAA056E.5010006@altadena.net> On 10/27/2011 05:38 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said: >> So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent. > > So I point out the tragedy of the commons, you agree with it, but the Wikipedia > reference that talks about the same exact thing isn't pertinent? How does that > follow? :) Maybe he is concerned that the Wikipedia article gets into nit-picking about the ownership of the commons that isn't relevant to our problem, and also is rather long-winded. Hardin got into some things at the end of his paper that probably aren't either (but then, he was a population biologist and not an economist). BTW - that paper is a good read and not too long. The journal link (reference 1 in the wikipedia article) actually works openly (AAAS only blocks full access for a while...) For our purpose, the ownership of the commons in question truly isn't relevant; the fundamental statement of the tragedy for us is that a "useful" resource that is incrementally free (or even cheap enough) to a large number of participants will get exploited and probably overused. I'm not aware of any solution to this problem with commons that doesn't involve a central authority :-( In feudal practice the landlord could do some enforcement; the spanish alcaldes were another good example of a semi-central solution to the commons problem (water rights in their origins, though their authority grew over time). Classic economics says that market pricing is the solution, but that tends to result in another kind of tragedy. -- Pete From steve at pirk.com Thu Oct 27 20:32:24 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Thu, 27 Oct 2011 18:32:24 -0700 Subject: Google+ now available for Google Apps domains Message-ID: Y'all ragged on me because Google+ was only available to gmail users... Well, now you can enable it for your users from the control panel on your Google Apps domains... Google Apps administrators can manually turn on Google+ for > their organization. Once Google+ is turned on, users will need to sign up > at google.com/+ to get started. For customers > who use Google Apps for Business or the free version of Google Apps and who > have chosen to automatically enable new services, > Google+ will automatically become available to all of your users over the > next several days. > > *Editions included:* > Google Apps, Google Apps for Business, Government and Education* http://googleappsupdates.blogspot.com/2011/10/google-now-available-for-google-apps.html Now, do I toss the last 1.5 years of posts and use my apps domain, or stay as my gmail user account. Decisions, decisions... Methjinks history is the better part of valor, so I will stay using my gmail account. It would be cool if you could link them. -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 - Google+ pirk.com From xenith at xenith.org Thu Oct 27 20:46:37 2011 From: xenith at xenith.org (Justin Seabrook-Rocha) Date: Thu, 27 Oct 2011 18:46:37 -0700 Subject: Google+ now available for Google Apps domains In-Reply-To: References: Message-ID: On Oct 27, 2011, at 6:32 PM, steve pirk [egrep] wrote: > Y'all ragged on me because Google+ was only available to gmail users... > Well, now you can enable it for your users from the control panel on your > Google Apps domains... > > Google Apps administrators can manually turn on > Google+ > for >> their organization. Once Google+ is turned on, users will need to sign up >> at google.com/+ to get started. For customers >> who use Google Apps for Business or the free version of Google Apps and who >> have chosen to automatically enable new services, >> Google+ will automatically become available to all of your users over the >> next several days. >> >> *Editions included:* >> Google Apps, Google Apps for Business, Government and Education* > > > http://googleappsupdates.blogspot.com/2011/10/google-now-available-for-google-apps.html > > Now, do I toss the last 1.5 years of posts and use my apps domain, or stay > as my gmail user account. Decisions, decisions... Methjinks history is the > better part of valor, so I will stay using my gmail account. It would be > cool if you could link them. From http://googleenterprise.blogspot.com/2011/10/google-is-now-available-with-google.html "For those of you who?ve already started using Google+ with a personal Google Account and would prefer to use your Google Apps account, we?re building a migration tool to help you move over. With this tool, you won?t have to rebuild your circles, and people who?ve already added you to their circles will automatically be connected to your new profile. We expect this migration option to be ready in a few weeks, so if you?d like, you can go ahead and get started with your Apps account today and merge your connections once the tool is available." Once that tool is complete, you should be able to merge/migrate your gmail G+ account to your Google Apps account. You can already do so with most of the numerous other Google properties. Justin Seabrook-Rocha -- Xenith || xenith at xenith.org || http://xenith.org/ Jabber: xenith at xenith.org || AIM: JustinR98 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james at gitflorida.com Thu Oct 27 22:09:41 2011 From: james at gitflorida.com (James Ashton) Date: Thu, 27 Oct 2011 23:09:41 -0400 (EDT) Subject: Colocation providers and ACL requests In-Reply-To: Message-ID: <29baeb8d-2df0-4dc4-9e63-a89fa4717078@mail.gitflorida.com> Christopher, This is pretty common policy. Not many datacenters of any size is going to act differently. If you don't purchase this service then you will not get the service. They may be willing work work with you on black-holing problem IPs though. This is pretty common, but don't expect a filtering package without purchasing it. James ----- Original Message ----- From: "Christopher Pilkington" To: "NANOG mailing list" Sent: Tuesday, October 25, 2011 2:43:00 PM Subject: Colocation providers and ACL requests Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: deny udp any a.b.c.d/24 eq 80 ?to refuse and tell us we must subscribe to their managed DDOS product? -cjp From rfinnesey at gmail.com Thu Oct 27 22:24:54 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Thu, 27 Oct 2011 23:24:54 -0400 Subject: Mexico? Message-ID: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> If I want to get a block of IP's issued for a network within Mexico who do I talk with? I have been told arin does not cover Mexico. It was my understand arin covers North America. Cheers Ryan From jcurran at arin.net Thu Oct 27 22:33:41 2011 From: jcurran at arin.net (John Curran) Date: Fri, 28 Oct 2011 03:33:41 +0000 Subject: Mexico? In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> Message-ID: <84CE871A-55A1-4632-88DA-EBDCC758F41B@arin.net> On Oct 28, 2011, at 3:24 AM, Ryan Finnesey wrote: > If I want to get a block of IP's issued for a network within Mexico who do I > talk with? I have been told arin does not cover Mexico. It was my > understand arin covers North America. Hi Ryan - ARIN used to cover the entire global minus the RIPE NCC and APNIC regions. When LACNIC was formed, it made sense to have ARIN handle Canada and US from NA, and have LACNIC handle Mexico. Look into www.lacnic.net and also www.nic.mx (NIC Mexico) Thanks! /John John Curran President and CEO ARIN From joelja at bogus.com Thu Oct 27 22:38:43 2011 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 27 Oct 2011 20:38:43 -0700 Subject: Mexico? In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> Message-ID: <4EAA23C3.5080209@bogus.com> On 10/27/11 20:24 , Ryan Finnesey wrote: > If I want to get a block of IP's issued for a network within Mexico who do I > talk with? I have been told arin does not cover Mexico. It was my > understand arin covers North America. mexico moved to the lacnic region with the formation of the lacnic rir. NIC mexico was deeply involved if not instrumental in the formation of lacnic. > > > Cheers > > Ryan > > > From egermann at limanews.com Thu Oct 27 22:42:59 2011 From: egermann at limanews.com (Eric Germann) Date: Thu, 27 Oct 2011 20:42:59 -0700 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC8D0F094E9F0@VA3DIAXVS091.RED001.local> There are some fairly interesting photos of the Verizon CO that took a hit on 9/11 at http://www.slideshare.net/datacenters/verizon-contingency-planning-for-coop I recall far back in my memory some posts on this from a decade ago that pointed to some websites that had more photos. Was kind of surreal to see switch gear and open air in the same photo. EKG -----Original Message----- From: Drew Linsalata [mailto:drew.linsalata at gmail.com] Sent: Thursday, October 27, 2011 5:41 PM To: Mike Cc: nanog at nanog.org Subject: Re: Need photographs of IT/Telecom gear/rooms I did this at career day last spring for my daughter's fifth grade class. They were a bit young to get too deep into the nitty gritty, but they completely ate up the presentation and it was really gratifying to get notes and emails (all voluntarily sent) from some of the kids talking about how much they learned. All the kids love the Internet and using computers and other related gadgets, so I was a total hit. I'm sure you will be too. Enjoy the experience. On Thu, Oct 27, 2011 at 3:30 PM, Mike wrote: Greetings, > > I have been given the opportunity to teach the mechanics of the > Internet to a group of 6 - 12'th grade students, ..... > > > From bill at herrin.us Thu Oct 27 22:44:16 2011 From: bill at herrin.us (William Herrin) Date: Thu, 27 Oct 2011 23:44:16 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EAA056E.5010006@altadena.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> Message-ID: On Thu, Oct 27, 2011 at 9:29 PM, Pete Carah wrote: > On 10/27/2011 05:38 PM, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said: >>> So... I'm in complete agreement with your statement, but The Wikipedia > reference is not pertinent. > > For our purpose, the ownership of the commons in question truly isn't > relevant; Pete, For our purpose, describing the Internet as a commons fundamentally misunderstands its nature. A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government. For example, I own a 3/11,000ths share of a private road network. Those roads are a commons. The Internet is not jointly owned. You do not own a one seven billionth share of the network in my basement and I do not a own one seven billionth of yours. Rather, the Internet is a cooperative effort of the sole owners of its distinct individual pieces. As the owner of the network in my basement, it is my privilege alone to decide how you may and may not use it. The same goes for the respective owners of every other piece of the Internet. Nor is the data transiting these networks a commons. The air over my land is a commons. I don't control it. If I pollute it or if I don't, it promptly travels over someone else's land. According to intellectual property law, the data transiting the Internet is owned by its originator. That ownership does not change as the packets move between my network and yours. The point is, at every step with the Internet there is always a specific owner whose property is either being used with his permission or abused against his wishes. At no point is it a commons. You must understand the Internet's nature before you can properly consider my responsibility for the instructions passed from or through my network which direct the action of computers in yours. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ross.annetts at digitalpacific.com.au Thu Oct 27 22:49:07 2011 From: ross.annetts at digitalpacific.com.au (Ross Annetts) Date: Fri, 28 Oct 2011 14:49:07 +1100 Subject: Update Bogon Lists Message-ID: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> Hi, We have been allocated the IP range: 101.0.64.0/18 And have had issues with 2 networks in regards to bogon filtering. It would be appreciated if everyone can remove it from their bogon lists. Regards, Ross Annetts Systems Administrator Digital Pacific http://www.digitalpacific.com.au - ph: 1300 694 678 From morrowc.lists at gmail.com Thu Oct 27 22:52:57 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Oct 2011 23:52:57 -0400 Subject: Update Bogon Lists In-Reply-To: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> References: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> Message-ID: On Thu, Oct 27, 2011 at 11:49 PM, Ross Annetts wrote: > Hi, > > > > We have been allocated the IP range: > > > > 101.0.64.0/18 > (soon-to-be-released rfc about same) > > > And have had issues with 2 networks in regards to bogon filtering. It would > be appreciated if everyone can remove it from their bogon lists. > > > > Regards, > > Ross Annetts > Systems Administrator > Digital Pacific > http://www.digitalpacific.com.au - ph: 1300 694 678 > > From dhc2 at dcrocker.net Thu Oct 27 22:59:32 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 28 Oct 2011 05:59:32 +0200 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> Message-ID: <4EAA28A4.6010605@dcrocker.net> On 10/28/2011 5:44 AM, William Herrin wrote: > A commons is jointly owned, either by a non-trivial number of private > owners or by all citizens of a government. The practical use of the term is a bit broader: As rule, the term gets applied to situations of fate-sharing when actions by some affect utility for many. You cited air pollution. The Internet can suffer comparable effects. Spam can reasonably be called pollution and it has a systemic effect on all users. For such an issue, it's reasonable and even helpful to view it as a commons. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From daniel.unam.ipv6 at gmail.com Thu Oct 27 23:22:37 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Thu, 27 Oct 2011 23:22:37 -0500 Subject: Mexico? In-Reply-To: References: Message-ID: <4EAA2E0D.8000603@gmail.com> Hi Ryan...well, a late response, but actually you should take a look in the www.lacnic.net (Latin-america's RIR) and www.nic.mx (Network Information Center of Mexico) webpages and contact someone there to get all the information you need in order to obtain a IP addresses block. Regards ---- > If I want to get a block of IP's issued for a network within Mexico who do I > talk with? I have been told arin does not cover Mexico. It was my > understand arin covers North America. ---- -- Daniel Espejel P?rez T?cnico Acad?mico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M. From bill at herrin.us Thu Oct 27 23:26:02 2011 From: bill at herrin.us (William Herrin) Date: Fri, 28 Oct 2011 00:26:02 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EAA28A4.6010605@dcrocker.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> Message-ID: On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER wrote: > On 10/28/2011 5:44 AM, William Herrin wrote: >> A commons is jointly owned, either by a non-trivial number of private >> owners or by all citizens of a government. > > The practical use of the term is a bit broader: > ? > > As rule, the term gets applied to situations of fate-sharing when actions by > some affect utility for many. > > You cited air pollution. ?The Internet can suffer comparable effects. > > Spam can reasonably be called pollution and it has a systemic effect on all > users. ?For such an issue, it's reasonable and even helpful to view it as a > commons. Dave, I respectfully disagree. If you throw pollution into the air, it may eventually impact me or it may blow somewhere else. Mostly it'll blow somewhere else. But as lots of people throw pollution into the air, some non-trivial portion of that pollution will drift over me. This is the so-called tragedy. By contrast, if you send me spam email, you are directly abusing my computer. The linkage is not at all amorphous. You send to me. I receive from you. There is no "all world" or "local area" destination. If you send without some specific pointer in my direction, I won't receive it. Ever. Imagining spam as a tragedy of the commons disguises its true nature as a massive quantity of one-on-one abuses of individual owners' computers. Worse, it forgives the owners of the intermediate networks for shrugging their shoulders and turning a blind eye to the abusers. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Fri Oct 28 00:34:51 2011 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 27 Oct 2011 22:34:51 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> Message-ID: <4EAA3EFB.1050904@bogus.com> Email as facility is a public good whether it constitutes a commons or not... If wasn't you wouldn't bother putting up a server that would accept unsolicited incoming connections on behalf of yourself and others, doing so is generically non-rival and non-excludable although not perfectly so in either case (what public good is). On 10/27/11 21:26 , William Herrin wrote: > On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER wrote: >> On 10/28/2011 5:44 AM, William Herrin wrote: >>> A commons is jointly owned, either by a non-trivial number of private >>> owners or by all citizens of a government. >> >> The practical use of the term is a bit broader: >> >> >> As rule, the term gets applied to situations of fate-sharing when actions by >> some affect utility for many. >> >> You cited air pollution. The Internet can suffer comparable effects. >> >> Spam can reasonably be called pollution and it has a systemic effect on all >> users. For such an issue, it's reasonable and even helpful to view it as a >> commons. > > Dave, > > I respectfully disagree. > > If you throw pollution into the air, it may eventually impact me or it > may blow somewhere else. Mostly it'll blow somewhere else. But as lots > of people throw pollution into the air, some non-trivial portion of > that pollution will drift over me. This is the so-called tragedy. > > By contrast, if you send me spam email, you are directly abusing my > computer. The linkage is not at all amorphous. You send to me. I > receive from you. There is no "all world" or "local area" destination. > If you send without some specific pointer in my direction, I won't > receive it. Ever. > > Imagining spam as a tragedy of the commons disguises its true nature > as a massive quantity of one-on-one abuses of individual owners' > computers. Worse, it forgives the owners of the intermediate networks > for shrugging their shoulders and turning a blind eye to the abusers. > > Regards, > Bill Herrin > From Gabriel.McCall at thyssenkrupp.com Fri Oct 28 07:54:37 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Fri, 28 Oct 2011 08:54:37 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EAA056E.5010006@altadena.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> Message-ID: The alternative to centralization is enclosure: segmentation and private ownership of portions of the formerly common resource. Since the internet is already thus enclosed, with each portion completely owned by one autonomous agent or another, the problem at hand is not a commons problem at all but merely one of negotiation and market force. Internet Death Penalties, blacklists, and unilateral de-peering and blackholing are exactly the sorts of responses an economist would expect to see to a rogue actor in the network community, precise analogs of various types of economic ostracism going back to the merchant consortia of the middle ages. -Gabriel -----Original Message----- From: Pete Carah [mailto:pete at altadena.net] Sent: Thursday, October 27, 2011 9:29 PM To: nanog at nanog.org Subject: Re: Outgoing SMTP Servers Maybe he is concerned that the Wikipedia article gets into nit-picking about the ownership of the commons that isn't relevant to our problem, and also is rather long-winded. Hardin got into some things at the end of his paper that probably aren't either (but then, he was a population biologist and not an economist). BTW - that paper is a good read and not too long. The journal link (reference 1 in the wikipedia article) actually works openly (AAAS only blocks full access for a while...) For our purpose, the ownership of the commons in question truly isn't relevant; the fundamental statement of the tragedy for us is that a "useful" resource that is incrementally free (or even cheap enough) to a large number of participants will get exploited and probably overused. I'm not aware of any solution to this problem with commons that doesn't involve a central authority :-( In feudal practice the landlord could do some enforcement; the spanish alcaldes were another good example of a semi-central solution to the commons problem (water rights in their origins, though their authority grew over time). Classic economics says that market pricing is the solution, but that tends to result in another kind of tragedy. -- Pete On 10/27/2011 05:38 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said: >> So... I'm in complete agreement with your statement, but The >> Wikipedia reference is not pertinent. > > So I point out the tragedy of the commons, you agree with it, but the Wikipedia > reference that talks about the same exact thing isn't pertinent? How does that > follow? :) From Valdis.Kletnieks at vt.edu Fri Oct 28 10:41:55 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Oct 2011 11:41:55 -0400 Subject: Outgoing SMTP Servers In-Reply-To: Your message of "Thu, 27 Oct 2011 23:44:16 EDT." References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> Message-ID: <62968.1319816515@turing-police.cc.vt.edu> On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said: > For our purpose, describing the Internet as a commons fundamentally > misunderstands its nature. You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it. > The Internet is not jointly owned. You do not own a one seven > billionth share of the network in my basement and I do not a own one > seven billionth of yours. Rather, the Internet is a cooperative effort > of the sole owners of its distinct individual pieces. That's correct, as far as it goes. However, what *is* a commons is the *value* of the cooperative effort - see Metcalf's Law. You turn off or disconnect your share of the Internet, my share of the *value* of the Internet drops slightly. > Nor is the data transiting these networks a commons. The air over my > land is a commons. I don't control it. If I pollute it or if I don't, > it promptly travels over someone else's land. If you choose to pollute the air heavily, the value of the air drops for everybody. If you choose to pollute the Net heavily, the value of the Net drops for everybody. > The point is, at every step with the Internet there is always a > specific owner whose property is either being used with his permission > or abused against his wishes. At no point is it a commons. Try working the same example but using a stream flowing across your property instead, that feeds into the reservior the municipal water supply draws from. Yes, you own your section of the stream, and the guy next door owns his section, and so on. So the stream is not a commons - but the quality of the water in it *is*. (Yes, weak analogy, the downstream people have no say in it. Pretend for the sake of argument that everybody involved lives next to a stream that feeds the reservior that everybody drinks from - that's actually a pretty good match to the Internet topology). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bjohnson at drtel.com Fri Oct 28 11:37:10 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 28 Oct 2011 16:37:10 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <62968.1319816515@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> Message-ID: Comments in-line >-----Original Message----- >From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >Sent: Friday, October 28, 2011 10:42 AM >To: William Herrin >Cc: nanog at nanog.org; Pete Carah >Subject: Re: Outgoing SMTP Servers > >On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said: > >> For our purpose, describing the Internet as a commons fundamentally >> misunderstands its nature. > >You *do* realize that for all your nice "Thei Internet Is Not A Commons" >ranting, the basic problem is that some people (we'll call them spammers) >*do* >think that (a) it's a commons (or at least the exact ownership of a given >chunk is irrelevant), and (b) they're allowed to graze their sheep upon it. So we should treat the Internet with respect to bad actors differently than others. STRIKE 1! > >> The Internet is not jointly owned. You do not own a one seven >> billionth share of the network in my basement and I do not a own one >> seven billionth of yours. Rather, the Internet is a cooperative effort >> of the sole owners of its distinct individual pieces. > >That's correct, as far as it goes. However, what *is* a commons is the *value* >of the cooperative effort - see Metcalf's Law. You turn off or disconnect your >share of the Internet, my share of the *value* of the Internet drops slightly. > So bad actors destroying the value created by a cooperative of good actors is not bad? STRIKE 2! >> Nor is the data transiting these networks a commons. The air over my >> land is a commons. I don't control it. If I pollute it or if I don't, >> it promptly travels over someone else's land. > >If you choose to pollute the air heavily, the value of the air drops for >everybody. >If you choose to pollute the Net heavily, the value of the Net drops for >everybody. > STRIKE 3! Oops got ahead of myself. I'm attempting to prevent the pollution but I may capture a little good water (almost nothing) along the way. To say that this is a way of "bad acting" and causes a loss of value to the Internet as a whole is pure folly. >> The point is, at every step with the Internet there is always a >> specific owner whose property is either being used with his permission >> or abused against his wishes. At no point is it a commons. > >Try working the same example but using a stream flowing across your >property >instead, that feeds into the reservior the municipal water supply draws from. >Yes, you own your section of the stream, and the guy next door owns his >section, and so on. So the stream is not a commons - but the quality of the >water in it *is*. (Yes, weak analogy, the downstream people have no say in it. >Pretend for the sake of argument that everybody involved lives next to a >stream >that feeds the reservior that everybody drinks from - that's actually a pretty >good match to the Internet topology). Actually if there were 4 strikes... STRIKE 4! Since I only transit destination packets, this analogy does not apply in any significant way. In fact this would only apply to transit providers filtering between peers or other transit connections. In my experience this is used at the customer connection to the transit or peering connection to protect the Internet from the clueless or compromised. - Brian BTW... what a great game last night! :) From bjohnson at drtel.com Fri Oct 28 13:16:31 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 28 Oct 2011 18:16:31 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> Message-ID: Owen, When you stretch an analogy this thin, it always falls apart. I was referring to the poison/pollution not the water/air. A drought/vacuum* would not be possible, but would you want the poisoned water/air? This analogy is bad enough without the nits picked out. I actually mixed two posts to create a stream analogy out of an air analogy. I will not go any further and all further follows on to this analogy should be ignored. :) - Brian J. * a lack of air (for a reasonable deffinition of air) would be a vacuum... right? >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Friday, October 28, 2011 12:11 PM >To: Brian Johnson >Subject: Re: Outgoing SMTP Servers > >> >>>> Nor is the data transiting these networks a commons. The air over my >>>> land is a commons. I don't control it. If I pollute it or if I don't, >>>> it promptly travels over someone else's land. >>> >>> If you choose to pollute the air heavily, the value of the air drops for >>> everybody. >>> If you choose to pollute the Net heavily, the value of the Net drops for >>> everybody. >>> >> >> STRIKE 3! Oops got ahead of myself. >> >> I'm attempting to prevent the pollution but I may capture a little good water >(almost nothing) along the way. To say that this is a way of "bad acting" and >causes a loss of value to the Internet as a whole is pure folly. >> > >No, it really isn't. Because the good water that you are catching is actually >causing >a drought downstream. > >Owen From dougb at dougbarton.us Fri Oct 28 13:21:55 2011 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 28 Oct 2011 11:21:55 -0700 Subject: Update Bogon Lists In-Reply-To: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> References: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> Message-ID: <4EAAF2C3.7090105@dougbarton.us> On 10/27/2011 20:49, Ross Annetts wrote: > Hi, > > > > We have been allocated the IP range: > > > > 101.0.64.0/18 > > > > And have had issues with 2 networks in regards to bogon filtering. It would > be appreciated if everyone can remove it from their bogon lists. Well no one else has said it yet, so ... The usual procedure when making requests of this nature has been to stand up an IP address in that range that people can ping to test if their own networks are working properly. Hopefully that will help you get this cleared up faster. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From bill at herrin.us Fri Oct 28 13:59:31 2011 From: bill at herrin.us (William Herrin) Date: Fri, 28 Oct 2011 14:59:31 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EAA3EFB.1050904@bogus.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EAA3EFB.1050904@bogus.com> Message-ID: On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli wrote: > Email as facility is a public good whether it constitutes a commons or > not... If wasn't you wouldn't bother putting up a server that would > accept unsolicited incoming connections on behalf of yourself and > others, doing so is generically non-rival and non-excludable although > not perfectly so in either case (what public good is). Interesting. I want to abstract and restate what I think you just said and ask you to correct my understanding: Making a service accessible to the public via the Internet implicitly grants some basic permission to that public to make use of the service, permission which can not be revoked solely by saying so. If that's the case, what is the common denominator? What is the standard of permission automatically granted by placing an email server on the internet, from which a particular operator may grant more permission but may not reasonably grant less? Put another way, what's the whitelist of activities for which we generally expect our vendor to ignore complaints, what's the blacklist of activities for which a vendor who fails to adequately redress complaints is misbehaving and what's left in the gray zone where behavior might be abusive but is not automatically so? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bhmccie at gmail.com Fri Oct 28 13:59:16 2011 From: bhmccie at gmail.com (-Hammer-) Date: Fri, 28 Oct 2011 13:59:16 -0500 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EAA3EFB.1050904@bogus.com> Message-ID: <4EAAFB84.80306@gmail.com> Girls, You are all pretty. End the thread. Seriously. -Hammer- "I was a normal American nerd" -Jack Herer On 10/28/2011 01:59 PM, William Herrin wrote: > On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli wrote: > >> Email as facility is a public good whether it constitutes a commons or >> not... If wasn't you wouldn't bother putting up a server that would >> accept unsolicited incoming connections on behalf of yourself and >> others, doing so is generically non-rival and non-excludable although >> not perfectly so in either case (what public good is). >> > Interesting. I want to abstract and restate what I think you just said > and ask you to correct my understanding: > > Making a service accessible to the public via the Internet implicitly > grants some basic permission to that public to make use of the > service, permission which can not be revoked solely by saying so. > > > If that's the case, what is the common denominator? What is the > standard of permission automatically granted by placing an email > server on the internet, from which a particular operator may grant > more permission but may not reasonably grant less? Put another way, > what's the whitelist of activities for which we generally expect our > vendor to ignore complaints, what's the blacklist of activities for > which a vendor who fails to adequately redress complaints is > misbehaving and what's left in the gray zone where behavior might be > abusive but is not automatically so? > > Regards, > Bill Herrin > > > From bill at herrin.us Fri Oct 28 14:05:17 2011 From: bill at herrin.us (William Herrin) Date: Fri, 28 Oct 2011 15:05:17 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <62968.1319816515@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> Message-ID: On Fri, Oct 28, 2011 at 11:41 AM, wrote: > On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said: >> For our purpose, describing the Internet as a commons fundamentally >> misunderstands its nature. > > You *do* realize that for all your nice "Thei Internet Is Not A Commons" > ranting, the basic problem is that some people (we'll call them spammers) *do* > think that (a) it's a commons (or at least the exact ownership of a given > chunk is irrelevant), and (b) they're allowed to graze their sheep upon it. Squatters, trespassers and thieves always manage to find self-serving justifications for their behavior. The theory that it's OK to take from the faceless owner is not a new one, nor is it particularly related to the concept of a commons. >> The point is, at every step with the Internet there is always a >> specific owner whose property is either being used with his permission >> or abused against his wishes. At no point is it a commons. > > Try working the same example but using a stream flowing across your property > instead, that feeds into the reservior the municipal water supply draws from. > Yes, you own your section of the stream, and the guy next door owns his > section, and so on. ?So the stream is not a commons - but the quality of the > water in it *is*. You've picked an interesting analogy for the flow of data on the Internet. If I dam up the stream on my side inducing my upstream neighbor's property to flood, I can be sued and I *will* lose the lawsuit. My action has willfully and directly damaged his property. Same if I divert all the water and dry out my downstream neighbor's lake. In more populous areas this sort of issue becomes sufficiently contentious that the government simply takes the stream, defining it as a "stormwater easement" and at that point, a regulated commons. My house is sandwiched between a stormwater easement under the back yard and a sanitary sewer easement under the front. I know far more about the legal issues around moving water than I ever wanted to. Like the fact that an areaway drain built in the 50's was typically attached to the sanitary sewer in full compliance with the building code, but the current building code forbids it and a judge will throw the book at you even though post-ex-facto normally applies to old construction. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mikejones.in Fri Oct 28 14:06:53 2011 From: mike at mikejones.in (Mike Jones) Date: Fri, 28 Oct 2011 20:06:53 +0100 Subject: Outgoing SMTP Servers In-Reply-To: <62968.1319816515@turing-police.cc.vt.edu> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> Message-ID: On 28 October 2011 16:41, wrote: > You *do* realize that for all your nice "Thei Internet Is Not A Commons" > ranting, the basic problem is that some people (we'll call them spammers) *do* > think that (a) it's a commons (or at least the exact ownership of a given > chunk is irrelevant), and (b) they're allowed to graze their sheep upon it. If someone keeps putting their animals in my garden then some countries would permit me to shoot them and sue the owner for the cost of the bullets. Even those with more restrictive property rights laws would still permit me to throw them off of my land and sue the owner for any damage they caused me. On the Internet when people start shooting their sheep they think they are the victims and go to the dutch police, sorry i mean the police of whichever jurisdiction the hypothetical entity is from, complaining that they are being deprived of their right to abuse peoples gardens. - Mike From wschultz at bsdboy.com Fri Oct 28 14:08:56 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Fri, 28 Oct 2011 12:08:56 -0700 Subject: Could a Comcast DNS admin please contact me offlist? Message-ID: Apologies for the off-topic chatter... -wil From cscora at apnic.net Fri Oct 28 14:17:17 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Oct 2011 05:17:17 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201110281917.p9SJHHK0006931@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Oct, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 379556 Prefixes after maximum aggregation: 166311 Deaggregation factor: 2.28 Unique aggregates announced to Internet: 186116 Total ASes present in the Internet Routing Table: 39180 Prefixes per ASN: 9.69 Origin-only ASes present in the Internet Routing Table: 32352 Origin ASes announcing only one prefix: 15498 Transit ASes present in the Internet Routing Table: 5266 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1580 Unregistered ASNs in the Routing Table: 843 Number of 32-bit ASNs allocated by the RIRs: 1911 Number of 32-bit ASNs visible in the Routing Table: 1562 Prefixes from 32-bit ASNs in the Routing Table: 3627 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 95 Number of addresses announced to Internet: 2489057440 Equivalent to 148 /8s, 92 /16s and 0 /24s Percentage of available address space announced: 67.2 Percentage of allocated address space announced: 67.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.5 Total number of prefixes smaller than registry allocations: 159572 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 94855 Total APNIC prefixes after maximum aggregation: 30982 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 91300 Unique aggregates announced from the APNIC address blocks: 38074 APNIC Region origin ASes present in the Internet Routing Table: 4590 APNIC Prefixes per ASN: 19.89 APNIC Region origin ASes announcing only one prefix: 1266 APNIC Region transit ASes present in the Internet Routing Table: 721 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 21 Number of APNIC region 32-bit ASNs visible in the Routing Table: 98 Number of APNIC addresses announced to Internet: 629428896 Equivalent to 37 /8s, 132 /16s and 82 /24s Percentage of available APNIC address space announced: 79.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 145811 Total ARIN prefixes after maximum aggregation: 74492 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 117702 Unique aggregates announced from the ARIN address blocks: 48191 ARIN Region origin ASes present in the Internet Routing Table: 14743 ARIN Prefixes per ASN: 7.98 ARIN Region origin ASes announcing only one prefix: 5663 ARIN Region transit ASes present in the Internet Routing Table: 1558 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 804671488 Equivalent to 47 /8s, 246 /16s and 80 /24s Percentage of available ARIN address space announced: 63.9 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 91098 Total RIPE prefixes after maximum aggregation: 50841 RIPE Deaggregation factor: 1.79 Prefixes being announced from the RIPE address blocks: 83738 Unique aggregates announced from the RIPE address blocks: 54302 RIPE Region origin ASes present in the Internet Routing Table: 16072 RIPE Prefixes per ASN: 5.21 RIPE Region origin ASes announcing only one prefix: 7969 RIPE Region transit ASes present in the Internet Routing Table: 2528 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1092 Number of RIPE addresses announced to Internet: 491265472 Equivalent to 29 /8s, 72 /16s and 29 /24s Percentage of available RIPE address space announced: 79.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 35470 Total LACNIC prefixes after maximum aggregation: 7898 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 34922 Unique aggregates announced from the LACNIC address blocks: 18132 LACNIC Region origin ASes present in the Internet Routing Table: 1540 LACNIC Prefixes per ASN: 22.68 LACNIC Region origin ASes announcing only one prefix: 442 LACNIC Region transit ASes present in the Internet Routing Table: 283 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 356 Number of LACNIC addresses announced to Internet: 92626368 Equivalent to 5 /8s, 133 /16s and 93 /24s Percentage of available LACNIC address space announced: 61.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8526 Total AfriNIC prefixes after maximum aggregation: 2021 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 6631 Unique aggregates announced from the AfriNIC address blocks: 1988 AfriNIC Region origin ASes present in the Internet Routing Table: 495 AfriNIC Prefixes per ASN: 13.40 AfriNIC Region origin ASes announcing only one prefix: 158 AfriNIC Region transit ASes present in the Internet Routing Table: 107 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 27830528 Equivalent to 1 /8s, 168 /16s and 169 /24s Percentage of available AfriNIC address space announced: 41.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2507 11096 967 Korea Telecom (KIX) 17974 1884 519 33 PT TELEKOMUNIKASI INDONESIA 7545 1611 303 84 TPG Internet Pty Ltd 4755 1539 637 174 TATA Communications formerly 7552 1393 1064 8 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1091 80 499 Sify Limited 4808 1090 2103 312 CNCGROUP IP network: China169 24560 964 342 218 Bharti Airtel Ltd., Telemedia 18101 953 166 150 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3544 3814 220 bellsouth.net, inc. 7029 2329 1016 197 Windstream Communications Inc 18566 2097 383 177 Covad Communications 1785 1841 680 122 PaeTec Communications, Inc. 4323 1623 1078 388 Time Warner Telecom 20115 1595 1546 620 Charter Communications 22773 1458 2907 100 Cox Communications, Inc. 19262 1395 4728 400 Verizon Global Networks 30036 1393 253 671 Mediacom Communications Corp 7018 1317 7029 861 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1500 352 13 Corbina telecom 6830 653 1927 415 UPC Distribution Services 34984 590 108 180 BILISIM TELEKOM 20940 547 182 422 Akamai Technologies European 3320 506 8169 386 Deutsche Telekom AG 12479 479 596 9 Uni2 Autonomous System 3292 478 2074 405 TDC Tele Danmark 8866 461 133 26 Bulgarian Telecommunication C 8551 403 354 44 Bezeq International 31148 401 21 111 FreeNet ISP Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1699 314 156 TVCABLE BOGOTA 28573 1473 1040 72 NET Servicos de Comunicao S.A 8151 1417 2927 348 UniNet S.A. de C.V. 7303 1231 748 177 Telecom Argentina Stet-France 27947 588 72 83 Telconet S.A 22047 580 322 17 VTR PUNTO NET S.A. 6503 572 450 69 AVANTEL, S.A. 7738 552 1050 31 Telecomunicacoes da Bahia S.A 3816 538 233 95 Empresa Nacional de Telecomun 11172 525 86 96 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 802 146 36 LINKdotNET AS number 8452 651 446 12 TEDATA 15475 444 74 8 Nile Online 36992 299 415 20 Etisalat MISR 3741 280 939 229 The Internet Solution 6713 244 519 14 Itissalat Al-MAGHRIB 15706 240 32 6 Sudatel Internet Exchange Aut 33776 221 13 8 Starcomms Nigeria Limited 29571 219 18 14 Ci Telecom Autonomous system 12258 196 28 57 Vodacom Internet Company Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3544 3814 220 bellsouth.net, inc. 4766 2507 11096 967 Korea Telecom (KIX) 7029 2329 1016 197 Windstream Communications Inc 18566 2097 383 177 Covad Communications 17974 1884 519 33 PT TELEKOMUNIKASI INDONESIA 1785 1841 680 122 PaeTec Communications, Inc. 10620 1699 314 156 TVCABLE BOGOTA 4323 1623 1078 388 Time Warner Telecom 7545 1611 303 84 TPG Internet Pty Ltd 20115 1595 1546 620 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 2329 2132 Windstream Communications Inc 18566 2097 1920 Covad Communications 17974 1884 1851 PT TELEKOMUNIKASI INDONESIA 1785 1841 1719 PaeTec Communications, Inc. 10620 1699 1543 TVCABLE BOGOTA 4766 2507 1540 Korea Telecom (KIX) 7545 1611 1527 TPG Internet Pty Ltd 8402 1500 1487 Corbina telecom 28573 1473 1401 NET Servicos de Comunicao S.A 7552 1393 1385 Vietel Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.79.132.0/23 30969 Zimbabwe OnLine (Private) Ltd 41.79.132.0/22 30969 Zimbabwe OnLine (Private) Ltd 41.79.134.0/23 30969 Zimbabwe OnLine (Private) Ltd 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.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:19 /9:12 /10:27 /11:81 /12:236 /13:465 /14:809 /15:1427 /16:12024 /17:6073 /18:10088 /19:19938 /20:27559 /21:27543 /22:37225 /23:35231 /24:197353 /25:1167 /26:1351 /27:757 /28:162 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2184 3544 bellsouth.net, inc. 18566 2046 2097 Covad Communications 7029 1999 2329 Windstream Communications Inc 10620 1594 1699 TVCABLE BOGOTA 8402 1476 1500 Corbina telecom 30036 1354 1393 Mediacom Communications Corp 11492 1118 1156 Cable One 1785 1056 1841 PaeTec Communications, Inc. 7011 1050 1168 Citizens Utilities 22773 946 1458 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:411 2:490 4:15 5:1 6:3 8:361 12:1954 13:1 14:544 15:11 16:3 17:7 20:9 23:60 24:1683 27:972 31:626 32:61 33:2 34:2 36:4 38:757 40:110 41:2664 42:53 44:3 46:1007 47:3 49:291 50:438 52:13 55:6 56:2 57:40 58:884 59:494 60:363 61:1174 62:1087 63:1950 64:4058 65:2305 66:4275 67:1982 68:1154 69:3202 70:883 71:382 72:1805 74:2604 75:393 76:318 77:879 78:868 79:452 80:1134 81:838 82:502 83:527 84:619 85:1122 86:403 87:890 88:353 89:1607 90:237 91:4242 92:530 93:1532 94:1302 95:1077 96:434 97:284 98:928 99:37 101:220 103:413 106:70 107:78 108:72 109:1055 110:665 111:795 112:334 113:487 114:617 115:710 116:880 117:721 118:901 119:1262 120:339 121:693 122:1566 123:1016 124:1354 125:1361 128:243 129:185 130:164 131:626 132:146 133:21 134:220 135:54 136:213 137:140 138:286 139:123 140:489 141:309 142:389 143:419 144:495 145:63 146:461 147:216 148:642 149:267 150:167 151:194 152:447 153:178 154:7 155:389 156:208 157:358 158:154 159:484 160:331 161:214 162:341 163:173 164:511 165:370 166:539 167:435 168:742 169:146 170:873 171:86 172:4 173:1718 174:673 175:423 176:282 177:356 178:1079 180:1121 181:36 182:653 183:220 184:379 185:1 186:1301 187:707 188:949 189:867 190:5144 192:5933 193:5037 194:3560 195:3115 196:1230 197:164 198:3627 199:4166 200:5519 201:1687 202:8572 203:8480 204:4306 205:2363 206:2674 207:2824 208:4027 209:3575 210:2713 211:1459 212:2086 213:1777 214:796 215:96 216:4924 217:1602 218:563 219:342 220:1250 221:515 222:343 223:271 End of report From jra at baylink.com Fri Oct 28 14:33:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Oct 2011 15:33:51 -0400 (EDT) Subject: Outgoing SMTP Servers In-Reply-To: Message-ID: <24203829.448.1319830431619.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > Interesting. I want to abstract and restate what I think you just said > and ask you to correct my understanding: > > Making a service accessible to the public via the Internet implicitly > grants some basic permission to that public to make use of the > service, permission which can not be revoked solely by saying so. That's correct; did you think it wasn't? The offer is *in the presence of a standard service on a standard port*; if I put a SMTP receiver on tcp/25, you are, yes, implicitly permitted to try to use it to send me email. There *is no place* to put "saying permission is revoked", so where would someone look, even if their daemon wanted to look. > If that's the case, what is the common denominator? What is the > standard of permission automatically granted by placing an email > server on the internet, from which a particular operator may grant > more permission but may not reasonably grant less? Put another way, > what's the whitelist of activities for which we generally expect our > vendor to ignore complaints, what's the blacklist of activities for > which a vendor who fails to adequately redress complaints is > misbehaving and what's left in the gray zone where behavior might be > abusive but is not automatically so? If there are specific things you want people not to do, *make it impossible for them to do those things* (ssh authentication, for example). Above that, I suppose that rate limiting failures is expected of a connecting client... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Fri Oct 28 14:54:10 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Oct 2011 13:54:10 -0600 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> Message-ID: <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> Sent from my iPhone On Oct 28, 2011, at 12:16, Brian Johnson wrote: > Owen, > > When you stretch an analogy this thin, it always falls apart. I was referring to the poison/pollution not the water/air. A drought/vacuum* would not be possible, but would you want the poisoned water/air? > I can tolerate a lot of spam if my legitimate messages get through. I have zero tolerance for blocking my legitimate traffic in the name of stopping pollution. I oppose the death penalty on the same basis. Owen > This analogy is bad enough without the nits picked out. I actually mixed two posts to create a stream analogy out of an air analogy. > > I will not go any further and all further follows on to this analogy should be ignored. :) > > - Brian J. > > * a lack of air (for a reasonable deffinition of air) would be a vacuum... right? > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Friday, October 28, 2011 12:11 PM >> To: Brian Johnson >> Subject: Re: Outgoing SMTP Servers >> >>> >>>>> Nor is the data transiting these networks a commons. The air over my >>>>> land is a commons. I don't control it. If I pollute it or if I don't, >>>>> it promptly travels over someone else's land. >>>> >>>> If you choose to pollute the air heavily, the value of the air drops for >>>> everybody. >>>> If you choose to pollute the Net heavily, the value of the Net drops for >>>> everybody. >>>> >>> >>> STRIKE 3! Oops got ahead of myself. >>> >>> I'm attempting to prevent the pollution but I may capture a little good water >> (almost nothing) along the way. To say that this is a way of "bad acting" and >> causes a loss of value to the Internet as a whole is pure folly. >>> >> >> No, it really isn't. Because the good water that you are catching is actually >> causing >> a drought downstream. >> >> Owen > From stb at lassitu.de Fri Oct 28 16:27:31 2011 From: stb at lassitu.de (Stefan Bethke) Date: Fri, 28 Oct 2011 23:27:31 +0200 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: <4EA9B172.5000202@tiedyenetworks.com> References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: <098202E0-95A8-4FBC-BE5B-615400A10610@lassitu.de> Am 27.10.2011 um 21:30 schrieb Mike: > Greetings, > > I have been given the opportunity to teach the mechanics of the Internet to a group of 6 - 12'th grade students, and as an engineer and owner of an ISP I have it in mind to really get into this and show these kids how, really, all this stuff works and to make it fun and exciting. There's a German TV program (Die Sendung mit der Maus - the program with the mouse) that has been doing "how stuff works" kind of segments for a long time, and they did one on "the Internet" some ten years back. A version with English subtitles is here: http://www.youtube.com/watch?v=vfXsdbnPjX4 While it is simplified, I find it surprisingly accurate despite the reenactment. Stefan -- Stefan Bethke Fon +49 151 14070811 From cidr-report at potaroo.net Fri Oct 28 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Oct 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201110282200.p9SM00GT097108@wattle.apnic.net> BGP Update Report Interval: 20-Oct-11 -to- 27-Oct-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3352 33466 2.0% 10.1 -- TELEFONICA-DATA-ESPANA TELEFONICA DE ESPANA 2 - AS38040 26517 1.6% 1894.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS9829 25985 1.6% 43.6 -- BSNL-NIB National Internet Backbone 4 - AS32528 23759 1.4% 3394.1 -- ABBOTT Abbot Labs 5 - AS5800 17561 1.1% 76.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS9498 15776 1.0% 19.4 -- BBIL-AP BHARTI Airtel Ltd. 7 - AS8866 13108 0.8% 28.4 -- BTC-AS Bulgarian Telecommunication Company Plc. 8 - AS29049 12263 0.7% 29.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 9 - AS16916 12018 0.7% 572.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 10 - AS53006 11094 0.7% 317.0 -- 11 - AS8402 10874 0.7% 10.2 -- CORBINA-AS OJSC "Vimpelcom" 12 - AS9649 10855 0.7% 204.8 -- MOPH-TH-AP Information Technology Office 13 - AS16010 10336 0.6% 84.0 -- RUSTAVI2ONLINEAS Caucasus Online LLC 14 - AS9562 9804 0.6% 1400.6 -- MSU-TH-AP Mahasarakham University 15 - AS8452 9590 0.6% 16.1 -- TE-AS TE-AS 16 - AS7552 9277 0.6% 6.9 -- VIETEL-AS-AP Vietel Corporation 17 - AS17974 9170 0.6% 6.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS1785 9020 0.6% 5.0 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS6713 8809 0.5% 36.3 -- IAM-AS 20 - AS9772 8362 0.5% 245.9 -- SENS-AS-KR Seobu District Office of Education in Seoul TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 23759 1.4% 3394.1 -- ABBOTT Abbot Labs 2 - AS38040 26517 1.6% 1894.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 3 - AS9562 9804 0.6% 1400.6 -- MSU-TH-AP Mahasarakham University 4 - AS53718 1297 0.1% 1297.0 -- ECH-AS - Evangelical Community Hospital 5 - AS55696 949 0.1% 949.0 -- SCOM-AS-ID Starcom Solusindo PT. 6 - AS17425 4928 0.3% 821.3 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 7 - AS45723 807 0.1% 807.0 -- OMADATA-AS-ID Omadata Indonesia, PT 8 - AS11943 704 0.0% 704.0 -- GLOBE - Globe Wireless 9 - AS56902 617 0.0% 617.0 -- MCMMRF-AS Ministry of communications and mass media of RF 10 - AS56939 584 0.0% 584.0 -- CREDOS Credo-S Ltd. 11 - AS16916 12018 0.7% 572.3 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 12 - AS50733 461 0.0% 461.0 -- BINA-AS Ertebat Gostaran Bina 13 - AS20414 3064 0.2% 437.7 -- HWASN - Hunton & Williams LLP 14 - AS9128 394 0.0% 394.0 -- Alpha Bank SA 15 - AS56615 371 0.0% 371.0 -- BTT-AS Business Travel Turism SRL 16 - AS28616 360 0.0% 360.0 -- Prodabel - Empresa de Inform?tica e Informa??o do Munic?pio de BH 17 - AS28572 5586 0.3% 349.1 -- Apoiocom Digital Ltda 18 - AS28341 2738 0.2% 342.2 -- 19 - AS57090 1364 0.1% 341.0 -- SNSREAAL SNS REAAL N.V. 20 - AS21594 680 0.0% 340.0 -- IBSA - Interstate Battery System of America Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 13420 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 213.16.48.0/24 11944 0.7% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 3 - 130.36.34.0/24 11858 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 11858 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 206.80.93.0/24 11800 0.7% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 6 - 202.171.192.0/20 6421 0.4% AS4788 -- TMNET-AS-AP TM Net, Internet Service Provider 7 - 180.180.255.0/24 5559 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 8 - 180.180.248.0/24 5239 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 9 - 180.180.253.0/24 5237 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 10 - 180.180.250.0/24 5234 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 180.180.249.0/24 5230 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 12 - 202.153.174.0/24 3197 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 202.41.70.0/24 3028 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 14 - 202.151.7.0/24 2458 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 15 - 202.151.6.0/24 2454 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 16 - 110.164.27.0/24 2448 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 17 - 110.164.24.0/24 2446 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 18 - 110.164.25.0/24 2446 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 19 - 110.164.26.0/24 2446 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 20 - 217.52.130.0/24 2336 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Oct 28 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Oct 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201110282200.p9SM00Td097103@wattle.apnic.net> This report has been generated at Fri Oct 28 21:12:31 2011 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 21-10-11 384022 223846 22-10-11 382807 223804 23-10-11 382848 223957 24-10-11 382901 223498 25-10-11 384225 224349 26-10-11 383269 224291 27-10-11 383062 223840 28-10-11 381389 223711 AS Summary 39291 Number of ASes in routing system 16594 Number of ASes announcing only one prefix 3545 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108506112 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'). --- 28Oct11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 381634 223945 157689 41.3% All ASes AS6389 3545 223 3322 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2097 405 1692 80.7% COVAD - Covad Communications Co. AS4766 2507 986 1521 60.7% KIXS-AS-KR Korea Telecom AS22773 1458 110 1348 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1536 228 1308 85.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1624 390 1234 76.0% TWTC - tw telecom holdings, inc. AS28573 1473 385 1088 73.9% NET Servicos de Comunicao S.A. AS1785 1844 785 1059 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1699 697 1002 59.0% Telmex Colombia S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1393 431 962 69.1% VIETEL-AS-AP Vietel Corporation AS7303 1231 330 901 73.2% Telecom Argentina S.A. AS8402 1456 640 816 56.0% CORBINA-AS OJSC "Vimpelcom" AS18101 954 151 803 84.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7029 2372 1586 786 33.1% WINDSTREAM - Windstream Communications Inc AS4808 1090 344 746 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1420 679 741 52.2% Uninet S.A. de C.V. AS30036 1393 676 717 51.5% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1610 944 666 41.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1104 452 652 59.1% LEVEL3 Level 3 Communications AS17974 1867 1229 638 34.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3549 1055 442 613 58.1% GBLX Global Crossing Ltd. AS24560 964 354 610 63.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 678 70 608 89.7% GIGAINFRA Softbank BB Corp. AS4804 702 95 607 86.5% MPX-AS Microplex PTY LTD AS20115 1595 991 604 37.9% CHARTER-NET-HKY-NC - Charter Communications AS22561 934 371 563 60.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS7011 1168 645 523 44.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 889 382 507 57.0% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 43633 15454 28179 64.6% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.79.132.0/22 AS30969 ZOL-AS Zimbabwe OnLine (Private) Ltd. 41.79.132.0/23 AS30969 ZOL-AS Zimbabwe OnLine (Private) Ltd. 41.79.134.0/23 AS30969 ZOL-AS Zimbabwe OnLine (Private) Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 91.232.55.0/24 AS52223 UNITED-STUDIONET United Studios SRL 91.232.56.0/23 AS52223 UNITED-STUDIONET United Studios SRL 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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.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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From gih at apnic.net Fri Oct 28 17:35:51 2011 From: gih at apnic.net (Geoff Huston) Date: Sat, 29 Oct 2011 09:35:51 +1100 Subject: Weekly Routing Table Report In-Reply-To: <4E9EA043.4030701@gmail.com> References: <201110141921.p9EJLO5A028872@thyme.rand.apnic.net> <4E989063.9010201@kenweb.org> <41F6C547EA49EC46B4EE1EB2BC2F341837800EE835@EXVPMBX100-1.exc.icann.org> <4E9EA043.4030701@gmail.com> Message-ID: <4EB74E9E-531C-43D8-AE60-0846527B896E@apnic.net> On 19/10/2011, at 9:02 PM, Philip Smith wrote: > Hi Leo, > > Leo Vegoda said the following on 18/10/11 00:31 : >>> >>>> 128.0.87.0/24 30977 JSC "Yugra-Telecom" >> >> This one seems to be an error. 128.0.80/21 appears to have been allocated on 5 October, nine days before the report was generated. > > The report is as good as what is in the RIR allocation databases, as I > grab those from the RIR public listings about 2 hours before the report > is run. So if it was allocated, it wasn't listed in the file that I pick > up. I'll investigate why. > >> The report is not 100% accurate. Some of the resources listed do appear to be used without being registered but not all of them. > > It is as accurate as the data I have access to. ;-) But I'd be delighted > to hear suggestions for improvements. > You could try using http://bgp.potaroo.net/stats/nro/status.joint.txt I use this as the basis of the bogon listing on the CIDR Report and I don't seem to be pickling up these false positives. regards, Geoff From nonobvious at gmail.com Fri Oct 28 18:21:39 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 28 Oct 2011 16:21:39 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> Message-ID: There are several models for where the MTA lives in an ISP environment - MTA at customer, connects to destination via Port 25. - MUA at customer, MTA at ISP, connects to destination via Port 25. - MTA at customer, ISP transparently forces connection through ISP MTA, then connects to destination via 25 - MUA at customer, ISP, MTA at email service provider, connects to destination via port 25. The MUA-vs-MTA distinction and the MTA-at-ISP model are _historical_artifacts_, left over from the days of dial ISPs. - An MTA benefits from having a reliable full-time connection to the Internet, because it's going to deliver mail to a potentially unreliable destination and may need to keep trying repeatedly over a long time, while the MUA only needs to connect to the MTA long enough to pass the message. - It's also helpful for the MTA to be colocated with the sender's mailbox service, and the mailbox service and its domain names also benefit from fulltime connectivity. - While dial internet is almost dead, smartphones and wireless laptops are partially recreating the unreliably-connected computer system, but they usually use MTAs at an email service provider, not the ISP. - On the other hand, any desktop computer or laptop, most smartphones, and many wristwatches have far more computing horsepower and disk space than the VAX 11/780s that ran early sendmail systems, so they're perfectly capable of being first-class objects on the Internet and running MTAs. I've got a strong preference for ISPs to run a Block-25-by-default/Enable-when-asked. As a purist, I'd prefer to have Internet connections that are actually Internet connections, and if you want to run email on a Linux box at home or have an Arduino in your refrigerator email the grocery when you're out of milk, you should be able to, and if some meddling kid at an ISP wants to block it, they should get off your lawn. In practice, of course, somewhere between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs, they're zombie spambots on home PCs, or occasional driveby wifi spammers or other pests, and not only should outgoing mail be blocked, but the user should be notified and the connection should probably be put into some kind of quarantined access. But that's for Port 25 - the Port 25 blocking by ISPs has largely pushed Email Service Providers to use other protocols such as 587 for mail submission from an MUA to the MTA, or webmail instead, and it's really bad practice for ISPs to interfere with that. In some cases they'll still be sending spam, but that's the MTA's job to filter out, and if they don't, they'll end up on a bunch of RBLs. (And generally they'll be trying to keep their mail clean themselves - if the MTA providers were spammers, they wouldn't need to go to the trouble of having actual residential users as customers when they could mass-produce it cheaper directly.) From matt at mt.au.com Fri Oct 28 21:02:18 2011 From: matt at mt.au.com (Matt Taylor) Date: Sat, 29 Oct 2011 13:02:18 +1100 Subject: Update Bogon Lists In-Reply-To: <4EAAF2C3.7090105@dougbarton.us> References: <008601cc9524$8bdba250$a392e6f0$@digitalpacific.com.au> <4EAAF2C3.7090105@dougbarton.us> Message-ID: <4EAB5EAA.4050401@mt.au.com> On 29/10/2011 5:21 AM, Doug Barton wrote: > On 10/27/2011 20:49, Ross Annetts wrote: >> Hi, >> >> >> >> We have been allocated the IP range: >> >> >> >> 101.0.64.0/18 >> >> >> >> And have had issues with 2 networks in regards to bogon filtering. It would >> be appreciated if everyone can remove it from their bogon lists. > Well no one else has said it yet, so ... The usual procedure when making > requests of this nature has been to stand up an IP address in that range > that people can ping to test if their own networks are working properly. > Hopefully that will help you get this cleared up faster. > > > Doug > Try this IP: 101.0.127.1 Cheers, Matt. From bjohnson at drtel.com Fri Oct 28 23:27:59 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Sat, 29 Oct 2011 04:27:59 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> , <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> Message-ID: <3386E044-7C1D-4373-AC63-10F9967B4860@drtel.com> Sent from my iPad On Oct 28, 2011, at 2:56 PM, "Owen DeLong" wrote: > > > Sent from my iPhone > > On Oct 28, 2011, at 12:16, Brian Johnson wrote: > >> Owen, >> >> When you stretch an analogy this thin, it always falls apart. I was referring to the poison/pollution not the water/air. A drought/vacuum* would not be possible, but would you want the poisoned water/air? >> > I can tolerate a lot of spam if my legitimate messages get through. I have zero tolerance for blocking my legitimate traffic in the name of stopping pollution. I oppose the death penalty on the same basis. > > Owen > How could my filter stop you from sending legitimate traffic? If you pay for services from me under my AUP, you need to comply with the AUP. I think this is a dead topic. We simply disagree on the merits. I appreciate your insight. - Brian From bjohnson at drtel.com Fri Oct 28 23:30:17 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Sat, 29 Oct 2011 04:30:17 +0000 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu>, Message-ID: ++1 - Brian Sent from my iPad On Oct 28, 2011, at 2:05 PM, "Mike Jones" wrote: > On 28 October 2011 16:41, wrote: >> You *do* realize that for all your nice "Thei Internet Is Not A Commons" >> ranting, the basic problem is that some people (we'll call them spammers) *do* >> think that (a) it's a commons (or at least the exact ownership of a given >> chunk is irrelevant), and (b) they're allowed to graze their sheep upon it. > > If someone keeps putting their animals in my garden then some > countries would permit me to shoot them and sue the owner for the cost > of the bullets. Even those with more restrictive property rights laws > would still permit me to throw them off of my land and sue the owner > for any damage they caused me. > > On the Internet when people start shooting their sheep they think they > are the victims and go to the dutch police, sorry i mean the police of > whichever jurisdiction the hypothetical entity is from, complaining > that they are being deprived of their right to abuse peoples gardens. > > - Mike > From jra at baylink.com Sat Oct 29 08:21:07 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 29 Oct 2011 09:21:07 -0400 (EDT) Subject: Update Bogon Lists In-Reply-To: <4EAB5EAA.4050401@mt.au.com> Message-ID: <31536496.506.1319894467500.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matt Taylor" > Try this IP: 101.0.127.1 >From tamqflta: [jra at devil ~]$ mtr -r -c10 101.0.127.1 HOST: devil Loss% Snt Last Avg Best Wrst StDev 1. 173.241.205.130 0.0% 10 0.6 0.6 0.4 1.0 0.2 2. gi2-3.border3.esnet.com 0.0% 10 0.8 0.6 0.4 0.8 0.1 3. 64.209.96.17 0.0% 10 0.3 0.4 0.2 0.5 0.1 4. as0-20G.scr1.HOU1.gblx.net 0.0% 10 23.6 28.9 23.4 77.2 17.0 5. xe9-2-0-10G.scr3.SNV2.gblx.n 0.0% 10 62.8 62.8 62.7 63.0 0.1 6. e8-1-20G.ar5.SJC2.gblx.net 0.0% 10 80.9 76.3 63.5 82.9 8.2 7. 64.215.29.54 0.0% 10 71.9 71.9 71.8 72.0 0.1 8. pos-0-0-1.cor01.syd03.nsw.VO 0.0% 10 227.6 232.8 227.5 279.0 16.2 9. ten-1-3-0.cor02.syd03.nsw.VO 0.0% 10 227.6 227.6 227.5 227.8 0.1 10. ip-203.192.31.114.VOCUS.net. 0.0% 10 227.6 227.6 227.5 227.7 0.1 11. ge-0-0-0.bdr01.syd04.nsw.VOC 10.0% 10 227.8 227.7 227.5 227.8 0.1 12. core-rtr-a.c1.voc.digitalpac 10.0% 10 227.8 227.7 227.6 227.8 0.1 [jra at devil ~]$ mtr -rn -c10 101.0.127.1 HOST: devil Loss% Snt Last Avg Best Wrst StDev 1. 173.241.205.130 0.0% 10 0.5 0.6 0.4 0.9 0.1 2. 216.139.207.18 0.0% 10 0.4 0.5 0.3 0.7 0.1 3. 64.209.96.17 0.0% 10 0.4 0.3 0.2 0.4 0.1 4. 67.17.95.53 0.0% 10 23.4 23.6 23.4 24.5 0.3 5. 67.16.163.206 0.0% 10 62.9 62.8 62.7 62.9 0.1 6. 67.16.145.118 0.0% 10 73.2 67.5 63.5 74.4 4.4 7. 64.215.29.54 0.0% 10 72.0 72.0 71.9 72.0 0.0 8. 114.31.199.45 0.0% 10 227.8 227.6 227.5 227.8 0.1 9. 114.31.192.87 0.0% 10 227.8 227.6 227.5 227.8 0.1 10. 114.31.192.203 0.0% 10 227.5 227.6 227.5 227.9 0.1 11. 114.31.192.181 10.0% 10 227.6 227.6 227.5 227.8 0.1 12. 101.0.127.1 10.0% 10 227.6 227.7 227.5 227.9 0.1 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jcdill.lists at gmail.com Sun Oct 30 09:20:10 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 30 Oct 2011 07:20:10 -0700 Subject: Need photographs of IT/Telecom gear/rooms In-Reply-To: <4EA9B172.5000202@tiedyenetworks.com> References: <4EA9B172.5000202@tiedyenetworks.com> Message-ID: <4EAD5D1A.8060000@gmail.com> > Greetings, > > I have been given the opportunity to teach the mechanics of the > Internet to a group of 6 - 12'th grade students, Show them this movie: http://www.warriorsofthe.net/movie.html jc From ekim.ittag at gmail.com Sun Oct 30 11:42:10 2011 From: ekim.ittag at gmail.com (Mike Gatti) Date: Sun, 30 Oct 2011 09:42:10 -0700 Subject: Colocation providers and ACL requests In-Reply-To: <29baeb8d-2df0-4dc4-9e63-a89fa4717078@mail.gitflorida.com> References: <29baeb8d-2df0-4dc4-9e63-a89fa4717078@mail.gitflorida.com> Message-ID: <7FF4C97C-B72E-4435-998F-80CBEC892DAB@gmail.com> I tend to disagree somewhat, you really have to put some context around the request and convey that to your provider. If the request is "please help me block this DDoS traffic so that I can contact the source as it's impacting my ability to do business" I think that is a reasonable request as long as it's not a permanent solution. I have worked through similar incidents in some datacenter in Northern Virginia (Sterling, Ashburn) and all of them accommodated that request at no cost. -- Michael Gatti ekim.ittag at gmail.com On Oct 27, 2011, at 8:09 PM, James Ashton wrote: > Christopher, > This is pretty common policy. Not many datacenters of any size is going to act differently. If you don't purchase this service then you will not get the service. > > They may be willing work work with you on black-holing problem IPs though. This is pretty common, but don't expect a filtering package without purchasing it. > > James > > ----- Original Message ----- > From: "Christopher Pilkington" > To: "NANOG mailing list" > Sent: Tuesday, October 25, 2011 2:43:00 PM > Subject: Colocation providers and ACL requests > > Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: > > deny udp any a.b.c.d/24 eq 80 > > ?to refuse and tell us we must subscribe to their managed DDOS product? > > -cjp > > > From jra at baylink.com Sun Oct 30 11:47:00 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 30 Oct 2011 12:47:00 -0400 (EDT) Subject: Outgoing SMTP Servers In-Reply-To: <33536.1319751497@turing-police.cc.vt.edu> Message-ID: <19028578.636.1319993220093.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said: > > So... I'm in complete agreement with your statement, but The > > Wikipedia reference is not pertinent. > > So I point out the tragedy of the commons, you agree with it, but the Wikipedia > reference that talks about the same exact thing isn't pertinent? How does that > follow? :) http://xkcd.com/958/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From caldcv at gmail.com Sun Oct 30 13:13:03 2011 From: caldcv at gmail.com (Chris) Date: Sun, 30 Oct 2011 14:13:03 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: <4EABE8EF.6070101@ripe.net> References: <20111026171837.0dafce03@petrie.dereferenced.org> <4EABE8EF.6070101@ripe.net> Message-ID: See, since I emailed this - RIPE wants feedback and sent me an email offlist! I'll gladly give them an earful about how RIPE address ranges are starting to be notorious for abuse due to lack of valid WHOIS information and lack of response from so-called abuse departments. I would like to thank Mr. Herrin for his input because he is completely right now. With the Protect IP Act lurking in Congress, would you rather have the Dept of Justice mandate URL blocking of DNS or would you continue to enjoy the freedom we have right now between companies, professionals and everybody else without the government's blind mandate on everything. I would rather have all of us call the shots and work in cooperation than a lobbyist or special interest buying the vote of a politician to have some Chinese / totalitarian control of the Internet. Mr. Pittcock, I was point out that I've had providers in the past automatically respond to abuse complaint but do nothing and in this instance, an abuse complaint just goes 100% unnoticed. It was not meant to be taken literally. Thanks, -C From dhc2 at dcrocker.net Sun Oct 30 14:19:35 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 30 Oct 2011 12:19:35 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> Message-ID: <4EADA347.3020109@dcrocker.net> Bill, Your misunderstanding of physical pollution pollutes your understanding of spam. But it turns out that you seem to misunderstand spam quite a bit, independently. On 10/27/2011 9:26 PM, William Herrin wrote: > If you throw pollution into the air, it may eventually impact me or it > may blow somewhere else. Mostly it'll blow somewhere else. But as lots > of people throw pollution into the air, some non-trivial portion of > that pollution will drift over me. This is the so-called tragedy. They used to be able to tell how recently someone moved to in Los Angeles by how corrupted their lungs were, from the /local/ pollution. Maybe it's still possible. Pollution tends to increase the occurrence of some diseases, thereby significantly increasing societal health costs. So the casual view of pollution going "somewhere else" is simply wrong. Still you do seem to understand that it affects some mass of folk. > By contrast, if you send me spam email, you are directly abusing my > computer. The linkage is not at all amorphous. You send to me. I > receive from you. There is no "all world" or "local area" destination. > If you send without some specific pointer in my direction, I won't > receive it. Ever. > > Imagining spam as a tragedy of the commons disguises its true nature > as a massive quantity of one-on-one abuses of individual owners' > computers. Worse, it forgives the owners of the intermediate networks > for shrugging their shoulders and turning a blind eye to the abusers. Email travels over shared resources. Spam consumes roughly %95 percent of that shared path (comm lines and servers). Receiving operators must devote masses of resources to filter that firehose of mostly junk, in order to get everyone's mailboxes to remain at least somewhat useful. Since the spammers are well-organized and aggressive and often quite bright, they adapt their attacks to get round these filters, thereby creating an extremely unstable arms race. This means the entire situation is extremely unstable. When -- not if -- it breaks, mail becomes unusable. That will be a common suffering. The one-to-one cost or damage is probably also a reasonable perspective, but it's /incremental/ to the shared cost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jra at baylink.com Sun Oct 30 14:29:22 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 30 Oct 2011 15:29:22 -0400 (EDT) Subject: Today is Dennis Ritchie Day Message-ID: <18426623.736.1320002962200.JavaMail.root@benjamin.baylink.com> So saith Tim O'Reilly, and I think he's entitled... http://radar.oreilly.com/2011/10/dennis-ritchie-day.html Happy landings, Dennis. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From kyle.creyts at gmail.com Sun Oct 30 15:52:24 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sun, 30 Oct 2011 16:52:24 -0400 Subject: XSServer / Taking down a spam friendly provider In-Reply-To: References: <20111026171837.0dafce03@petrie.dereferenced.org> <20111027005241.33b1f951@petrie.dereferenced.org> Message-ID: I would agree that at the moment, we exist in what is supposed to be a "self-policing" community. How long will it stay so, if livelihoods are jeopardized? Some are paid to move bits, and consider that their only obligation. Others are charged with operating services that are impacted by the aforementioned types of pollution. But each party cannot exist without the other, at the end of the day; the economic relationship between the two, at some level, makes this a shared problem. While bit-movers _may not_ have an explicit and direct business reason to aid in reducing the pollution in the community, as members of the community, is it not our collective responsibility to work against those polluting it? It is disrespectful, IMHO, to those who worked so hard to make this communal resource the shared treasure it is, for us to neglect the duty to protect and care for it. I understand that not everyone feels that it should be policed. I have respect for those who feel this way. To me, this is a complicated ecosystem, and we are its custodians, responsible for its continued health and function. Who among you do not have a custodial relationship with some network or inter-networking? Do none of you feel a responsibility to maintain it for those who will come after you? As a part of ensuring the continued function of our ecosystem, in light of the reality of this pollution, I think ensuring the integrity of our individual administrative domains, and working with others, in some capacity, to ensure the health and integrity of their own, is paramount. I would make a reference to the way we have treated and are treating our planet, but the analogy is tired. I do fear that some day, the 'way we treated the internet' will be a similarly tired metaphor. -k On Oct 27, 2011 8:47 PM, "William Herrin" wrote: > On Thu, Oct 27, 2011 at 1:52 AM, William Pitcock > wrote: > > On Wed, 26 Oct 2011 20:22:53 -0400 > > Chris wrote: > >> This is a huge business. Shady "SEO" companies are charging > >> individuals at least $250 per month to use their spam tools of choice > >> to spam forums and Wordpress blogs. I got one of the major players on > >> the run right now because he cannot seem to keep his "business page" > >> hosted with a company longer than a few weeks and I keep playing > >> whack-a-mole with him. > > > > McColo and Atrivo were not terminated because of spam. If you believe > > they are, then you are simply misinformed. Atrivo and McColo were > > terminated over their network being used extensively for botnet > > control centers. > > William, > > Atrivo and McColo were terminated _late_. > > As an industry, might we not consider finding a reasonable way to do a > more effective job identifying and dealing with shops who can't seem > to keep out the customers who use those facilities to hurt and abuse > the rest of us? If we fail to adequately self-regulate, the courts and > entities like the U.S. Congress will surely find a way to do it for > us. And they won't care nearly as much about the technical constraints > as we do. > > I make no judgment about XSServer and offer no solution. I merely > suggest that Chris has posed a legitimate operational problem that our > community may wish to redress while the while the details of such a > choice are still in our hands. > > 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 Oct 30 16:53:10 2011 From: bill at herrin.us (William Herrin) Date: Sun, 30 Oct 2011 17:53:10 -0400 Subject: Outgoing SMTP Servers In-Reply-To: <4EADA2B8.2020209@bbiw.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA2B8.2020209@bbiw.net> Message-ID: On Sun, Oct 30, 2011 at 3:17 PM, Dave CROCKER wrote: > Your misunderstanding of physical pollution pollutes your understanding of > spam. ?But it turns out that you seem to misunderstand spam quite a bit, > independently. Okay wise guy. Let's take another look at your version of email spam as pollution. Put some gangbangers in a truck and drive them down the street. These are our allegorical spammers. As the truck rolls they fire thousands of rounds, clip after clip, from Uzis aimed at every glass window that they see. Clearly I am mistaken to describe these gangbangers as mass murdering criminals. When I say that they and the folks who aided and abetted their spree should be locked away, I display my ignorance as to the nature of gangs. No, this is all really a matter of lead pollution: People taking too much advantage of the fact that it's generally OK to drive on the road, or throw objects through the air, a real tragedy of those commons. It's not like we can jail everybody who decides to shoot up a house. So, instead of hiring sheriffs whose our ire will land on folks who willfully or negligently shielded the gangbangers from detection and pursuit, we should forgive the complicit and restrict our efforts to bulletproof glass and generally reducing the rain of bullets to a more survivable level. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bjohnson at drtel.com Sun Oct 30 22:36:50 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 31 Oct 2011 03:36:50 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <4EADA347.3020109@dcrocker.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> Message-ID: On Oct 30, 2011, at 2:19 PM, Dave CROCKER wrote: > > Email travels over shared resources. Spam consumes roughly %95 percent of that shared path (comm lines and servers). Receiving operators must devote masses of resources to filter that firehose of mostly junk, in order to get everyone's mailboxes to remain at least somewhat useful. Since the spammers are well-organized and aggressive and often quite bright, they adapt their attacks to get round these filters, thereby creating an extremely unstable arms race. This means the entire situation is extremely unstable. When -- not if -- it breaks, mail becomes unusable. That will be a common suffering. > > The one-to-one cost or damage is probably also a reasonable perspective, but it's /incremental/ to the shared cost. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? - Brian * I do not think of the Internet as a commons, but Dave does. I will not comment on this as it is tangential to the thread. From dhc2 at dcrocker.net Sun Oct 30 23:41:23 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 30 Oct 2011 21:41:23 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> Message-ID: <4EAE26F3.8060401@dcrocker.net> On 10/30/2011 8:36 PM, Brian Johnson wrote: > So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From doctorchd at gmail.com Mon Oct 31 02:56:10 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Mon, 31 Oct 2011 09:56:10 +0200 Subject: using IPv6 address block across multiple locations Message-ID: Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. Recently we obtained our PI /48 from RIPE. The idea was to assign partial slices from this block to different locations (we have currently 3 offices in Europe and 2 in USA). All locations are interconnected with static VPNs. Each location is supposed to establish BGP session with local ISP. Partial prefix /56 + aggregate /48 (with long AS PATH) are to be announced by each office. The problem we ran across is that ISP in US does not wish to accept prefixes longer then /48 from us. Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Thank you. Dmitry Cherkasov From swmike at swm.pp.se Mon Oct 31 03:37:20 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 31 Oct 2011 09:37:20 +0100 (CET) Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: > Need your advice: is this normal to distribute /48 by /56 parts across > locations or should we obtain separate /48 for each of them? Or maybe we > need /32 that can be split into multiple /48? Anyway we are not ISP so > /48 looks quite reasonable and sufficient for all our needs. Don't expect anyone to accept less than /48, so in your setup you need a /48 per site. -- Mikael Abrahamsson email: swmike at swm.pp.se From richard.barnes at gmail.com Mon Oct 31 04:39:57 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 31 Oct 2011 05:39:57 -0400 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: Couldn't you also advertise the /48 from all the sites, if you're willing to sort things out over the inter-site VPNs?--Richard On Mon, Oct 31, 2011 at 4:37 AM, Mikael Abrahamsson wrote: > On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: > >> Need your advice: is this normal to distribute /48 by /56 parts across >> locations or should we obtain separate /48 for each of them? Or maybe we >> need /32 that can be split into multiple /48? Anyway we are not ISP so /48 >> looks quite reasonable and sufficient for all our needs. > > Don't expect anyone to accept less than /48, so in your setup you need a /48 > per site. > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > > From jeroen at unfix.org Mon Oct 31 05:43:53 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 31 Oct 2011 11:43:53 +0100 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: <4EAE7BE9.3030705@unfix.org> On 2011-10-31 08:56 , Dmitry Cherkasov wrote: > Hello, > > Please advice what is the best practice to use IPv6 address block > across distributed locations. You go to multiple RIRs and get multiple prefixes. Heck, you apparently can even get multiple disjunct prefixes from the same RIR. There went the whole idea of aggregation.... Greets, Jeroen (Note though that some entities who actually got disjunct prefixes are quite large and will be putting quite a number of hosts behind those prefixes, thus the usage/prefix ratio is quite high and likely worthy of a routing slot) From rcarpen at network1.net Mon Oct 31 06:52:22 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 31 Oct 2011 07:52:22 -0400 (EDT) Subject: using IPv6 address block across multiple locations In-Reply-To: Message-ID: <2f9085a4-48e0-41c7-8f24-eaa927f4b1b3@zimbra.network1.net> Not sure about RIPE, but under ARIN, you would qualify for a /44 (or larger if you have more than 12 sites), out of which you could announce the /48s independently and as an aggregate, as you wish to do. -Randy ----- Original Message ----- > Hello, > > Please advice what is the best practice to use IPv6 address block > across distributed locations. > > Recently we obtained our PI /48 from RIPE. The idea was to assign > partial slices from this block to different locations (we have > currently 3 offices in Europe and 2 in USA). All locations are > interconnected with static VPNs. Each location is supposed to > establish BGP session with local ISP. Partial prefix /56 + aggregate > /48 (with long AS PATH) are to be announced by each office. > > The problem we ran across is that ISP in US does not wish to accept > prefixes longer then /48 from us. > Need your advice: is this normal to distribute /48 by /56 parts > across > locations or should we obtain separate /48 for each of them? Or maybe > we need /32 that can be split into multiple /48? Anyway we are not > ISP > so /48 looks quite reasonable and sufficient for all our needs. > > Thank you. > > Dmitry Cherkasov > > > From owen at delong.com Mon Oct 31 07:59:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Oct 2011 05:59:31 -0700 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: Ideally, you should put a /48 at each location. Owen On Oct 31, 2011, at 12:56 AM, Dmitry Cherkasov wrote: > Hello, > > Please advice what is the best practice to use IPv6 address block > across distributed locations. > > Recently we obtained our PI /48 from RIPE. The idea was to assign > partial slices from this block to different locations (we have > currently 3 offices in Europe and 2 in USA). All locations are > interconnected with static VPNs. Each location is supposed to > establish BGP session with local ISP. Partial prefix /56 + aggregate > /48 (with long AS PATH) are to be announced by each office. > > The problem we ran across is that ISP in US does not wish to accept > prefixes longer then /48 from us. > Need your advice: is this normal to distribute /48 by /56 parts across > locations or should we obtain separate /48 for each of them? Or maybe > we need /32 that can be split into multiple /48? Anyway we are not ISP > so /48 looks quite reasonable and sufficient for all our needs. > > Thank you. > > Dmitry Cherkasov From bjohnson at drtel.com Mon Oct 31 08:23:04 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 31 Oct 2011 13:23:04 +0000 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> Message-ID: Bill, Responses in-line... >-----Original Message----- >From: Bill Stewart [mailto:nonobvious at gmail.com] >Sent: Friday, October 28, 2011 6:22 PM >To: nanog at nanog.org >Cc: Brian Johnson >Subject: Re: Outgoing SMTP Servers > > >I've got a strong preference for ISPs to run a >Block-25-by-default/Enable-when-asked. As a purist, I'd prefer to >have Internet connections that are actually Internet connections, and >if you want to run email on a Linux box at home or have an Arduino in >your refrigerator email the grocery when you're out of milk, you >should be able to, and if some meddling kid at an ISP wants to block >it, they should get off your lawn. In practice, of course, somewhere >between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs, >they're zombie spambots on home PCs, or occasional driveby wifi >spammers or other pests, and not only should outgoing mail be blocked, >but the user should be notified and the connection should probably be >put into some kind of quarantined access. > This is, of course, exactly why this blocking is done. >But that's for Port 25 - the Port 25 blocking by ISPs has largely >pushed Email Service Providers to use other protocols such as 587 for >mail submission from an MUA to the MTA, or webmail instead, and it's >really bad practice for ISPs to interfere with that. In some cases >they'll still be sending spam, but that's the MTA's job to filter out, >and if they don't, they'll end up on a bunch of RBLs. (And generally >they'll be trying to keep their mail clean themselves - if the MTA >providers were spammers, they wouldn't need to go to the trouble of >having actual residential users as customers when they could >mass-produce it cheaper directly.) For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? I would not block submission ports, specifically 587. More specifically, the only port I will block would be 25. The RFC actually says to use the submission port for the MUA to MTA anyways. RFC 5068 is definitive on this issue. Also read RFC 4409 and its predecessors. My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. Call me a liar! :) - Brian From streiner at cluebyfour.org Mon Oct 31 09:42:33 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 31 Oct 2011 10:42:33 -0400 (EDT) Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: > The problem we ran across is that ISP in US does not wish to accept > prefixes longer then /48 from us. > Need your advice: is this normal to distribute /48 by /56 parts across > locations or should we obtain separate /48 for each of them? Or maybe > we need /32 that can be split into multiple /48? Anyway we are not ISP > so /48 looks quite reasonable and sufficient for all our needs. Think of a /48 the same way you'd use a /24 of IPv4 space in a multi-homed design. /48 is the smallest v6 block that you can reasonably expect to be globally reachable. Many providers will not accept anything smaller, unless it's from one of their own blocks, in which case it will likely get aggregated into their larger prefix. jms From streiner at cluebyfour.org Mon Oct 31 09:45:04 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 31 Oct 2011 10:45:04 -0400 (EDT) Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Mon, 31 Oct 2011, Owen DeLong wrote: > Ideally, you should put a /48 at each location. Speaking from my experience with getting v6 space from ARIN earlier this year, as long as your documentation is in pretty good order, a /48 per site is pretty easy to get. I don't know if the experience is different with other RIRs. jms From nazgul at somewhere.com Mon Oct 31 10:49:51 2011 From: nazgul at somewhere.com (Kee Hinckley) Date: Mon, 31 Oct 2011 11:49:51 -0400 Subject: Google+ now available for Google Apps domains In-Reply-To: References: Message-ID: <7EA88141-E237-4FF0-8716-C6D9EF121AC6@somewhere.com> On Oct 27, 2011, at 9:46 PM, Justin Seabrook-Rocha wrote: > Once that tool is complete, you should be able to merge/migrate your gmail G+ account to your Google Apps account. You can already do so with most of the numerous other Google properties. Keep in mind that if you want to publicly post on Google+ using your Google Apps account, you will need to change your account name to conform with Google's definition of "something that looks kind of like the thing on your government photo ID". From joelja at bogus.com Mon Oct 31 11:01:01 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 31 Oct 2011 09:01:01 -0700 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: <4EAEC63D.4090903@bogus.com> On 10/31/11 05:59 , Owen DeLong wrote: > Ideally, you should put a /48 at each location. > > Owen > > On Oct 31, 2011, at 12:56 AM, Dmitry Cherkasov wrote: > >> Hello, >> >> Please advice what is the best practice to use IPv6 address block >> across distributed locations. >> >> Recently we obtained our PI /48 from RIPE. The idea was to assign >> partial slices from this block to different locations (we have >> currently 3 offices in Europe and 2 in USA). All locations are >> interconnected with static VPNs. Each location is supposed to >> establish BGP session with local ISP. Partial prefix /56 + aggregate >> /48 (with long AS PATH) are to be announced by each office. >> >> The problem we ran across is that ISP in US does not wish to accept >> prefixes longer then /48 from us. >> Need your advice: is this normal to distribute /48 by /56 parts across >> locations or should we obtain separate /48 for each of them? Or maybe >> we need /32 that can be split into multiple /48? Anyway we are not ISP >> so /48 looks quite reasonable and sufficient for all our needs. It's not because it can't be de-aggregated further in general. if you have 5 discreet site you really need at /45. if you can tthe announcements of the regions to something less specific than a /48 e.g. a /46 then by all means do so. >> Thank you. >> >> Dmitry Cherkasov > > From Mike.Rae at sjrb.ca Mon Oct 31 11:22:40 2011 From: Mike.Rae at sjrb.ca (Mike Rae) Date: Mon, 31 Oct 2011 16:22:40 +0000 Subject: Hands and Eyes for London and Amsterdam Message-ID: Hi : Looking for some recommendation on "Hands and Eyes" to aid in setting up gear in datacenters located in Amsterdam and London. Exceptional quality of workmanship a must. Thanks Mike From leigh.porter at ukbroadband.com Mon Oct 31 11:31:57 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 31 Oct 2011 16:31:57 +0000 Subject: Hands and Eyes for London and Amsterdam In-Reply-To: References: Message-ID: For London: http://www.netsumo.com/ -- Leigh Porter > -----Original Message----- > From: Mike Rae [mailto:Mike.Rae at sjrb.ca] > Sent: 31 October 2011 16:26 > To: nanog at nanog.org > Subject: Hands and Eyes for London and Amsterdam > > Hi : > > Looking for some recommendation on "Hands and Eyes" to aid in setting > up gear in datacenters located in Amsterdam and London. > > Exceptional quality of workmanship a must. > > Thanks > Mike > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From joelja at bogus.com Mon Oct 31 11:30:49 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 31 Oct 2011 09:30:49 -0700 Subject: using IPv6 address block across multiple locations In-Reply-To: <4EAE7BE9.3030705@unfix.org> References: <4EAE7BE9.3030705@unfix.org> Message-ID: <4EAECD39.2070507@bogus.com> On 10/31/11 03:43 , Jeroen Massar wrote: > On 2011-10-31 08:56 , Dmitry Cherkasov wrote: >> Hello, >> >> Please advice what is the best practice to use IPv6 address block >> across distributed locations. > > You go to multiple RIRs and get multiple prefixes. > > Heck, you apparently can even get multiple disjunct prefixes from the > same RIR. > > There went the whole idea of aggregation.... or you could just get an aggregateable block of the appropiate size from one RIR and deaggregate it as necessary which should be the normal course of action... > Greets, > Jeroen > > (Note though that some entities who actually got disjunct prefixes are > quite large and will be putting quite a number of hosts behind those > prefixes, thus the usage/prefix ratio is quite high and likely worthy of > a routing slot) > From mike at mtcc.com Mon Oct 31 11:48:21 2011 From: mike at mtcc.com (Michael Thomas) Date: Mon, 31 Oct 2011 09:48:21 -0700 Subject: Outgoing SMTP Servers In-Reply-To: <4EAE26F3.8060401@dcrocker.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> <4EAE26F3.8060401@dcrocker.net> Message-ID: <4EAED155.8040604@mtcc.com> Dave CROCKER wrote: > > > On 10/30/2011 8:36 PM, Brian Johnson wrote: >> So you support filtering end-user outbound SMTP sessions as this is a >> means to prevent misuse of the Commons*. Correct? > > > If it is acceptable to have the receiving SMTP server at one end of a > connection do filtering -- and it is -- then why wouldn't it be > acceptable to have filtering done at the source end of that SMTP > connection? > > As soon as we step upstream this way, stepping up earlier still is > merely a question of efficacy and efficiency. I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of "now that we know we have a likely bot, what do we with it, and how much will that cost?" Mike From smb at cs.columbia.edu Mon Oct 31 12:08:35 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 31 Oct 2011 13:08:35 -0400 Subject: using IPv6 address block across multiple locations In-Reply-To: <4EAECD39.2070507@bogus.com> References: <4EAE7BE9.3030705@unfix.org> <4EAECD39.2070507@bogus.com> Message-ID: <898D7E6D-0B27-45AC-A3CF-0E1B89F796B6@cs.columbia.edu> On Oct 31, 2011, at 12:30 49PM, Joel jaeggli wrote: > On 10/31/11 03:43 , Jeroen Massar wrote: >> On 2011-10-31 08:56 , Dmitry Cherkasov wrote: >>> Hello, >>> >>> Please advice what is the best practice to use IPv6 address block >>> across distributed locations. >> >> You go to multiple RIRs and get multiple prefixes. >> >> Heck, you apparently can even get multiple disjunct prefixes from the >> same RIR. >> >> There went the whole idea of aggregation.... > > or you could just get an aggregateable block of the appropiate size from > one RIR and deaggregate it as necessary which should be the normal > course of action... > One important question: if data for one of your locations were to be sent from somewhere that is closer (as the packets fly) to another, would you prefer that it be sent over your VPN or over the open Internet? The latter may be cheaper for you, since you don't have to pay for that bandwidth; the former may be more secure if your VPN is encrypted. To send stuff only over the open Internet in this situation, use a separate /48 for each location. To send stuff only over your VPN, put everything in a single /44 or so and advertise only it. Advertising the /44 and having each location advertising its own /48 within that /44 will usually cause the traffic to go over the open Internet, with your VPN as backup in case of reachability problems if some ISPs won't carry the longer /48s because of their own policies. --Steve Bellovin, https://www.cs.columbia.edu/~smb From jbates at brightok.net Mon Oct 31 13:32:00 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Oct 2011 13:32:00 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <4EAED155.8040604@mtcc.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> <4EAE26F3.8060401@dcrocker.net> <4EAED155.8040604@mtcc.com> Message-ID: <4EAEE9A0.30200@brightok.net> On 10/31/2011 11:48 AM, Michael Thomas wrote: > I've often wondered the same thing as to what the resistance is to outbound > filtering is. I can think of a few possibilities: > > 1) cost of filtering > 2) false positives > 3) really _not_ wanting to know about abuse On the other hand, you have 1) cost of tracking 2) support costs handling infections It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well. Finally, when architecture allows it, dynamic profiles with ACL support allowing a default of tcp/25 blocked, and easy to find and click removal of an account from tcp/25 blocking, combined with ACL monitoring, flagging, and notification by support staff is probably the ultimate in ideal scenarios. Combined with a % of traffic mirrored into a tunnel to an IDS which monitors for things such as network scanning or known signatures outbound, it makes for a very effective mechanism to assist customers in protecting themselves. I'm personally curious how much traffic is necessary to mirror to properly detect problems. ie, can you get away with 1% or less (GE for each 100GE-200GE of traffic) or if you must cover as much as 10%+. My traffic load is small enough that it doesn't matter, but it's always nice to know how well something might scale. Jack From jay at miscreant.org Mon Oct 31 16:00:26 2011 From: jay at miscreant.org (Jay Mitchell) Date: Tue, 1 Nov 2011 08:00:26 +1100 Subject: Google+ now available for Google Apps domains In-Reply-To: <7EA88141-E237-4FF0-8716-C6D9EF121AC6@somewhere.com> References: <7EA88141-E237-4FF0-8716-C6D9EF121AC6@somewhere.com> Message-ID: Possibly not for much longer: http://mashable.com/2011/10/19/google-to-support-pseudonyms/ Regards, Jay On 01/11/2011, at 2:49 AM, Kee Hinckley wrote: > > On Oct 27, 2011, at 9:46 PM, Justin Seabrook-Rocha wrote: >> Once that tool is complete, you should be able to merge/migrate your gmail G+ account to your Google Apps account. You can already do so with most of the numerous other Google properties. > > Keep in mind that if you want to publicly post on Google+ using your Google Apps account, you will need to change your account name to conform with Google's definition of "something that looks kind of like the thing on your government photo ID". From bonomi at mail.r-bonomi.com Mon Oct 31 16:19:14 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 31 Oct 2011 16:19:14 -0500 (CDT) Subject: Outgoing SMTP Servers In-Reply-To: <4EAED155.8040604@mtcc.com> Message-ID: <201110312119.p9VLJEck099196@mail.r-bonomi.com> On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas opined: > > Dave CROCKER wrote: > > > > > > On 10/30/2011 8:36 PM, Brian Johnson wrote: > >> So you support filtering end-user outbound SMTP sessions as this is a > >> means to prevent misuse of the Commons*. Correct? > > > > > > If it is acceptable to have the receiving SMTP server at one end of a > > connection do filtering -- and it is -- then why wouldn't it be > > acceptable to have filtering done at the source end of that SMTP > > connection? > > > > As soon as we step upstream this way, stepping up earlier still is > > merely a question of efficacy and efficiency. > > I've often wondered the same thing as to what the resistance is to outbound > filtering is. I can think of a few possibilities: > > 1) cost of filtering > 2) false positives > 3) really _not_ wanting to know about abuse > > Given the cost of incoming filtering, I'd think that outbound filtering > would be down in the noise. On the other hand, getting support blowback > for false positives seems plausible, but probably no worse than blowback > from false positives incoming. So, #3 -- assuming my list is exhaustive > which it probably isn't -- seems like a real possibility. Especially when > you consider that it opens a can of worms of "now that > we know we have > a likely bot, what do we with it, and how much will that cost?" There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. There are only a relative handful of things a _residential_ provider can use to "reliably" filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. <*GRIN*> Further, any sort of "content" filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%. From nazgul at somewhere.com Mon Oct 31 16:34:00 2011 From: nazgul at somewhere.com (Kee Hinckley) Date: Mon, 31 Oct 2011 17:34:00 -0400 Subject: Google+ now available for Google Apps domains In-Reply-To: References: <7EA88141-E237-4FF0-8716-C6D9EF121AC6@somewhere.com> Message-ID: On Oct 31, 2011, at 5:00 PM, Jay Mitchell wrote: > Possibly not for much longer: > > > http://mashable.com/2011/10/19/google-to-support-pseudonyms/ Google officially* repudiated that, saying it was nothing new, just their old promise that eventually they plan to offer pseudonym support if they can solve the technical problems. * By "officially", I mean that Google+ VP Vic Gundotra commented in Mike Elgan's post that Mike was correct. That's about as official as Google gets when it comes to the policy. From jfbeam at gmail.com Mon Oct 31 19:07:10 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 31 Oct 2011 20:07:10 -0400 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Mon, 31 Oct 2011 05:39:57 -0400, Richard Barnes wrote: > Couldn't you also advertise the /48 from all the sites, if you're > willing to sort things out over the inter-site VPNs? If we're talking about a site-to-site IPsec VPN "over the internet", then that's a very bad idea. Even if "the internet" in this case is entirely within the same provider's network. (and it doesn't sound like it is.) --Ricky From justine at cs.washington.edu Mon Oct 31 19:47:56 2011 From: justine at cs.washington.edu (Justine Sherry) Date: Mon, 31 Oct 2011 17:47:56 -0700 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) Message-ID: Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (sylvia at eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 From bjohnson at drtel.com Mon Oct 31 20:12:32 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 1 Nov 2011 01:12:32 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <4EAEE9A0.30200@brightok.net> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> <4EAE26F3.8060401@dcrocker.net> <4EAED155.8040604@mtcc.com>,<4EAEE9A0.30200@brightok.net> Message-ID: <7C2677B5-9AF4-4E4D-8FFD-259320B8E5E7@drtel.com> Sent from my iPad On Oct 31, 2011, at 1:30 PM, "Jack Bates" wrote: > > > On 10/31/2011 11:48 AM, Michael Thomas wrote: >> I've often wondered the same thing as to what the resistance is to outbound >> filtering is. I can think of a few possibilities: >> >> 1) cost of filtering >> 2) false positives >> 3) really _not_ wanting to know about abuse > > On the other hand, you have > > 1) cost of tracking > 2) support costs handling infections > > It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. Let me know when u can "fix" the root causes. The two I know of: 1. Bad actors 2. Clueless users > > In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well. Still not the real root cause, but close. ;) Largely in agreement otherwise. - Brian From bjohnson at drtel.com Mon Oct 31 20:17:16 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 1 Nov 2011 01:17:16 +0000 Subject: Outgoing SMTP Servers In-Reply-To: <201110312119.p9VLJEck099196@mail.r-bonomi.com> References: <4EAED155.8040604@mtcc.com>, <201110312119.p9VLJEck099196@mail.r-bonomi.com> Message-ID: <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com> Sent from my iPad On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" > There is an at-least-somewhat-valid argument against outbound filtering. > to wit, various receiving systems may have different policies on what is/ > is-not 'acceptable' traffic. They have a better idea of what is acceptable > to the recipients (their users), than the originating MTA operator does. An > originating system cannot accomodate that diversity of opinions _without_ > getting input from all prospective recipients. > > And it is, of course, 'not practical' for every email recipient to notify > every email 'source' network as to what that recpient considers 'acceptable'. > This is not plausible. It also has nothing to do with a network owner protecting his network from his own users. > > There are only a relative handful of things a _residential_ provider can > use to "reliably" filter outgoing mail. A non-comprehensive list: > 1) 'Greylisting' at the origin is as effective at stopping spam as it is > at the destination. > 2) Checks for certain kinds of standards violations that legitimate mail > software does not make. > 3) Check for certain kinds of 'lies' in headers -- things that *cannot* > occur in legitimate email. > 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. > 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if > present), and quarrantining on abnormal numbers of different putative > origins. > > There's no point in checking source addresses against any DNSBL, for reasons > that should be 'obvious'. <*GRIN*> > > Further, any sort of "content" filters prevent customers from _discussing_ > scams in e-mail. > > There is a 'hard' problem in letting the source 'opt out' of such filtering, > because an intentional 'bad guy' will request his outgoing mail not be > monitored, as well as the person who has a 'legitimate' reason for sending > messages that might trip mindless content filters. > > Statistical note: Out of the last roughly 6,000 pieces of spam seen here, > circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 > were in character-sets not supported here. Incidentally, spam volume, as > seen here, is running a bit _under_ 2/3 of all email, down from a peak of > over 95%. > This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective. - Brian From afisayo at gmail.com Mon Oct 31 21:23:21 2011 From: afisayo at gmail.com (Adefisayo Adegoke) Date: Mon, 31 Oct 2011 20:23:21 -0600 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: References: Message-ID: <5948995898631926267@unknownmsgid> Hello Justine, I find it interesting, to say the least, that all of the communication that you have about a Berkeley research program while your email came from washington.edu? Thanks, 'Ayo ..... Success is getting what you want, happiness is wanting what you get - Ingrid Bergman ... the sky is too low to be my limit ....Sent from my iPhone On Oct 31, 2011, at 6:48 PM, Justine Sherry wrote: > Hello! My name is Justine and I am a graduate student at UC Berkeley > (http://cs.berkeley.edu/~justine). > > I'm doing a research project on middlebox appliances such as proxies, > WAN optimizers, and firewalls. Middlebox appliances are any > networking-related hardware other than routers and switches. I'd like > to learn a little bit about how middleboxes are used in real world > deployments in enterprises. Vendors often engage in surveys of this > type - but the research community knows less than we'd like to about > typical concerns in an enterprise network. > > If you work on network management in an enterprise, I'd love to hear > about your experiences through this survey: > https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 > > Some promises: > (1) If you give me your email address, I will not give it to anyone > else, nor will I add you to any annoying mailing lists. > (2) If you mention the name of your organization, I will not share it > with anyone else. > (3) If I publish any data from this, statistics will be reported in aggregate. > (4) I will not share the raw data from this survey with anyone other > than my advisor, Professor Sylvia Ratnasamy > (sylvia at eecs.berkeley.edu). > > Feel free to skip questions and please provide approximate answers if > you have them. > > Finally, to thank you for your time, we'll enter you in to a lottery > for a $100 Amazon gift card; we'll select two people to win and > contact them on November 16. Thank you! > > If you have any questions or concerns, please contact me. > > Justine > > PS: The survey is here! Don't miss it! > https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 > From deleskie at gmail.com Mon Oct 31 21:26:32 2011 From: deleskie at gmail.com (jim deleskie) Date: Mon, 31 Oct 2011 23:26:32 -0300 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <5948995898631926267@unknownmsgid> References: <5948995898631926267@unknownmsgid> Message-ID: A quick look at her web pg shows her undergad @ UWash On Mon, Oct 31, 2011 at 11:23 PM, Adefisayo Adegoke wrote: > Hello Justine, > > I find it interesting, to say the least, that all of the communication > that you have about a Berkeley research program while your email came > from washington.edu? > > Thanks, > > 'Ayo > > ..... Success is getting what you want, happiness is wanting what you > get - Ingrid Bergman > > ... the sky is too low to be my limit ....Sent from my iPhone > > On Oct 31, 2011, at 6:48 PM, Justine Sherry wrote: > >> Hello! My name is Justine and I am a graduate student at UC Berkeley >> (http://cs.berkeley.edu/~justine). >> >> I'm doing a research project on middlebox appliances such as proxies, >> WAN optimizers, and firewalls. Middlebox appliances are any >> networking-related hardware other than routers and switches. I'd like >> to learn a little bit about how middleboxes are used in real world >> deployments in enterprises. Vendors often engage in surveys of this >> type - but the research community knows less than we'd like to about >> typical concerns in an enterprise network. >> >> If you work on network management in an enterprise, I'd love to hear >> about your experiences through this survey: >> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >> >> Some promises: >> (1) If you give me your email address, I will not give it to anyone >> else, nor will I add you to any annoying mailing lists. >> (2) If you mention the name of your organization, I will not share it >> with anyone else. >> (3) If I publish any data from this, statistics will be reported in aggregate. >> (4) I will not share the raw data from this survey with anyone other >> than my advisor, Professor Sylvia Ratnasamy >> (sylvia at eecs.berkeley.edu). >> >> Feel free to skip questions and please provide approximate answers if >> you have them. >> >> Finally, to thank you for your time, we'll enter you in to a lottery >> for a $100 Amazon gift card; we'll select two people to win and >> contact them on November 16. Thank you! >> >> If you have any questions or concerns, please contact me. >> >> Justine >> >> PS: The survey is here! Don't miss it! >> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >> > > From justine at cs.washington.edu Mon Oct 31 21:33:55 2011 From: justine at cs.washington.edu (Justine Sherry) Date: Mon, 31 Oct 2011 19:33:55 -0700 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <5948995898631926267@unknownmsgid> References: <5948995898631926267@unknownmsgid> Message-ID: :) I should've guessed that you guys, of all people, would notice the discrepancy. I used to be at the UW; I registered for this list using my UW email address. Rather than re-register in order to be able to post to the list, I just sent from my old email address. The survey is linked from my homepage and the UW affiliation is mentioned: http://www.eecs.berkeley.edu/~justine/ Justine On Mon, Oct 31, 2011 at 19:23, Adefisayo Adegoke wrote: > Hello Justine, > > I find it interesting, to say the least, that all of the communication > that you have about a Berkeley research program while your email came > from washington.edu? > > Thanks, > > 'Ayo > > ..... Success is getting what you want, happiness is wanting what you > get - Ingrid Bergman > > ... the sky is too low to be my limit ....Sent from my iPhone > > On Oct 31, 2011, at 6:48 PM, Justine Sherry wrote: > >> Hello! My name is Justine and I am a graduate student at UC Berkeley >> (http://cs.berkeley.edu/~justine). >> >> I'm doing a research project on middlebox appliances such as proxies, >> WAN optimizers, and firewalls. Middlebox appliances are any >> networking-related hardware other than routers and switches. I'd like >> to learn a little bit about how middleboxes are used in real world >> deployments in enterprises. Vendors often engage in surveys of this >> type - but the research community knows less than we'd like to about >> typical concerns in an enterprise network. >> >> If you work on network management in an enterprise, I'd love to hear >> about your experiences through this survey: >> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >> >> Some promises: >> (1) If you give me your email address, I will not give it to anyone >> else, nor will I add you to any annoying mailing lists. >> (2) If you mention the name of your organization, I will not share it >> with anyone else. >> (3) If I publish any data from this, statistics will be reported in aggregate. >> (4) I will not share the raw data from this survey with anyone other >> than my advisor, Professor Sylvia Ratnasamy >> (sylvia at eecs.berkeley.edu). >> >> Feel free to skip questions and please provide approximate answers if >> you have them. >> >> Finally, to thank you for your time, we'll enter you in to a lottery >> for a $100 Amazon gift card; we'll select two people to win and >> contact them on November 16. Thank you! >> >> If you have any questions or concerns, please contact me. >> >> Justine >> >> PS: The survey is here! Don't miss it! >> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >> > From kmedcalf at dessus.com Mon Oct 31 22:19:59 2011 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 31 Oct 2011 21:19:59 -0600 Subject: Outgoing SMTP Servers In-Reply-To: <4EAE26F3.8060401@dcrocker.net> Message-ID: <242056bf46838144920145176dd89803@mail.dessus.com> Dave CROCKER [mailto:dhc2 at dcrocker.net] said on Sunday, 30 October, 2011 22:41 > On 10/30/2011 8:36 PM, Brian Johnson wrote: >> So you support filtering end-user outbound SMTP sessions as this is a >> means to prevent misuse of the Commons*. Correct? > If it is acceptable to have the receiving SMTP server at one end of a > connection do filtering -- and it is -- then why wouldn't it be acceptable to have > filtering done at the source end of that SMTP connection? > As soon as we step upstream this way, stepping up earlier still is merely > a question of efficacy and efficiency. Actually, if it is my network I have the absolute right to control what comes in and what goes out. If I am a commercial entity and my paying customers like this, then I will make lots of money. If they don't, I will go out of business. Thus for self-interest and survival end-user-networks do not restrict outbound excessively but block inbound with various policies that strike a balance between paying customers going elsewhere and paying customers leaving for less controlled environments, while still making a profit and staying in business. Hence, we end up with the situation that we have. It won't change without either (a) every operator deciding to do the same thing for their own collective best interest (such as blocking outbound TCP/25); or, (b) external fascist forces. And the bit-movers really don't care, since all they do is move bits...and more bits means more money. From jbates at brightok.net Mon Oct 31 22:46:24 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Oct 2011 22:46:24 -0500 Subject: Outgoing SMTP Servers In-Reply-To: <7C2677B5-9AF4-4E4D-8FFD-259320B8E5E7@drtel.com> References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <4EAA28A4.6010605@dcrocker.net> <4EADA347.3020109@dcrocker.net> <4EAE26F3.8060401@dcrocker.net> <4EAED155.8040604@mtcc.com>, <4EAEE9A0.30200@brightok.net> <7C2677B5-9AF4-4E4D-8FFD-259320B8E5E7@drtel.com> Message-ID: <4EAF6B90.70002@brightok.net> On 10/31/2011 8:12 PM, Brian Johnson wrote: > > Sent from my iPad > > On Oct 31, 2011, at 1:30 PM, "Jack Bates" wrote: > >> >> On 10/31/2011 11:48 AM, Michael Thomas wrote: >>> I've often wondered the same thing as to what the resistance is to outbound >>> filtering is. I can think of a few possibilities: >>> >>> 1) cost of filtering >>> 2) false positives >>> 3) really _not_ wanting to know about abuse >> On the other hand, you have >> >> 1) cost of tracking >> 2) support costs handling infections >> >> It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. > Let me know when u can "fix" the root causes. The two I know of: > 1. Bad actors > 2. Clueless users > While true, from a security viewpoint, the root cause is loss of control over the system involved. Spam, while perhaps the most visible and annoying to others is not my highest concern (We find the number of clueless users direct spamming is miniscule compared to hijacked systems). My concern is that the customer has lost control of their machine and could at that moment be unknowingly giving out critical information. -Jack From swhyte at gmail.com Mon Oct 31 23:00:58 2011 From: swhyte at gmail.com (Scott Whyte) Date: Mon, 31 Oct 2011 21:00:58 -0700 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: References: <5948995898631926267@unknownmsgid> Message-ID: <4EAF6EFA.5000702@gmail.com> On 10/31/11 19:33 , Justine Sherry wrote: > :) I should've guessed that you guys, of all people, would notice the > discrepancy. > > I used to be at the UW; I registered for this list using my UW email > address. Rather than re-register in order to be able to post to the > list, I just sent from my old email address. > > The survey is linked from my homepage and the UW affiliation is mentioned: > http://www.eecs.berkeley.edu/~justine/ I've met Justine and can vouch for her serious, laser-focused interest in middlebox research, and that if she's not really attending Cal then she's bamboozled a whole heap of CS profs over there. But seriously, if you can help her ascertain real middlebox use cases she wants to help improve that segment of networking via useful research, nothing more or less. -Scott > > Justine > > On Mon, Oct 31, 2011 at 19:23, Adefisayo Adegoke wrote: >> Hello Justine, >> >> I find it interesting, to say the least, that all of the communication >> that you have about a Berkeley research program while your email came >> from washington.edu? >> >> Thanks, >> >> 'Ayo >> >> ..... Success is getting what you want, happiness is wanting what you >> get - Ingrid Bergman >> >> ... the sky is too low to be my limit ....Sent from my iPhone >> >> On Oct 31, 2011, at 6:48 PM, Justine Sherry wrote: >> >>> Hello! My name is Justine and I am a graduate student at UC Berkeley >>> (http://cs.berkeley.edu/~justine). >>> >>> I'm doing a research project on middlebox appliances such as proxies, >>> WAN optimizers, and firewalls. Middlebox appliances are any >>> networking-related hardware other than routers and switches. I'd like >>> to learn a little bit about how middleboxes are used in real world >>> deployments in enterprises. Vendors often engage in surveys of this >>> type - but the research community knows less than we'd like to about >>> typical concerns in an enterprise network. >>> >>> If you work on network management in an enterprise, I'd love to hear >>> about your experiences through this survey: >>> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >>> >>> Some promises: >>> (1) If you give me your email address, I will not give it to anyone >>> else, nor will I add you to any annoying mailing lists. >>> (2) If you mention the name of your organization, I will not share it >>> with anyone else. >>> (3) If I publish any data from this, statistics will be reported in aggregate. >>> (4) I will not share the raw data from this survey with anyone other >>> than my advisor, Professor Sylvia Ratnasamy >>> (sylvia at eecs.berkeley.edu). >>> >>> Feel free to skip questions and please provide approximate answers if >>> you have them. >>> >>> Finally, to thank you for your time, we'll enter you in to a lottery >>> for a $100 Amazon gift card; we'll select two people to win and >>> contact them on November 16. Thank you! >>> >>> If you have any questions or concerns, please contact me. >>> >>> Justine >>> >>> PS: The survey is here! Don't miss it! >>> https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 >>> >> > From jbates at brightok.net Mon Oct 31 23:13:23 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Oct 2011 23:13:23 -0500 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <4EAF6EFA.5000702@gmail.com> References: <5948995898631926267@unknownmsgid> <4EAF6EFA.5000702@gmail.com> Message-ID: <4EAF71E3.7030406@brightok.net> On 10/31/2011 11:00 PM, Scott Whyte wrote: > But seriously, if you can help her ascertain real middlebox use cases > she wants to help improve that segment of networking via useful > research, nothing more or less. Would love to see the results, although it definitely is catered more to enterprise than ISP (where many of these are probably used more than in enterprise). It's missing a small datapoint. What types of failures are most likely to occur?(Physical/electrical, Misconfiguration, Overload) Layer-3 Routers - SOFTWARE BUGS! : ) -Jack From cb.list6 at gmail.com Mon Oct 31 23:44:21 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 31 Oct 2011 21:44:21 -0700 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <4EAF71E3.7030406@brightok.net> References: <5948995898631926267@unknownmsgid> <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net> Message-ID: On Oct 31, 2011 9:13 PM, "Jack Bates" wrote: > > On 10/31/2011 11:00 PM, Scott Whyte wrote: >> >> But seriously, if you can help her ascertain real middlebox use cases she wants to help improve that segment of networking via useful research, nothing more or less. > > > Would love to see the results, although it definitely is catered more to enterprise than ISP (where many of these are probably used more than in enterprise). > Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn. Given that these middle box infested ISPs are supposed to be providing "internet", that seems like more fertile research grounds, as the definition of internet is starting to shift ...at least imho. Cb > It's missing a small datapoint. What types of failures are most likely to occur?(Physical/electrical, Misconfiguration, Overload) > > Layer-3 Routers - SOFTWARE BUGS! > > : ) > > -Jack >