forkb0mb.org - Routing

The nerd-net

nospam@example.com (TJE) — Fri, 03 Feb 2012 18:58:19 -0500

The nerd-net

Notice:

I do not yet have all of the hardware and networking gear set up on my network; so this is merely a description of what I'm looking to do, to gather some ideas and feedback, and then figure out how to proceed. If, after reading the details below, you want to join, or have suggestions, please let me know!

History / Ideas

I've been thinking about starting a "nerd net" for quite some time. I have many friends that use a Linux/*BSD machine at their border, and typically have some kind of services running inside the network. I'd like to link these networks together and share access to services. This opens up all kinds of possibilities...

Network

To avoid a single point of failure, and saturation of any one network's bandwidth, we would avoid linking in a hub-and-spoke fashion. Instead, I propose that we maintain a list of active nodes (essentially, each person's gateway box) and try to maintain at least 3 active VPN connections at a time. In other words, each node on the network would have a VPN tunnel to at least 3 other nodes. It would be very useful to have control of a DNS zone for maintaining this list. Each node would have it's own A record; say, mynode.domain.com. Each time a node wants to connect to the network, it would request the A record for something like connect.domain.com, which would hand out A records of each of the registered nodes in a round-robin fashion.

Authentication will be central in this; so some knowledge of SSL will be beneficial. I, and possibly a few key others, would maintain access to a CA signing key and the nodes would be authenticated to the network via certificates signed by that CA key. Any node that you attempt to connect to should trust you based on that certificate; and, based on the certificate presented, you should trust any connection attempt with a valid, signed certificate. I, and possibly others, can assist with any certificate-based configuration issues that you might have.

Routing

To allow for a private network that's going to be potentially changing topology on a regular basis, we'll need a routing protocol, such as RIPv2. For simplicity, each network would receive it's own /24 of RFC1918 space, with the gateway box running the VPN software being the "node" on the network. Most likely, you'd want to set up split-tunneling on the gateway box so that any requests going to the private network route over the VPN and the rest of your traffic (web surfing, email, etc) goes out your normal internet connection.

With each node on the network being connected to at least 3 other nodes at any given time, that requires us to keep track of the various routes from one network to another. Instead of trying to keep track of this by hand, we could easily set up RIPv2 and announce the routes we "know". I imagine using netblocks in the 172.16.0.0/12 range, with each network having a /24 and being multi-homed (connected to 3+ other nodes), there could potentially be several routes from one network to the other. A light-weight, distance-vector routing protocol like RIPv2 seems to be a good fit; open-source implementations, simple, and proven. The route to any network from yours would be the one with the least intermittent hops.

Another, more complex, possibility would be using OSPF and OpenBSD's open-source implementation. Given that each node will have different bandwidth, this may be a good idea to try.

Services and other ideas

This would be the whole reason for the network!

I would be interested in providing several services to the network, but not publicly. For one, a Linux- or FreeBSD-based shell server with access to the internet, compilers/development tools, documentation, email (anyone remember pine+procmail?), etc. A (small-ish) public web space to let people know that you're part of the network; something like Apache's mod_userdir. A blog application accessible only from within the nerd-net.

I would also maintain the internal network's intranet site. This could be a site used to post updates of system maintenance, new services being offered/tested, and a way to maintain an up-to-date list of all of the nodes.

A private IRC server is definitely on the TODO list. Any and all bots would be allowed; if anyone would be interested in linking the IRC daemons, I'll likely be using the Blackened or UltimateIRCd.

I could provide SMTP services for the network. If we find a zone to use, I can provide email services for that zone. Technically, unlimited user@zone email addresses. I would also be willing to host DNS services for the internal network; providing dynamic DNS and a "view" for those coming in via the network.

Another service I'd consider offering would be your own PostgreSQL database for development and testing. A big part of what I envision for this network is that it'll be a big collection of computer-savvy geeks; what better place to deploy and test code than on a network inhabited solely by those with the clue to help you in debugging, vuln testing, etc.

Other possibilities include shared-CPU time using tools like distcc(1). Maybe remote storage (NFS/iSCSI)?

Requirements

a public IP address to allow for incoming VPN connection requests

a Unix-like machine (Linux, Solaris, *BSD, MacOS/X)

OpenSWAN, FreeSWAN, OpenVPN, etc for creating the VPN

Zebra for RIPv2, OpenBSD OpenOSPFd for routing

Benefits

The benefits of a private network are many, and extend beyond just the sharing of services. This is a chance to build a real-world, potentially large-scale network with changing topology. Any member wishing to add/configure new services or features is welcomed to; and the services could be advertised/listed on the internal network's intranet site.

Other benefits include the ability to policy-route certain traffic. For instance, I would be interested in routing my DNS traffic over the VPN to be routed out someone else's connection; it's low traffic, but my ISP mangles my DNS traffic to route to their servers regardless of what server I point to. Such configuration could even be set up where my DNS traffic goes out through a different VPN's node each time (i.e., a type of load-balancing).

