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:
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 '"http://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.
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 ;)
Fixed the wording about Business edition and Software assurance upgrades. Thanks guys.
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?
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.
Hey Steve, I was attending the 2 sessions you recently had in Norway. I kind of remember that you talked about a Teledo gateway (which was running Linux....ugh!) and if I understood you correctly you placed this as the gateway between corpnet and internet. I have read up on the function of Teledo and the only reason I can think of you need to put a Teledo gateway in here is to do some 4to6 conversion. Is that correct? Does this mean that the corpnet only run pure ipv6 (no teledo tunneling over ipv4). Does this also mean that if we also run ipv4 on the corpnet that we can do this without the Teledo gateway (as we then can use the public available Teledo broker service)?
By the way. I have start talking about this to the upper management and they totaly buy the simplicity and benefits this will have.....hey, who does not want Outlook Anywhere functionality for all services?. This is great stuff! Also thanks for the idea you gave me in the 1:1 session about using Federation between intranet AD and our "customer" AD and the use of IAG so we can get rid of the replication problems out to our DMZ networks.
Interesting idea, Steve. Check out my observations at http://blogs.windowsecurity.com/shinder/2008/07/23/death-of-the-dmz-redux/
I was reading about it in Tom's blog yesterday.
I've just stopped when IPv6 and now were mentioned (Tom moved into a more technical discussion).
It would be interesting to hear how the network of the future looks to you regarding its infrastructure.
Is IPv6 a mature technology, a well defined one ?
How would you know how it would be like in the future?
IPv6 is far away, and anywhere+IPv6 even further away.
From anywhere ?
Please, just define anywhere, will you ?
"It DOES NOT depend on how remote hosts have obtained their own IPv6 connectivity (native IPv6, tunnel broker [RFC3053], softwires [RFC4925], Teredo [RFC4380], 6rd [thisdraft]...)."
Do we have a time schedule to say when it will only be IPv6, as at this moment it looks like there it will be a lot of co-existence, which is yet to be defined ?
We can only hope that IPv6 deployments will be done carefully, otherwise, we will end up with a mess.
Even Teredo is not here yet. This one introduces its own security risks. Are we ready to deal with it, do we fully understand its security, what firewalls can hadle it ?
Is there any plan to be followed, a clean path, so that we can talk at this moment about the network of the future having a practical solution?
"The common thinking for the last 10+ years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4. It has not happened."
How would you know that there would be no NAT in IPv6 ?
"> Worst case, it doesn't get used and we have this nice utopian NAT-free IPv6 network.
No, that's the best case. The worst case is that it encourages vendors to implement it and corporate IT folk to deploy it."
"> Can you say the same for the worst-case situation for NOT standardizing v6 NAT?
That's a very hard question to answer, because it depends very much on how CPE and firewall vendors react in their product plans. Since they all know that NAT isn't needed for IPv6, and product managers are not known for funding unnecessary work, in the best case, it doesn't get implemented. In the worst case, it gets implemented randomly."
Medieval gateways, maybe, how about IPv6, this is a technology from the 90s, would it be still possible to call it a modern technology, when it would be eventually deployed at a large scale ?
How is it possible to achieve a "now" security solution combining a present solution(the list of technologies from Microsoft you've mentioned) with a theoretical and not well defined one, the IPv6 of the future ?
Have we fully understood the security in practice of IPv6 ?
How it would look your list of technologies say, in 2015(just a date, no allusion) ?
Correct me, but your design appears to be based on "My test corpnet" looks like the Internet ?
Can you sustain with a time graph your interesting solutions ?
Who knows, I might be a boring old man before IPv6-only will exist....
Wouldn't be more feasible to say, it's time to start "piloting this very idea on your internal corpnet", and to define the boundaries of this corpnet ?
If will it be the network of the future without "boundaries", it's just an unanswerable question in this moment, IMHO. Just because it will take a lot of joint efforts to happen. And "joint" does not have a good reputation.
By the way, looking forward to the "October issue".
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.
Oh my, oh my!
I really do appreciate your concerns about my level of "awareness" regarding modern network technologies and the fact that you want me to be a well informed man.
I might have some for you as well:
It's just my personal feeling that you did not understand the nature of my questions.
My questions were not asked just because I personal do not know how to answer them.
I'm talking about the REAL world here.
The way you described the "network of the future", this future appears to be a very close one, although you do not place it in a specific period.
The fact that you already run IPv6 on your own corpnet is pretty much meaningless regarding the big picture.
Your article just and only assumes that your corpnet network is a simulation at a small scale of the future "Internet".
Your article just and only assumes that anywhere I would be in the world, I would enjoy the same benefits and face the same problems that your corpnet is currently experimenting.
Which is deeply wrong. Hey, this is just IMHO.
When I'm saying that IPv6 is far away I'm not talking about an IPv6 network here and one there.
I'm talking about big scale deployments all arround the world.
If I would contact my ISP right now, and ask them about IPv6, I would get an answer like "say what" ?
In fact, my ISP(one of the biggest from my country), just a couple of months ago replaced their customers old IPv4 equipment with new IPv4 only ones.
In the REAL world, there are currently small vendors involved in the ISP area which DO NOT have any product incorporating IPv6, IPv6 being just on their roadmap.
It would take a lot of efforts from vendors, ISPs and yes, the end customer(either is a company or a home user) to make it be only IPv6 everywhere.
Funny question though, how many of the networking guys out there are "IPv6 ready", as they are also part of the efforts too...
As described in your article, IPv6 is a must everywhere I would be, at home, in a hotel, on a wireless campus...
Here's another one for you:
There are plenty of them:
Please don't send me where I've been, there is just an awful big number of "will" there.
One more time, I'm questioning the expandability of your design into the REAL big world in respect with the "overall infrastructure" supporting it.
And you have no answers for that, you just imagine that this will be somehow, magically there, knocking on the door.... anywhere...
Personal I do not "buy" that.
These are REAL world problems, questions to answer, and interesting, there are a lot of people out there wondering about...
I would really appreciate if you would leave my "ignorance" to rest in peace.
Quite frankly, my "ignorance" about the near feature is mainly focused on TMG or UAG.
Near future just means to me a couple of years.
Interesting though, you seem to contradict yourself a little bit, because you do not throw away completely the gateways or the perimeter. So there is nothing really to count down for.
Just plenty to dream about.
Oh, and I suppose the silver bullet named Teredo was not prepared for me, as we're talking here, for example, of anywhere.
I'm sorry if I offended you, that certainly wasn't my intention. We can spend an eternity reading IETF drafts and dicussion lists, or we can take the technologies available today and build an environment where the distinction between the Internet and a corpnet evaporates. You ask for a specific time period, yet reject my answer, despite the evidence.
As I've described, the technology is here now. You're asking for the real world, yet not acknowledging that the building blocks already exist (no "magic" or "door-knocking" required). Nowhere have I claimed that "my test corpnet looks like the Internet." Rather, I describe how one can use the existing Internet, along with existing technologies in current products, to achieve the kind of perimeter reduction that every customer I talk to is clammoring for. Of course I encourage people to pilot it first -- that's why I'm writing and speaking about it, and that's why I'm working on more detailed guidance. Yes, it takes some work to get to this point, but it's work that's entirely possible now.
I've seen presentations about IPv6 deployment (or lack thereof). Do you suppose that the reason for low deployment is that no one has had a need to? While some of us netheads love it for its protocol pureness, people do things only when there's an economic incentive. The US hasn't adopted the metric system because to do so is very expensive -- and the rest of the world is perfectly happy to convert from metric to imperial when doing business with the US. Someday it'll cost the US more *not* to convert, then it will. Same with IPv6: up until now, there's been no economic incentive that overcomes the cost. Well, finally, a reason is arising -- one that enables mobility experiences not available previously, and organizations large and small are seeing this.
To address a couple specific points of yours -- first: traditional gateways. I've already described why traditional gateways won't disappear anytime soon, because the distinction between trusted and untrusted endpoints won't go away. There's no contradiction here, and I'm not sure how you read that into my explanation.
Second: the idea of "anywhere." Apparently you don't believe me when I say that it works anywhere. How can I convince you that it does? I've successfully operated in this environment in 30 countries on six continents, from homes and airports and hotels and offices, over wired and wireless and tethered Bluetooth -- all kinds of Internet connections, really. Never have I had to check whether IPv6 is enabled by an ISP or allowed through some random router, because my computer automatically uses one of many transition technologies (yes, even Teredo, although I'm right now verifying the extent of server-side Teredo support) included in the operating system. So I'm not sure why you claim otherwise. "Only IPv6 everywhere" is neither a requirement nor a desire.
Rather than worrying about what other people think about IPv6 and its capabilities or pervasiveness, which will only delay migration, why not take the plunge and build a test lab similar to what I've described, and help accelerate change? I predict you'll be pleasantly surprised.
Don't worry, I was not offended, just amused.
It's an old habit and pleasure of mine to read RFCs.
Actually, I do have a test IPv6 network in my lab.
It does not do what you describe, it's just my little game.
It was not my intention to find a reason why IPv6 was not adopted at a large scale, just to simply point out that it takes time, and we have to be patient.
Actually it's quite simple why I cannot be convinced by the idea of anywhere.
Because of the co-existence of IPv4 and IPv6 in the near future, IMHO, thinking of your solution while being on the road, unfortunately I'm back to where I've been before, to the hope and prey game.
What if I'm behind one of "those" IPv4 NAT device ?
Although Microsoft put a lot of efforts in making Teredo work with most NAT devices, including symmetric ones, I do not know this as a fact.
I know that it is only supposed to work. Your results show that indeed it appears to work.
So I can hope.
Maybe AYIYA can help me. I do not know this either as a fact.
Let me assume that the NAT device is not a problem, maybe the NAT vendors read the existing informational RFC :).
What if I'm behind a restrictive IPv4 firewall which does NAT and forces me to use a web proxy too(I already have some places on my mind)?
Only HTTP and HTTPS are allowed to the Internet.
Looks like I'm screwed. I can't have IPv6 connectivity.
Teredo can't help. Neither AYIYA.
So I can prey. I suppose that "connectivity price" is taking into equation too.
Interesting Teredo combined with IPsec might improve my personal network security, however Teredo has quite the opposite effect to the network from where I'm connecting, if allowed.
So the security folks, might follow the idea spread in press, that it is a good idea to block Teredo on their network firewall. Anyway, if the firewall was indeed a firewall, meaning really allowing only needed traffic, I could not use Teredo in the first place. Neither AYIYA.
It was just a quick thought of mine, that if IPv6 native support would be everywhere, true access from anywhere might work. But I do not know this as a fact, I'm just imagining. Someone may return to me my own words like: what if you are stuck behind a proprietary IPv6 NAT device. I would just say, whatever, I will just wait and see, too early to call.
I do not argue that the pieces are here(I'm aware of the existing networking equipment from various vendors too), nor that you have it working already. That would be stupid, because I would say that you are lying.
As said above, I do not believe that indeed access from anywhere is a feasible possibility even with your solution.
The gateways will still be there to complement this issue along with other problems like the existence of non-Vista machines(the market share is not that good for Vista, personal I've contributed to that, buying an XP OS to replace the x32 Vista edition on my laptop, although now I'm thinking to buy a x64 Vista one), which will result in my opinion in the existence of a dual architecture, and this should be taken to the management group. That's why I did not start to deeply evaluate the security of your solution vs let's say, the traditional one.
I have a question for you regarding anywhere, since you was able to test access from many places around the world, did you had time to create some statistics, like a chart showing the successful connectivity rate of your solution vs a SSL VPN solution (I'm making no allusions to the security afforded by each solution), maybe taking the price of the connectivity into equation(as for example I can pay for wireless Internet or I could get it for free) ?
According to your last post, we will have a 100% success rate with your solution, so it would be interesting to see the results for a SSL VPN solution. Although 100% results are usually hard to swallow.
Hmm, haven't you already noticed that me worrying about what other people think is not an aspect that concerns me:). I was just saying that some IPv6 technical aspects have not been clearly defined yet, and they are currently discussed.
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 smile*
But Adrian, I don't want to be patient, and my customers don't want to be patient. My customers have real business problems to solve, and I'm giving them a technical architecture they can use right now. This is exactly the kind of presssure we need to get the RFC-naval-gazers to get off their duffs :)
You can sit behind as many IPv4 NAT gateways as you want and it still works. What do you think sits in every airport, hotel, and home network? Yet my direct connect works every time.
AYIYA is not one of our supported transition technologies, and we have no plans to implement it. Teredo, 6to4, and ISATAP are better solutions.
SSL VPNs are a different beast. These are more appropriately viewed as application proxies. You're right, if you're visiting some site where they allow only outbound HTTPS, then that breaks not only IPv6 direct connect but also all traditional IPv4 VPNs, too. This is orthogonal to the discussion of IPv6 direct connect.
If you want to move the conversation to operating systems, I can tell you that Vista certainly isn't a requirement. It makes the most sense for two reasons:
1. Vista includes built-in BitLocker volume encryption, which is extremely important when users with managed laptops need to carry confidential data offline. This eliminates the threat of data interception from stolen machines.
2. Vista user account control makes it easier to build an environment where users run as non-admin.
You can accomplish IPv6 direct connect with XP as well -- all the other technologies in my list are supported. We can even include MacOS and Linux, since with the proper add-ons they support IPv6, IPsec, and NAP. But you do lose the ability to centrally control configuration through group policy.
I'm lost why you think charts have any value. Such a chart would show 100% success for every attempt of mine. What value is that? And what does the price of connectivity have to do with anything? I can't control how much a hotel or a coffeeshop charges for Internet access. I'll take any connection I can get, and make my IPv6 direct connection on top of it.
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.
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.