January 2010 - Test - lists.nanog.org

Blocking only Facebook Apps
by Xaver Aerni 06 Jan '10

06 Jan '10

Hello, We have differents company here, they would only block the Apps from Facebook. Facebook self could be open. It give a methode to block only the Apps by firewall. If we haven't a methode we must block facebook in difference bigger companies... Greetings Xaver Xariffusion Informatik & Telecom Zürichstrasse 10a 8340 Hinwil Switerzland Tel. +41 43 843 7878 +1 707 361 6839

3 2

RE: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)
by msokolov＠ivan.Harhan.ORG 06 Jan '10

06 Jan '10

Frank Bulk - iName.com <frnkblk(a)iname.com> wrote: > It's being done by Actelis, Hatteras, and Zhone. More exactly SHDSL or ^^^^^^^^^^^^^^^^^^^^^ > similar variants. The market is being well-served. ^^^^^^^^^^^^^^^^^ The highlighted sentence is precisely the difference between what they are doing and what I am doing. The SHDSL folks seem to live in some kind of fantasy world where they think that all major network operators are going to throw out all their SDSL/2B1Q infrastructure and install SHDSL DSLAMs across the country instead. My SDSL work on the other hand is oriented toward working with the existing SDSL/2B1Q infrastructure massily deployed across USA by networks like Covad and what used to be DSL.net (now part of MegaPath). My Open SDSL Connectivity Project has successfully reverse-engineered the proprietary SDSL/2B1Q flavors used by the DSLAM brands deployed by the two networks named above, and I want to build bonded SDSL CPE for those flavors/networks. And yes, I have already had discussions with some people at both of the named companies. It wasn't even necessary for me to initiate contact with them as both of them have sought my open source project out and contacted me on their own about this very idea of SDSL bonding. However, despite lots of excited talk, both dialogues have ended with a mutter. Apparently there is some kind of wall of arrogance that prevents those folks from even considering getting their CPE from a mosquito like me, even though I can deliver it for one-tenth to one-hundredth of what the big vendors would want for the same thing if they would even consider building such - those big vendors have plenty of their own arrogance! Therefore, my next angle of approach is to see if there are any ISPs who go through Covad or through MegaPath's ex-DSL.net component as their Layer 2 transport (I know that at least in Covad's case there is a huge number of ISPs large and small who do that) and who want bonded SDSL badly enough to punch through that wall of arrogance. If you are an ISP who rents Layer 2 transport from Covad and I were to supply you the CPE, I think you should be able to serve bonded SDSL to your customers without having to beg Covad to descend from the heavens and give that service its blessing. Just order 2 (or 3 or 4 or however many loops you want to bond) ATM transport pipes from Covad terminating at your customer's address on one end and at your DS3/ATM interconnection point on the other end. Have your Cisco/Redback/whatever router run PPPoA on each of those ATM pipes and do MLPPP bonding between them. All that would be needed then is the CPE, and that's what the Open SDSL Connectivity Project is for... MS

2 1

Level3 voice rep
by Carlos Alcantar 05 Jan '10

05 Jan '10

Does anyone have a level3 tdm voice rep ? that they don't mind sharing thanks in advance. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos(a)race.com

1 0

Request for Information - IPv6 Routing Table Snapshots
by Michael K. Smith - Adhost 05 Jan '10

05 Jan '10

Hello Everyone: I am requesting the assistance of operators who are receiving full IPv6 routing tables from upstream, transit providers. If you could send me a copy of your full IPv6 table, as plain text or whatever format best suits, I would be sincerely grateful. I am doing some preliminary work on a potential NANOG presentation regarding the differences in IPv6 routing tables presentation from various "large" transit providers, because I've seen some oddities in announcement variations between several of them and want to dig deeper. Sadly, I only have two v6 transit providers, although I've had a third in the past and will again in the near future, so I will have 3 tables to compare. It would be good to have as many sample objects as possible. Please note this isn't a matter of looking at the global routing table from a looking glass - I'm interested to see what each provider is presenting to their customer, and extrapolating internal policies and potential pitfalls in the future as IPv6 is deployed in earnest. I have tables from NTT, TWTC and HE already. If you could add to this I would be grateful. Please feel free to contact me directly with any questions or concerns as well. Kind Regards, Mike Smith -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith(a)adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

3 3

Re: I don't need no stinking firewall!
by William Herrin 05 Jan '10

05 Jan '10