Responsibilities

As the network uses a VPN to set up, exactly what it is, a Virtual Private Network, we should seek to keep the network private. Configuring an Apache reverse-proxy, or some type of port-forward from your external IP address into the network would be frowned upon. Any need to create such accesses for the outside should be discussed with the entire group, and hopefully some sort of consensus reached.

It would also be the responsibility of each node's owner to keep the machine secure and up-to-date. Any breach of one of the nodes would lead to an open route to the network.

Users/Networks

I will create the CA key used to sign all certificates used to access the VPN; but, as I do not wish to be the sole decider in who is allowed on the network and who is not, I plan to create a handful of sub-CA certificates to be distributed to trusted associates who may also sign certificates for potential users. If you've been given a sub-CA certificate, you're being trusted to know who you're letting into our private little clubhouse. :) Using multiple sub-CA certificates will also allow for anyone to validate who provided access for this particular user/network; and the ability to revoke access as necessary (hoping that it wouldn't ever become necessary).

Conclusion

A "nerd net" would be a fun project to gather a bunch of us geeks together and share services. This is the first time I'm really throwing the idea out there (beyond mentioning it to a few people here and there), so if anyone else thinks it would be fun, get ahold of me!

CRTC Tells Rogers to Stop Slowing Down the Speed of Online Games

nospam@example.com (TJE) — Fri, 16 Sep 2011 21:56:41 -0400

CRTC Tells Rogers to Stop Slowing Down the Speed of Online Games

Canada's telecommunications regulator on Friday gave Rogers Communications Inc., mere days to come up with a plan to solve a problem that could be unfairly slowing down the speed of online games.

[...]

Rogers now has until Sept. 27 to present a plan to the regulator to deal with the issue.

[...]

While Internet service providers have said they need to manage online traffic to deal with network congestion during peak hours, the CRTC has instituted a policy stipulating that the noticeable degradation of time-sensitive Internet traffic requires prior commission approval under Canada's Telecommunications Act.

/*
Emphasis is my own. This is my entire point:

If they're having bandwidth issues during peak-usage, then they are over-subscribing their bandwith ( and/or maxing out the capabilities of their network infrastructure ) and customers notice. Customers also tend to vote with their dollars.
*/

Survey: Most Enterprises Will be on IPv6 by 2013

nospam@example.com (TJE) — Thu, 28 Jul 2011 12:21:02 -0400

Survey: Most Enterprises Will be on IPv6 by 2013

IT professionals overwhelmingly say they want their companies to be leaders not laggards in IPv6 adoption, Network World survey finds.

/*
Warning: This article contains a slideshow.

Otherwise, it's pretty interesting to see how important IPv6 adoption has become in the networking world now that it's starting to sink-in that IPv4-space is quickly dwindling. See here. The last /8's were allocated in early February 2011.
*/

Tunneling nmap through Tor

nospam@example.com (TJE) — Thu, 28 Jul 2011 12:11:34 -0400

Tunneling nmap through Tor

I looked at how to reduce your exposure using Tor earlier in the week. We installed Tor and Privoxy and configured our system to browse the Internet anonymously. We can use Tor and another great program called proxychains to Torify our network scans with nmap.

/*
I checked this out and it seems to work well. Other than the fact that Tor doesn't seem to carry UDP traffic (other than DNS) or ICMP traffic, you're limited to TCP traffic alone, which isn't too much of a limitation.

It is a little slow getting your scan results back - especially if you don't pass -p<port1>,<port2> to nmap(1), but it's certainly more secure than just trying to use an open proxy server out on the 'net.

All in all, a neat trick.
*/

Two /8s allocated to APNIC from IANA

nospam@example.com (TJE) — Thu, 10 Feb 2011 08:26:53 -0500

Two /8s allocated to APNIC from IANA

APNIC received the following IPv4 address blocks from IANA in February 2011 and will be making allocations from these ranges in the near future:

39/8

106/8

/*
The allocation of these blocks left the IANA with 5 /8 blocks left; which triggers a clause saying that when the pool gets down to 5 remaining blocks, each of the 5 *NICs get one of the remaining blocks. It's just unfortunate that 2 of the last 6 or 7 blocks are completely wasted by being routed to what essentially amounts to an Internet cesspool (APNIC). I regularly pull down the IANA assignments, parse out the netblocks assigned to APNIC, and then null-route them all.

Note: The aforementioned clause is stated in the "Global policy for the allocation of the remaining IPv4 address space."

*/

/*
Here's a ticker, from Hurricane Electric, that estimates the eventual exhaustion of IPv4 addresses from the regional registries.

You might take this time to register for a block of IPv6 addresses - It's free!

*/

Secret Forum Reveals Oz Firewall Backroom Dealing

nospam@example.com (TJE) — Mon, 17 May 2010 00:56:52 -0400

Secret Forum Reveals Oz Firewall Backroom Dealing

Circumvention legal, but you can't tell anyone how[.]

