Directly connect to your corpnet with IPsec and IPv6
Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.
At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)
I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:
- Windows Vista Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)
- That are domain-joined
- Users run as non-admin
- Group policy applies numerous settings
- UAC is enabled
- BitLocker is configured to protect confidential information stored offline
- The Windows Firewall is enabled
- NAP is used for checking health
- Forefront Client Security for keeping malware off the box
- Smart cards for strong authentication of users
- IPsec is required for connection authentication and traffic encryption
- IPv6 is required for worldwide Internet connectivity
- A DNS suffix search list represents the data center name space
- Static IPv6 DNS servers provide name resolution for hosts in the data center
What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)
Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!
Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).
Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.
Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"https://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.
For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.
My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.
I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I’ve already described my view of the network of the future in my article here. IPv6 is very mature and well-defined. I’m not sure why you think it’s far away? If you read my article, you’ll note that we are running IPv6 on our own corpnet now, and it (along with IPsec) is the foundation of “anywhere access,” which we are running right now. You’re asking a lot of questions that seem to indicate an unawareness of the capabilities of modern networking protocols. I’d suggest you settle down with a few good books and websites to get up to speed on IPv6. Perhaps you can begin with http://www.microsoft.com/ipv6.Anonymous
January 01, 2003
I blogged some time ago about the " Shrinking Enterprise " and wouldn't it be neat if we could do awayAnonymous
January 01, 2003
How do you define "defense in depth"? Layers of networks with firewalls between each one does not equal defense in depth. Misconfigured firewalls could be equally problematic, and no amout of even perfect firewalling will stop attacks targeted at vulnerable applications. Testing your IPsec policies is critical here; Vista's simplified IPsec policies make it much easier. The border router drops anything that isn't IPsec, and the servers will drop any IPsec requests that they can't authenticate. There's plenty of depth in the direct connect design, it's just implemented difrerently. Some of the controls are on the host, whose configuration is set and validated by computers in the data center. Other security controls are in the data center itself.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Adrian... The guy merely said it's possible. smile Security is a myth and control is an illusion. I'm with you completely about the oversimplified aspect of the implementations but you only presented the perspective of the users and implementors. What about those who actually have the power to change things ? Cause the solution, as stated, is here. ISP owners now has something other than price per subscription they could use as competitive edge. Hardware vendors also will set a side some budget to bet on this "just in case". Enteprise software might add this into the feature... and so on. I remember the time where everybody thought tcp/ip was too complicated to be worldwide. I also remember some people thought netbios will be "anywhere". So calm down... The guy merely said it's possible. wider smileAnonymous
January 01, 2003
Fixed the wording about Business edition and Software assurance upgrades. Thanks guys.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Steve, Great post - even the argumentative responses! My question is how you feel about the security community's never-ending need to do stateful packet inspection on this traffic which would now be encrypted with IPSec. I've spent hours arguing with absentminded security folks who fail to see the future of networks as you do. They are always a proponent of VPN (or IPSec) termination points so they can do packet inspection on traffic in the clear. Their contention is that a host could be infected, then begin attacks which are wrapped in encrypted end-to-end IPSec packets - thus losing the ability to "detect" and attack. I hate the idea that these "professionals" continue to think that IDS/IPS is the answer. Until they can detect unknown attacks, signature based anything will continue to be behind the curve. Am I wrong and is this still a valid way to think about network security? Or is the average security professional that out of touch with how we should architecting the next generation of networks. Btw, thanks for all the good info! -joe cAnonymous
June 25, 2008
Hey Steve, I was there when you gave that talk, nice drawings on the tablet ;) Seriously, I'm so glad you showed us a way to secure our environment that doesn't require any additional tools. I'm sure you will agree that the real challenge here is to convince the upper management, not the IT world... Thanks for posting this, I can forward this to my boss and hope for the best ;)Anonymous
June 30, 2008
I think you'll have to convince the security people, not the upper management. As a security guy, this idea has tantalized me for years, but I've always viewed it with a healthy dose of skepticism. The problem, as I see it, is that there's no defense in depth. A misconfiguration on the IPSec side can expose your whole infrastructure to risk. Or am I missing something?Anonymous
July 03, 2008
The comment has been removedAnonymous
July 25, 2008
The comment has been removedAnonymous
July 29, 2008
The comment has been removedAnonymous
July 29, 2008
The comment has been removedAnonymous
July 30, 2008
The comment has been removedAnonymous
July 30, 2008
@Steve Yes, no patience, but a lack of patience in a good way. Speaking about XP, I won't say all, 'cause I might have missed some, most docs on Microsoft site say that Teredo does only work with symmetric NAT devices on Vista or Win2008 and if you are behind such a NAT device with XP or Win 2003, game's over with Teredo, thus no-go IPv6. My quick tests showed the same thing. Maybe a change that I did not catch occurred ? So Vista might be required. Personal I did not found any references about AYIYA on Microsoft's web site, I just thought to mentioned it anyway as I was not sure of its status. The value of a chart might be for some the "kind of pressure" IMHO. Many people like charts. A good chart will not show 100%. Having such a statistic, indeed will be useless. The price has to do with anywhere, just imagine that I'm sitting in a hotel behind a restrictive firewall, so no IPv6 connectivity. The next door coffeeshop charges me, how it would sound to call the management and say, look I need 1$ for Internet access in order to get working the new thousands of dollars "true access from anywhere solution", and they would reply: "but you have free Internet in your hotel, we checked this aspect when we've made the reservation". Wow, that would not be nice. Just to stress you a little bit, OpenVPN works through a web proxy which could require certian forms of auth, and is a full network connectivity solution(if we talk only about its connectivity possibilities) So after all, for now, anywhere = find any connection that will work. @Paulius I'm cool... Very cool... And smiling as well... I really like to spin the anywhere wheel... I've presented only those aspects, because speaking about the ones that have the power to change things we're entering the theoretical land, a territory I wanted to avoid as much as possible. I wanted to keep things in the now time frame and in our hands, because that's all about, to make it with what we have, on our own, and not to depend on X or Y. I'm not saying that IPv6 is extremely complicated, I'm just treating it with a lot of respect because I want to do things correctly. --AdrianAnonymous
July 31, 2008
"...So after all, for now, anywhere = find any connection that will work...." Proves the x and y is not entirely theoritical. And with... "...I'll take any connection I can get, and make my IPv6 direct connection on top of it...." I find it fascinating that with all this argument, I believe the BOTH of you are trying to say the SAME thing ! :DAnonymous
August 15, 2008
The comment has been removedAnonymous
September 09, 2008
Hi Steve after seeing you at techEd Australia Ive pretty much sold my management that we can do this and we should do this, bring on the instruction set :)Anonymous
September 11, 2008
The comment has been removedAnonymous
September 11, 2008
The comment has been removedAnonymous
September 14, 2008
The comment has been removedAnonymous
January 26, 2009
The comment has been removedAnonymous
February 11, 2009
I was reading the DirectAccess Early Adopter’s Guide, and it looks I have to take my words back... IP-HTTPS will be here, so the idea of "anywhere" might be indeed true... And in the OS arena, Windows 7 promises to be a hit... Adrian