On Tue, Jan 5, 2010 at 3:16 PM, Brian Johnson <bjohnson(a)drtel.com> wrote: > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? A firewall is anything that examines IP packets in-line for the purpose of discarding undesirable packets before they can be interpreted by the transport layer protocol (e.g. TCP) on the endpoint computer. A firewall is usually a computer filling in the same slot as a router in a network topology capable of discarding packets before they can reach the endpoint computer at all. In some cases though, a firewall may be a separate piece of software on the same computer sending or receiving the packet. The purpose of the firewall is to permit the protected equipment to operate with a less thorough (hence less expensive) attention to the network security process. Can't really afford to have a dedicated network security guru for every dozen desktops playing big brother with what software the users are using so you focus your attention on the border instead. Stateful inspection is useful when you want the firewall to discard any packets which are not part of a communications session that the firewall understands and has approved. By contrast, packet filtering will only discard those packets explicitly deemed bad. At a practical level, the above distinction can be a noop. Internal machines are usually incapable of acting on packets the packet filter will unintentionally pass, such as IP fragments without the first fragment. Stateful address-overloaded NAT offers additional protection over stateful inspection alone in that the firewall naturally "fails closed." That is, a malfunctioning firewall will drop acceptable packets rather than allow bad ones. This is "defense in depth." An error in the filtering process still leaves the firewall with no idea which internal machine to transmit the errantly cleared packet to; that information was only available as part of the session state. By contrast, stateful, packet filtering and non-overloaded NAT firewalls are always able to send the packet to an internal machine once it passes the filtering rules. This last is part of what makes the little "DSL routers" such useful weapons in the network security professional's arsenal. Regards, Bill Herrin -- William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

1 0

Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)
by msokolov＠ivan.Harhan.ORG 05 Jan '10

05 Jan '10

Frank Bulk - iName.com <frnkblk(a)iname.com> wrote: > We offer it, but practically speaking we haven't gotten much higher than 1.5 > Mbps on the upstream. Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? I have spent the past 5 years of my life learning everything there is to know about SDSL. Don't ask me why, I don't really know the answer to that question myself. I won't waste the bandwidth of this elite list with dirty details of just what I've done with SDSL over the past 5 y, but I'll give a link to an open source project that contains the body of SDSL knowledge amassed over those years: http://ifctfvax.Harhan.ORG/OpenSDSL/ To make the long story short, for most of those years I kept trudging on my project, treating it as an ultra-weird hobby that no one else in the world could possibly have any interest in. That persisted until 2009 when my project got noticed by two fairly major North American DSL network operators. (Well, one very major and one semi-major, but I'll spare the names.) Both of those had contacted me via my Open SDSL Connectivity Project expressing interest in SDSL bonding. Both companies were telling me how much interest they had in SDSL bonding, how much it would help their business to be able to offer bonded SDSL services at 3 or 6 Mbps, how many customers they would be able to sign up for these services, etc. But when I asked them to back their verbally-expressed interest with the tiniest amount of money or even no money at all but a letter of intent which I could show to SBA etc, they both went silent. We've been playing a game of cat-and-mouse ever since. As far as I could understand the existing situation is that the SDSL infrastructure already deployed en masse by the major North American DSL network operators already has the capability to serve out bonded SDSL circuits, bonding either in the DSLAM or somewhere upstream of it, using MLPPP, Multilink Frame Relay or whatever else one can think of, but the problem is with CPE. Apparently bonding-capable multiport SDSL CPE devices are quite scarce. Considering everything I've done with SDSL over the past 5 y, I believe I have a right to say with confidence that I am more than capable of designing and building a bonding-capable multiport SDSL CPE device for any existing SDSL flavor with any desired number of ports (2, 4 or whatever). But what I don't know, and what I'm asking this highly esteemed list for advice with, is this question: is there anyone at all in the world who might have a real serious interest in such a thing? If there is someone in the world who would truly appreciate having a bonded SDSL solution, I would be delighted to work on developing such a thing. I would see it as a service to humanity whereby more use would be made out of existing copper infrastructure in the ground instead of having to dig more ditches to bury more fiber or whatever. But if there is no one in the world who would be interested in bonded SDSL (or at least interested enough to invest one dime into development), then why bother... MS

4 5

Query regarding maintenance menu on Liebert PeX units
by Sam Silvester 05 Jan '10

05 Jan '10

Hi all, Sorry if this isn't the best place to be posting such a question, but I figured there may well be a few aircon experts around. I've got a few Liebert PeX 3100FA units and we're in the process of commissioning some additional units. The installing contractors are trying to hunt down the maintenance menu PIN as it appears there has been a bit of a breakdown of communications between the installing contractors and the distributer who have decided to keep that detail rather close to their chests - I'm trying to short-circuit the process to keep things moving! Offlist is fine to keep the noise down. Thanks, Sam