/*
Emphasis is theirs.

Now say what? It will be legal to circumvent (technical details at the bottom), but illegal to explain to someone else how to perform this perfectly legal configuration. I wonder how this might affect a corporate or ISP helpdesk perform VPN connectivity setup?
*/

Australia’s plans for a firewall to protect its population from smut on the internet are rapidly evolving from farce to total chaos. Weekly revelations on bulletin boards suggest that Stephen Conroy, the man behind the big idea, does not know what forthcoming legislation on the topic will say, when it will be introduced or how the firewall will work in practice.

/*
This time, emphasis is mine. I want to continue to point out how big of an asshat this particular Australian politician is. He is the "Minister for Broadband, Communications and the Digital Economy." He's the one that floated the idea of this nation-wide "firewall" (which is technically a proxy since it will be filtering at layer 7 - hence the technical problems) to "protect" citizens from illegal, immoral, or "dangerous" content. This is nearly the same thing the Chinese and Iranians are doing, just using layer 7 proxy devices instead of what's assumed to be basic layer 3 IP filtering of destination hosts. Skip to the very end of the post for the technical details behind this.

To say this whole thing began as a farce is hitting the nail right on the head.
*/

Meanwhile, it turns out that the Minister’s own Department of Broadband, Communications and the Digital Economy (DBCDE) has been hosting a secret forum for discussions with ISPs likely to be affected by proposals. Along the way it floated the idea of making it a crime to advise surfers on how to do things that are perfectly legal to do. Confused? You will be.

First up is the time scale for plans to introduce the new firewall. As already reported, the question of when legislation will be introduced has now been bouncing between the offices of Prime Minister Kevin Rudd and Communications Minister Stephen Conroy. Severe wriggling from Conroy’s office suggests that plans for an early introduction of legislation have been put on the back burner for now.

/*
Conroy wants to shelve the legislation until after the elections. He's technically incompetent, but he's smart enough to realize that this is going to be a screw-up of biblical proportions and it will likely cost him the election. It's "on the back burner for now," but it's by no means dead.
*/

Meanwhile further digging inside this forum revealed that departmental officials appear to have been discussing the possibility of making it a criminal offen[s]e to advise individuals of means that would enable them to circumvent the filter – even where the means themselves were perfectly legal.

/*
I would say that this equates to information being illegal. In a way, that's in the same league as banning books.
*/

As the EFA suggests, this answer raises more issues than it addresses, and relies on the degradation of the Australian network being gradual, rather than catastrophic. It does appear, however, that the government has no plans to deal with a possible overload of its firewall bringing the Australian internet to its knees – beyond setting up a review when such an event actually happens.

/*
Why should there be any degradation of bandwidth at all? I suspect that if this goes through, there's going to be a noticeable difference in download speeds and initial access to websites.
*/

