Using spackle to seal the bullet holes in your foot

Andre Duran blogged about decentralized security and used the following picture.

The caption reads: "So where do I deploy my firewall now?"
My answer is: "You don't. You're screwed." And because each of those entities at the edge are likely to have similar looking networks, you're screwed.
En masse.
The decentralized border discussion has irked me for years because it makes some very bad assumptions concerning trust. Not trust in people, but in their behavior. Just about anyone that has worked network security for any large firm will tell you that people tend to drift towards practices which require the least activity on their part. In other words, people tend to procrastinate and some are downright lazy. Unless you can guarantee that each of those border entities conform to the letter and intent of your security policies, you're screwed.
En masse.
Your corporate network should reach farther than you can walk in 15 minutes and should only have users whose connection to your internal network can be terminated without a lawyer. The guy who has the power to hire and fire should also be within a 15 minute walk of your office (his pace, not yours).
Decentralized security (the transparent border) has been a rationalization used to spend less money on security and to justify the convenience of teleworking with minimal spending.
External people need access to a service or data set? Good. Stick that service in a DMZ and restrict who can access that. Even better, give them a laptop configured so that it is only capable of connecting to your DMZ. Block your internal users from accessing the DMZ too. If you have to supply access from between the internal network and the DMZ, use an application proxy and limit what can go through where, when (yes time limits) and how.
The only company whose network diagram should look like the picture above is one who gives away network access for free and doesn't require passwords. (In other words, they have no service or data set, only connectivity.)
Yeah, we're going to need identity-based security to be able to use IPv6, but that technology isn't available yet. And don't go pushing NAC at me. That only works when you own the network from end to end (i.e., it's centralized security and won't work with a decentralized network).
Gunnary writes that security models must mirror the changes in business and technology or it's going to be broken. I think he's over-simplified the issue. While the company's "mission" may change greatly (moving from selling sneakers to MP3 players), the reason that the network is there changes little (provide word processing and access to the database).
Decentralized security only works when your users cannot exert changes in any part of the network or even on their local system. If any one of them can connect their node to any other network then there's going to be trouble (ask CNN to tell the story about their senior management and the Welchia worm). If they can connect to yours and the other at the same time, you're screwed.
En masse.
Here's a hint: if you have a firewall like what Gunnar describes, with thousands of open ports, then your security domain is too big and your security policy is too generic. They should both be broken into communities of interest and protected as separate entities.
Don't believe me? Go interview any Fortune 500 company. I'm willing to bet they partition off specific pieces of the network from their own users, not to mention the rest of the world.