1 0

Re: Request for Information - IPv6 Routing Table Snapshots
by mkarir 05 Jan '10

05 Jan '10

You could also try asking the BGP bot which has a couple of views. AIM: bgpbotz Jabber: bgpbotz(a)jabber.research.merit.edu help examples show ip bgp view show bgp view RS-SWITCH ipv6 -manish > Date: Tue, 05 Jan 2010 08:13:44 -0800 > From: Joel Jaeggli <joelja(a)bogus.com> > Subject: Re: Request for Information - IPv6 Routing Table Snapshots > To: "Michael K. Smith - Adhost" <mksmith(a)adhost.com> > Cc: nanog(a)nanog.org > Message-ID: <4B436538.2000508(a)bogus.com> > Content-Type: text/plain; charset=UTF-8 > > you might take a look at route-views6.routeviews.org > > last I looked it had 22 neighbors. > > you can either telnet to it (it's quagga) or look in the archived > ribs here: > > http://archive.routeviews.org/route-views6/bgpdata/ > > Michael K. Smith - Adhost wrote: >> Hello Everyone: >> >> I am requesting the assistance of operators who are receiving full >> IPv6 >> routing tables from upstream, transit providers. If you could send >> me a >> copy of your full IPv6 table, as plain text or whatever format best >> suits, I would be sincerely grateful. >> >> I am doing some preliminary work on a potential NANOG presentation >> regarding the differences in IPv6 routing tables presentation from >> various "large" transit providers, because I've seen some oddities in >> announcement variations between several of them and want to dig >> deeper. >> Sadly, I only have two v6 transit providers, although I've had a >> third >> in the past and will again in the near future, so I will have 3 >> tables >> to compare. It would be good to have as many sample objects as >> possible. >> >> Please note this isn't a matter of looking at the global routing >> table >> from a looking glass - I'm interested to see what each provider is >> presenting to their customer, and extrapolating internal policies and >> potential pitfalls in the future as IPv6 is deployed in earnest. >> >> I have tables from NTT, TWTC and HE already. If you could add to >> this I >> would be grateful. Please feel free to contact me directly with any >> questions or concerns as well. >> >> Kind Regards, >> >> Mike Smith >> >> -- >> Michael K. Smith - CISSP, GSEC, GISP >> Chief Technical Officer - Adhost Internet LLC mksmith(a)adhost.com >> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >> >

1 0

Re: D/DoS mitigation hardware/software needed.
by Jeffrey Lyon 05 Jan '10

05 Jan '10

1. We have multiple nodes conducting DDoS scrubbing, one failing would not be catastrophic. 2. Indeed. 3. Sort of, such devices are downstream for extremely valid reasons I won't get into now. 4. Indeed, were equipped to handle substantially higher than 150kpps. I'm sure Arbor is really neat but I disagree that any DDoS appliance is a standalone solution. I don't expect an employee of the vendor themselves to attest to this though. Best regards, Jeff Best regards, Jeff On Jan 4, 2010 10:14 PM, "Suresh Ramasubramanian" <ops.lists(a)gmail.com> wrote: On Tue, Jan 5, 2010 at 8:36 AM, Jeffrey Lyon <jeffrey.lyon(a)blacklotus.net> wrote: > We have such a c... So .. this is interesting. The firewall would have to frontend your mail / web / whatever application .. and if something goes beyond the firewall's rated capacity (100k ++ - maybe nearly 150..175k connections per second for a high end firewall), the firewall falls over. And even before that, there's the risk of whatever application you're protecting getting pounded flat if your firewall passes even a small percentage of this traffic. Do you - 1. Have (say) two firewalls in HA config? 2. Back your firewall with routing based measures, S/RTBH, blackhole communities your upstream offers, etc [the standard nspsec bootcamp stuff] 3. Simply back the firewall with a netflow based device? 4. Estimate that the risk of a DDoS that exceeds your firewall's rated capacity is extremely low? [and yes, 150k ++ connections per second ddos is going to be massive, and relatively rare for most people] --srs -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

11 29

Re: D/DoS mitigation hardware/software needed.
by Jeffrey Lyon 05 Jan '10

05 Jan '10

We have such a configuration in progress, it works great without any of the issues you're proposing. Jeff On Jan 4, 2010 9:09 PM, "Dobbins, Roland" <rdobbins(a)arbor.net> wrote: On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > Use a robust firewall such as a Netscreen in fro... Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. ----------------------------------------------------------------------- Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

4 13