/*
Details:

Circumvention:
Circumvention of these filters will be trivial; you can wrap your request in SSL (such as https:// if the website supports it), by using a VPN provider outside Australia (many more found on the link for the word "using"), by using Tor (which uses a technique known as Onion Routing), or even by viewing blocked pages via the Google cache.

Technical Considerations:
This filtering is to take place with proxies (at the Application [7] layer) as opposed to the traditional large-scale deployments of firewalls (at the Network [3] and Transport [4]) layers). The deeper you have to inspect a packet, the more CPU and memory required to process the filters. It costs - in many ways, from actual dollars for the hardware and software, to performance impact, to configuration complexity to man-hours of maintenance - considerably more to filter at layer 7 with a proxy than layers 3/4 with a firewall.

The one benefit to filtering at layer 7 is that you block only what is intended to be blocked. In today's world (where we've been running out of IPv4 space for a dacade now) a lot of websites are configured using virtual hosts. This allows web hosting providers to host a virtually unlimited number of websites on a single IP address. Let's say there are two websites, both hosted on the same virtual host IP address, where one is banned and the other is not:

www.bannedwebsite.co.au (banned)
www.momsrecipies.co.au (allowed)

With a layer 7 proxy, when the user attempts to reach a website, the proxy intercepts the request, checks the request (including hostname and URI), and then either blocks the request, or requests the page on behalf of the end-user and returns her the requested webpage. So your mom can still access www.momsrecipes.co.au while nobody can access www.bannedwebsite.co.au. With a proxy, you can return HTML to the end-user explaining why access to this particular website is blocked and possibly a method of contact to dispute the denial of access.

Pros:
() Finer-grained control of what's filtered
() Less "false positives"
Cons:
() Expensive in many aspects (mentioned above)
() Complex configuration
() Considerable service impact due to use of DPI at Application [7] layer
() Slightly easier to circumvent; using https is the only circumvention measure mentioned that does not tend to work with the firewall approach - the rest should work against both types

With a layer 3/4 firewall, access to the virtual host IP address (or even the subnet it's part of) will be blocked. When anyone tries to go to www.bannedwebsite.co.au, they are unable to, which is the intended result. They will get a different error; the browser will just report that website was unreachable. End of explanation. If anyone tries to go to www.momsrecipies.co.au, they will also be denied with the same uninformative unreachable error. Since both websites are on the same IP address, the firewall has no way of knowing which website you're looking for, so it blocks everything.

Pros:
() Cheaper to deploy
() Simpler configuration - hundreds of hosts/subnets vs. thousands of hostnames
() Can often be implemented on existing hardware - edge or core routers utilization IP ACLs
() Faster, more responsive access to allowed websites; less service impact
Cons:
() Collateral damage - legitimate sites on the same virtual host as banned site are also blocked
() Slightly more difficult to circumvent (a websites https site will likely be in the same blocked subnet)

Comparison with Other Instances of State-Controlled Internet Access:
I see three major differences in the Australian proposal as opposed to the other major regimes implementing state-wide filtering of websites (China and Iran). They are as follows:

The use of layer 7 proxies instead of layer 3/4 firewalls and route filtering

In China and Iran the responsibility of implementing and maintaining the filters rests on the tier-1 to tier-2 network providers who bring capacity into the country. By filtering at this level, you are enforcing that ISPs block these sites along with everyone else in the country. By placing the responsibility on the ISP, who provides the access to the end-user, you are going to find that ISPs (a) will add/remove entries from the blocked list to fit their own agendas; (b) will suffer varying performance impact and quality of service based on their investment in the filtering technology and correctness of the implementation; (c) will raise prices to pay for increased hardware/software components, man-hours maintaining the systems, and extra capacity required to maintain a reasonable quality of service; and (d) some will become popular with a certain customer base due to being lax in their filter list updates and tendency to allow some banned content.

Another side effect of this proposal, from an economic standpoint, is that it is likely to put smaller ISPs out of business. Instead of putting the smaller burden on the backbone providers, with considerably more capital, it will place a more expensive burden on ISPs with less resources at their disposal. If these filters become legally mandatory, this will likely put smaller ISPs out of business. A smaller provider may not have access to the resources (money, manpower, and know-how) to meet these requirements and will thus have to shut down operations.

The third difference is in the legality and enforcement of the filters. In the Australian proposal, it will be legal to circumvent the filters provided you know how. In China, they are known for randomly allowing then blocking then allowing access to certain websites and enforcement is relatively low. Occasionally they will decide to make an example of someone, and they will end up in prison. In Iran, enforcement is rather strong, with penalties ranging from prison time to possibly "disappearing".

Other Thoughts:
There is one other somewhat commonly used filtering technique involving DNS. The ISP or corporate gateway will transparently route all DNS requests by the end-user to DNS servers under their control. The DNS servers will be configured as authoritative for the blocked domains; typically configured to return an IP address that connects you to a website telling you that your access is blocked and possibly why. This is similar to the Walled Garden approach.

*/

Rough Justice for Terry Childs

nospam@example.com (TJE) — Wed, 28 Apr 2010 17:58:46 -0400

Rough Justice for Terry Childs

A San Francisco jury found Terry Childs guilty of one count of felony denial of service yesterday. The count carries a maximum sentence of five years in prison. Considering that he's already served nearly two years to date, he may actually be released on parole at his June 14 sentencing hearing, or he may be facing another three years behind bars. His lawyers stated that they will appeal.

/*
This ruling brings a chill to my spine. While Childs could have handled the situation with a little more grace, I don't believe that any crime was actually committed. I've worked under some pretty shoddy conditions before - lack of procedures, lack of accountability - but this sets precedent for criminal prosecution.

Knowing firsthand how difficult this would be, I'd have just let the lackluster-at-best management sink. I would have turned over the passwords along with my resignation. Anyone with a CCIE can find another job, even in this economy. If it comes down to risking my freedom and clean criminal record because my boss is a moron, then it's time to move on. I can't imagine how painful it would have to be to create such a complex, intricate system, only to have to turn it over to inept cretins who will undoubtedly destroy it.
*/

IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated

nospam@example.com (TJE) — Sun, 24 Jan 2010 21:37:46 -0500

IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated

"A total of 16,777,216 IP address numbers were just allocated to the Asian Pacific Network Information Centre IP address registry for assignment to users. Some venerable IP addresses such as 1.1.1.1 and 1.2.3.4 have been officially assigned to the registry itself temporarily, for testing as part of the DEBOGON project. The major address blocks 1.0.0.0/8 and 27.0.0.0/8, are chosen accordance with a decision by ICANN to assign the least-desirable remaining IP address ranges to the largest regional registries first, reserving most more desirable blocks of addresses for the African and Latin American internet users, instead of North America, Europe, or Asia. In other words: of the 256 major networks in IPv4, only 24 network blocks remain unallocated in the global free pool, and many of the remaining networks have been tainted or made less desirable by unofficial users who attempted an end-run around the registration process, and treated 'RESERVED' IP addresses as 'freely available' for their own internal use. This allocation is right on target with projected IPv4 consumption and was predicted by the IPv4 report, which has continuously and reliably estimated global pool IP address exhaustion for late 2011 and regional registry exhaustion by late 2012. So, does your enterprise intranet use any unofficial address ranges for private networks?"

/*
The content of this post was shamelessly ripped from the front page of Slashdot.
*/

/*
The IANA still shows 1.0.0.0/8 and 27.0.0.0/8 as being RESERVED and registered to them.

What burns my ass like 3 foot flames is that we're giving these dwindling IP blocks to countries that shouldn't even be allowed to participate in the global internet! As I've stated before, on my own private network, for my own protection, I null-route all blocks allocated to APNIC, whether they've been sub-allocated out yet or not.

I say we pull all of China's IP space. With their "Great Firewall of China," they've made it clear that they don't want their citizens participating in the global Internet, anyway. I say that we pull all of their routable IP space, give them -- let's be generous here -- a /20 to NAT behind, and let them use RFC1918-space for every machine in their god-forsaken country. If they use RFC1918-space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), that gives them a total of:
16,777,216 + 1,048,576 + 65,536 = 17,891,328 IP addresses to use.

Under this scenario, those of us who wish to rid ourselves of the useless packets (i.e., botnets and spam) spewing forth from this country, we can simply firewall or null-route a /20 and protect ourselves with better than 95% certainty. Sure, a few users will manage to VPN out to somewhere else in the world (*cough*Russia*cough) and wreak havoc from there, but it still keeps the vast majority off our Internet. I am sure that you could convince management to allow you to block a /20, even in the enterprise, a lot easier that wide swaths of /8s.
*/

/*
In regards to corporations "borrowing" publicly routable IP space; I've seen it first-hand. I worked for a fairly large company in the financial sector, whose network was probably designed around the time I was born. They decided they were going to use 88.0.0.0/8 for their internal addressing scheme. Why not 10.0.0.0/8 you ask? It has the same amount of IP addresses; but the answer eluded me. With hundreds of branch locations all routing into their internal network, then through proxy servers, and finally out to the real Internet, this got to be quite a mess. We had to create a special route on the proxy pairs that linked directly to the ingress routers so that when a user needed to access a site whose IP just so happened to reside in 88.0.0.0/8, we'd have a special allow rule for that host/domain name that bypassed the traditional routing. I guess it's a good thing that they were bought out and their services either integrated or deprecated.
*/

Law Firm Suing China Hit By Cyber Attack

nospam@example.com (TJE) — Sun, 17 Jan 2010 07:40:59 -0500

Law Firm Suing China Hit By Cyber Attack

Last week, Santa Barbara, Calif.-based CYBERsitter sued the People's Republic of China, the two Chinese software makers, and seven computer manufacturers for distributing Web filtering software known as Green Dam with allegedly stolen code.

This week, the law firm representing the company said that it had been targeted in a cyber attack from China.

In a phone interview, Elliot B. Gipson of Gipson Hoffman & Pancione described what amounts to a spear-phishing attack -- the same technique used against Google in China. "They were e-mails targeted at individuals in our law firm that were made to appears as if they were coming from other individuals at our law firm," he said. "They attempted to get the target to click on a link or attachment."

/*
It looks like China is at it again. When will our government say "enough is enough?"

Given that we've "outsourced" essentially all of our manufacturing jobs to China, India, and Mexico, all we have left to power our economy is our ingenuity; our intellectual property. The Chinese government has made little effort to hide the fact that they are behind these attacks.

I'm really starting to favor a new "Cold War," this time against China. We toppled the Soviet Union without firing a single shot; there's no reason we couldn't do the same to China. With carefully coordinated electronic attacks, we could cripple their booming economy and leave them in ruins without risking one single American life.

For those who have no reason to receive email, or other network traffic, from China and the other "problem children" in APNIC, here is a list of subnets that are managed by APNIC. You may wish to null-route all of them, or fine-tune the list to your needs.

*/

Graphical Network Simulator 3

nospam@example.com (TJE) — Tue, 08 Dec 2009 03:17:43 -0500

Graphical Network Simulator 3

/*
This simulator is absolutely awesome. It requires that you have the Cisco IOS images as it comes with a MIPS emulator and actually emulates a real Cisco router, switch, or PIX firewall. It's so realistic that you can design a network, configure the routers and switches, and then drop the running configurations onto real network gear.

It certainly helps to have plenty of RAM available to run this. 1 GB or more is almost a necessity.
*/

Why is the Internet So Infuriatingly Slow?

nospam@example.com (TJE) — Sun, 07 Sep 2008 23:41:31 -0400

Why is the Internet So Infuriatingly Slow?
Plus, two horrible things your Internet service provider wants to do to make it speedier.

Everyone hates their Internet service provider. And with good cause: In the age of ubiquitous Internet access, Web service in America is still often frustratingly slow. Tired of being the villain, telecom companies have assigned blame for this problem to a new bad guy. He's called the "bandwidth hog," and it's his fault that streaming video on your computer looks more like a slide show than a movie. The major ISPs all tell a similar story: A mere 5 percent of their customers are using around 50 percent of the bandwidth—sometimes more during peak hours. While these "power users" are sharing three-gig movies and playing online games, poor granny is twiddling her thumbs waiting for Ancestry.com to load.

/*
I can't say I believe their argument that everyone hates their ISP. I don't hate mine. Long gone are the days of the independent ISPs, so for bandwidth reasons I've gone with Big Cable. I can't complain about the 10 Mb service. I've probably gotten between 2 and 3 9's as far as availability.

I've spent almost the entirety of the last 10 years working in various capacities - ranging from front-line tech support to Unix engineering and on-site network technician - in the ISP world. I've worked at independent ISPs, Big Telco, Big Cable, and a transit provider. Far and wide, the vast majority of the customers I spoke with liked their service and was very friendly and cooperative.
*/

The ISPs are certainly correct that there's a problem: The current network in the United States struggles to accommodate everyone, and the barbarians at the gate—voice-over-IP telephony, live video streams, high-def movies—threaten to drown the grid. (This Deloitte report has a good treatment of that eventuality.) It's less clear that the telecom companies, fixated as they are on the bandwidth hogs, are doing a good job of managing the problem and planning for the future. The ISPs have put forward two big ideas, in recent months, about how to fix our bandwidth crisis. We can arrange these plans into two categories: horrible now and horrible later.

/*
I don't see the "struggle," either. Considering my experience in a wide range of ISP/ASP/NSP roles, I've never seen backbone and/or uplink capacity as a major concern. There was always plenty of bandwidth to go around, and they were already planning the "new" network design to bring in even more.

I'm beginning to wonder if this isn't more of a willful restriction of bandwidth to create an artificially low supply thus driving up prices (read: profits) on the demand side.
*/

/* On the topic of paying per GB for internet access: */
The criticism is easy to condense: No one joyrides in a taxi. A plan like this, as its many opponents have noted, will cramp the freewheeling, inventive nature of the Internet. The Internet owes its success to two pillars of human activity: masturbation and procrastination. (Seriously: We have the porn companies to thank for pioneering all sorts of technologies, from VHS to secure credit-card transactions online.) Is the Internet really the Internet if people don't use it to waste time?

/*
Finally, a kernel of truth to this article! You know you've had too much internet when you're too lazy to rub one out.
*/

Beyond that, capping data transfer is simply a crude way to get people to curb their data appetites. Imposing limits on gigabytes per month is as sensible as replacing speed limits with a total number of miles you can drive in a given day. A more reasonable scenario—though one that's still decidedly unfun—would be to charge for Internet access as we charge for cell phones, running the meter during peak hours and letting people surf and download for free on nights and weekends, when there's far less competition for bandwidth.

/*
I guess the pay hours/free hours would be about the opposite of internet traffic. It's those 3:30 - 4:00 PM and 5:30 - 6:30 PM spans when you see the biggest spikes - people coming home from school or work and checking email, reading the news, playing online games, etc.

How many times have you set up a big download (like a Linux DVD ISO) before bed to just let it run overnight?
*/

Comcast now says it will pursue a more compliant strategy that slows the connections of power users during peak times without singling out specific types of traffic. This tactic is similar to the more general practice of "traffic shaping": prioritizing data packets for applications like video that shouldn't lag at the expense of something like e-mail, which can wait in line an extra few seconds without anyone noticing—except that it's deprioritizing users, not data packets. (People who hate the concept of traffic shaping prefer to call this "throttling" or "choking.")

/*
I have no problem whatsoever with basic QoS. Obviously you'll want to give higher precedence to things like VoIP and video conferencing to keep latency as low as possible, but there should be enough bandwidth that nobody gets "starved." Rate-limiting just for the sake of "throttling" is evil.
*/

This plan is "horrible later" because it fails to account for the natural evolution of the Web toward larger file sizes and higher bandwidth activities. While it isn't a God-given right to be able to downloaded pirated DVDs all day long, the ISPs should not adopt a long-term strategy that penalizes high-bandwidth activity. As FCC commissioner Robert M. McDowell pointed out in the Washington Post a few weeks ago, this is not the first time we've reached a crisis level of congestion. If Time Warner and Comcast had structured their networks around anti-bandwidth-hogging policies, say, 20 years ago, revolutionary services like YouTube and BitTorrent might not even exist.

/*
I'm certain that they would not. If we had signed away our rights to the internet as quickly as we did our telco infrastructure, good old corporate greed would have ensured that we had the slowest average internet access in the industrialized world.

I do find the joke about pirated DVDs worth a chuckle.
*/

Cold, hard cache. Shortly before the start of the 2008 Olympics, some commentators feared the global network wouldn't be able to handle all the demand for streaming Web video. The fact that the Internet didn't "melt," as one ZDNet author feared, set tongues wagging about NBC's use of third-party "content-delivery networks." To deliver nonlive content, these companies can store popular content on many different servers around the country—a method of ensuring that data packets don't have to travel as far to reach their destination. In general, your machine will retrieve information much faster from a "nearby" server on the network than from one across the globe. If a copy of the movie you want is stored by your ISP on a local server, you'll both get it faster and hold up fewer people in the process.

/*
How many times have we heard "chicken little" foretelling of an "internet meltdown?" It's not going to happen, people. There's a lot of really smart people who get paid to make sure those things don't happen.

It certainly makes sense to use things like Anycast to serve content as close to the subscriber as possible. The fewer hops it is to your destination, theoretically, the faster you should be able to get your content.
*/

Interesting Bit of iptables(8) Hackery

nospam@example.com (TJE) — Thu, 22 May 2008 16:59:13 -0400

/*
A while back, I set up a transparent Squid proxy at my border to limit my exposure to "drive-by downloads." It's a pretty standard setup; Squid running on the gateway/firewall, and iptables configured to route all tcp/80 traffic back into itself on port 3128.

An unfortunate side effect of this is that tcptraceroute breaks. As port 80 is the default port that tcptraceroute uses (as the destination port), you end up with a traceroute that looks something like this:

(root@desktop1) ~# tcptraceroute www.ebay.com Selected device eth0, address 172.25.X.XXX, port 39068 for outgoing packets Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max 1 hp-core.ebay.com (66.135.200.145) [open] 0.558 ms 0.384 ms 0.315 ms

I can assure you, I'm not 1 hop off from www.ebay.com. Since iptables is mangling the packet at the very first hop, my gateway/firewall, I'm receiving the SYN-ACK from that first hop.

Keep in mind, tcptraceroute will use any destination port you specify, but the default is port 80 since it's usually allowed through most firewalls, and often open.

Given that the default TTL of a Linux-based computer is 64, I can use the TTL match in iptables to selectively capture what tcp/80 traffic goes to the proxy and what does not. Consider the following rule:

iptables -t nat -A PREROUTING -i $IF_INT -p tcp --dport 80 \ -j DNAT --to-destination 172.25.X.XXX:3128

This is the rule that routes all outbound traffic, originating on the internal network, to the Squid proxy. Now if we change that rule to match only packets with a TTL larger than, say, 48, we end up with the following:

iptables -t nat -A PREROUTING -m ttl --ttl-gt 48 -i $IF_INT -p tcp --dport 80 \ -j DNAT --to-destination 172.25.X.XXX:3128

With this rule in place, a tcptraceroute headed for www.ebay.com on tcp/80 looks more like the following:

(root@desktop1) ~# tcptraceroute -f6 www.ebay.com Selected device eth0, address 172.25.X.XXX, port 57684 for outgoing packets Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max 6 so-1-2-0.gar2.chi1.bbnplanet.net (4.79.74.1) 76.668 ms 23.024 ms 30.840 ms 7 ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158) 57.014 ms 34.438 ms 36.097 ms 8 ae-68.ebr3.Chicago1.Level3.net (4.69.134.58) 25.716 ms 22.857 ms 32.941 ms 9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 84.660 ms 49.091 ms 40.722 ms 10 ae-1-100.ebr1.Denver1.Level3.net (4.69.132.37) 79.996 ms 52.921 ms 52.897 ms 11 ae-3.ebr2.SanJose1.Level3.net (4.69.132.57) 71.323 ms 70.999 ms 71.651 ms 12 ae-82-82.csw3.SanJose1.Level3.net (4.69.134.218) 66.468 ms 70.863 ms 72.099 ms 13 ae-32-89.car2.SanJose1.Level3.net (4.68.18.132) 65.688 ms 62.794 ms 59.597 ms 14 EBAY-INC.car2.SanJose1.Level3.net (166.90.140.134) 60.576 ms 65.507 ms 58.566 ms 15 10.6.1.158 71.070 ms 59.413 ms 59.670 ms 16 10.6.1.146 61.397 ms 88.846 ms 68.280 ms 17 hp-core.ebay.com (66.135.200.145) [open] 84.341 ms 59.523 ms 62.286 ms

Now that looks a little more reasonable. Given that I'm 1 hop off from the gateway/firewall, and Linux uses a default TTL of 64, then all of my packets generated by, say, Firefox, will come into $IF_INT with a TTL of 64. With 64 > 48, the DNAT rule matches, and the request gets routed through the Squid. As tcptraceroute works like any other traceroute tool, only using TCP SYN packets, the first packet will only have a TTL of 1. With 1 < 48, it does not match the DNAT rule, and passes through unchanged. The second packet will have a TTL of 2, with 2 < 48, and so on. As most all destinations on the internet are reachable in 30 hops or less, this guarantees that my browser generated requests are proxied, while my diagnostic requests are passed through unchanged.

You can view/change your default TTL as such:
(root@desktop1) ~# cat /proc/sys/net/ipv4/ip_default_ttl 64

Needless to say, the IP addresses have been changed to protect the innocent. ;)
*/

pfSense

nospam@example.com (TJE) — Thu, 20 Mar 2008 09:15:21 -0400

pfSense

/*
pfSense is (yet another) all-in-one router/firewall/VPN device. It's based on the m0n0wall firewall, so it's based on FreeBSD and the entire system configuration is contained in one XML file. The entire rc process is written in PHP, making the XML parsing easy and also allowing for easy extendability.

I've seen about a million of these all-in-one devices, but what sets this one apart for me is the GUI. This looks to be the simplest, yet most-powerful, all-inclusive web-based GUI I've seen on such a platform.

Here's a quick rundown of the features included:

SSL web interface
wireless support
stateful packet filtering
NAT (many-to-one/one-to-one)
PPPoE and PPTP support on the WAN interface
DHCP client/server
IPsec VPN tunnels (IKE; with support for hardware crypto cards and mobile clients)
PPTP VPN (with RADIUS server support)
caching DNS server
DynDNS support
SNMP agent
traffic shaping
configuration backup/restore
load balancing
bridging firewall ("invisible" firewall)
many others
*/

FCC Hints at Taking Action Against Comcast

nospam@example.com (TJE) — Fri, 14 Mar 2008 00:51:39 -0400

FCC Hints at Taking Action Against Comcast

The Federal Communications Commission is edging toward taking action against cable operator Comcast for monkeying with its customers' peer-to-peer traffic, according to several news reports.

On Friday [03/07/2008] FCC Chairman Kevin Martin indicated during a speech at Stanford University's Law School that the commission may take action against the cable operator, which has been accused of blocking or slowing down the peer-to-peer file sharing service BitTorrent on its broadband network.

Martin didn't say for certain that the FCC would take action against Comcast. But he did say that he was troubled by Comcast's initial denial of slowing or blocking traffic, according to news reports from people who attended the speech. What worried him most was the fact that Comcast wasn't forthcoming to its customers about what it was doing.

"A hallmark of what should be seen as a reasonable business practice is certainly whether or not the people engaging in that practice are willing to describe it publicly," The Wall Street Journal quoted Martin as saying.

/*
I completely agree. If my ISP is going to throttle or "shape" their network traffic, I believe that it should be completely transparent with it's customer base in what it is doing.

I've seen numbers kicked around on many lists such as the North American Network Operators Group (NANOG) reflecting the fact that roughly 10% of customers utilize more than 50% of the available bandwidth.

I've purchased what's known as "unlimited access" at 5 Mbit/sec (downstream), and I believe I am entitled to use up to 5 Mbit/sec at any time for any duration. That would be my definition of "unlimited access." I run MRTG on all of my active switchports as well as my 3-interface firewall/routing device; and I occasionally burst up to my full 5 Mbit/sec for anywhere from a few minutes to a few hours per day, but never around-the-clock.

The only way that an ISP can run into trouble with customers making full use of what they have purchased is when they are oversubscribing their bandwidth too much. Bandwidth is cheap these days, and if it requires me paying a small amount more (say, 5% - 10%) for my ISP to purchase additional bandwidth, then so be it.
*/

Martin has said he understands the need for companies to manage their networks. And he has said that reasonable network management practices are acceptable.

/*
Agreed. As I've been on both ends of this dispute, I recognize the need for network providers to protect their investment. What I do not agree with is network providers meddling with the customer's layer 7 data. As far as the provider is concerned, the customer is just passing IP traffic. They need not know what type of data is being carried over IP. Nor should they concern themselves with "imitating" the customer by injecting packets into the stream to throttle or limit traffic on a connection-by-connection basis.
*/

But now it looks like Chairman Martin, and by extension the commission, sees Comcast as going beyond simply managing its network. But even if the FCC decides that Comcast has violated Net neutrality principles, it's unclear what the agency can actually do to Comcast. The principles are not agency regulation. And there are no Net neutrality laws on the books, so it's hard to say what kind of enforcement the FCC can impose.

/*
While the FCC may not be able to directly punish Comcast, I believe the negative publicity will affect their "bottom line" and they will get the hint.
*/

Still, if the FCC finds that Comcast has violated its Net neutrality principles, it will be a big deal. In the past, carriers have argued that regulation and new laws were not needed because network operators had not abused their power as network gatekeepers. But if the FCC acknowledges that one major broadband provider has crossed this line, then it could add more weight to the arguments of those supporting Net neutrality legislation.

/*
Proof yet again that any industry that cannot self regulate will force the hands of government to intervene. The last thing the Internet needs is more government regulation. The entire spirit of the Internet is the lack of governmental boundaries and influence.
*/

Gunplay Blamed for Internet Slowdown

nospam@example.com (TJE) — Tue, 21 Aug 2007 14:56:25 -0400

Gunplay Blamed for Internet Slowdown

/*
Oddly enough, this was also a fairly regular problem for a previous employer w/ a large metro fiber ring when I lived in Cincinnati, OH.
*/