IPsec and Domain Isolation

Everything You Always Wanted To Know About The Soft SA, But…

2005-12-16T01:43:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

What Is a “Soft” SA?

A soft SA is one in which the Negotiate security filter action is enabled, but there is no authentication or encryption being performed because the computer with which communication occurs is not running IPSec. This process is also known as fallback to clear. Even though the packet is not being protected, an SA without an AH or ESP header is still maintained in the SAD. Soft SAs and fallback to clear are possible only when Allow unsecured communication with non IPSec-aware computer is selected on the Security methods tab in the properties of a filter action.

When Fall back to clear is allowed, traffic is secured by IPsec when possible (if the computer at the other end of the connection supports IPsec with a complementary filter action and filter in its policy), but traffic can be sent unsecured if the peer does not have an IPsec policy to respond to the request for security negotiation. If the peer does not respond to the request for security negotiation within three seconds, an SA for plaintext traffic (a soft SA) is created. Soft SAs allow normal TCP/IP communication with no IPsec encapsulation to occur. Keep in mind that although IPsec might not secure such traffic, another application might help secure the traffic (for example, traffic might be secured by Lightweight Directory Access Protocol (LDAP) encryption or remote procedure call (RPC) authentication mechanisms). If the peer does respond within three seconds and the security negotiation fails, the communication that matches the corresponding filter is blocked.

However, IKE allows Fall back to clear only if there is no reply.

Soft SAs And Hardware Offloading

Hardware acceleration is accomplished by offloading specific processing tasks that are normally completed by an operating system component to the network adapter. Some network adapters can perform IPSec cryptographic functions, such as encryption and decryption of data and the calculation and verification of message authentication codes.

A check is made to determine whether the SA for the packet being offloaded is a soft SA. A soft SA is an SA in which no authentication or encryption is being performed because the computer with which communication occurs is not running IPSec. Because no AH or ESP headers need to be processed, hardware offloading is unnecessary.

[Note - My research so far has not made it clear whether this means the NIC actually does not allow the offload or they are telling you that it isn’t a good idea to this. I will follow-up when I have a better answer]

Soft SAs Lifetime

Soft SAs have a timeout of 5 minutes (this setting cannot be changed). This means that after a Soft SA is formed, the remote computer ca initiate communications with the local computer peer any time within this 5 minute window and not have to re-negotiate an SA. This means that if you are on a secured sever and establish a connection with someone on the network, they can re-establish a connection with that secure server (firewall aside) using the established soft SA.

Now, this situation doesn’t necessarily represent a huge security whole because the secure server IPsec policy must include the failback to clear option. But this can throw you off when you do your testing / troubleshooting. For example, if you are using either Request Security or Require Security you will expect to not be able to initiate a connection from your “non-secured” sever to a domain computer but you can. This might make it look like the policy doesn’t work right, when, in fact, it is working correctly, but the 5-minute timeout is the problem.

Soft SAs and Multicast / Broadcast Traffic

In some IPsec policy designs that use the filter option to “Allow unsecured communication with non-IPsec aware computer”, an attacker may be able to use multicast or broadcast traffic inbound to cause a destination computer to send a unicast response. This would then trigger an IKE negotiation outbound that will create a Soft SA packet and open the path for the attacker to connect. An attacker may construct an invalid TCP packet by using a multicast or broadcast destination address to try to bypass IPsec filters. If a program or protocol is running that requests to receive multicast or broadcast packets, the attacker may be able to communicate with that program if the attacker and the program both use only broadcast and multicast traffic.

What the Heck is the “Default Response Rule”?

2005-12-16T01:38:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

The default response rule is used to ensure that the peer computer responds to requests for secure communication. If the active policy does not have a rule defined for a computer that is requesting secure communication, then the default response rule is applied and security is negotiated. For example, when Computer A communicates securely with Computer B and Computer B does not have an inbound filter defined for Computer A, the default response rule is used.

The default response rule, which can be used for all policies, has the IP filter list of <Dynamic> and the filter action of Default Response when the list of rules is viewed with the IP Security Policies snap-in. The filter list of <Dynamic> indicates that the filter list is not configured, but that filters are created automatically based on the receipt of IKE negotiation packets.

The default response rule cannot be deleted, but it can be deactivated. It is activated for all of the default policies and you have the option of enabling it when you create new IPSec policies with the IP Security Policy Wizard.

The Default Response Rule and Security

A consequence of using the default response rule is that the peer computer can send unsecured data to a secured server after the quick mode SA and dynamic filter have timed out. These peer computers, also called “client computers” because they use the “Client” default security action, rely on the computer with which they are communicating to initiate secure communications. This reliance occurs both when communication is initiated and when it is resumed after a delay that is sufficient to time out a previously established quick mode SA and dynamic filter.

To prevent client computers from sending unsecured data to secure servers, you must configure your client computer IPSec policy with additional rules that initiate secured communications to secure servers.

If the secure server sends new data on the existing connection, it renegotiates the quick mode SA before sending this data to the client computer because a rule exists on the secure server to secure traffic between itself and all other computers.

The Default Response Rule and Firewalls

After the firewall is opened to allow the IKE and IPSec protocols, the firewall might not be able to inspect packets to control which traffic is secured by IPSec. IPSec policy filters determine which traffic IPSec can secure, so if you want only a specific protocol to flow between two peers, you must create IPSec filters that enforce this behavior. Port-specific filters can control the direction in which connections are made.

Therefore, if a computer is in a more trusted network (inside the firewall) and you want IPSec to secure traffic only over certain protocols and ports on that computer, do not enable the default response rule in the IPSec policy for that computer. If the default response rule is enabled and an attacker compromises the remote computer, the attacker might be able to modify the IPSec policy to negotiate security for all traffic through the firewall.

New IPsec Documentation Available

2005-12-05T23:12:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

Managing Intra-Windows Compatibility for IPsec
This paper includes information about managing intra-Windows compatibility among the IPsec-compatible Windows operating systems. This paper also includes information on regulatory compliance, Windows-based IPsec tools, and best practices. This paper is intended for IT professionals in organizations.

Changes In IPsec in Windows 2003 SP1

2005-12-05T22:54:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

The long and the short of it are that there aren’t any changes in IPsec that affect configuration. The (see, Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1) book of SP1 doesn’t have any entries specifically for IPsec. There are some performance and reliability enhancements, but nothing major. You Windows 2000 and Windows XP policies should work just fine on Windows Server 2003 SP1.

Does IPsec Do ‘Stateful’ Filtering?

2005-06-22T00:25:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

What Is ‘Stateful’ Filtering?
Stateful filtering is the type of packet filtering that firewalls do where the firewall records certain details from packets leaving the protected network and then compare any returning packets destined for the original sender of the packets. The firewall makes sure that the details of the packets coming in are the same as the details it recorded from the packets going out. If they match the packets are forwarded, if not the packets are dropped and an event raised.

Does IPsec Do This?
The simple answer is ‘No’. IPsec filters packets based upon a previously-agreed upon ‘contract’ called a ‘Security Association’ or SA. Packets accepted or dropped based upon the rules in an SA (the process is a bit more complex than this, but this is the observed outcome).

This filtering is very similar in the end result (packets are accepted or dropped based upon information in the packets), but different is where and when they happen. With IPsec, the packets are dropped by the IPsec peer when they reach the peer and not the firewall on behalf of the peer.

Can I Use Both For More Security?
Absolutely ‘Yes’ ! IPsec and firewalls of all types can work together to provide a better security than either alone.

How Do I Enable IPsec Traffic Through A Firewall?
For information about enabling IPsec through a firewall, see the Microsoft Knowledge Base article 233256 (http://support.microsoft.com/default.aspx?scid=kb;en-us;233256)

IPsec and Certificate Authentication

2005-06-21T03:11:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

There is some confusion over what role certificates have in IPsec. Some are thinking that the certificates are being used to encrypt the IPsec traffic - but this is not true. PKI certificates can be used to authenticate IPsec peers but cannot be used to encrypt traffic secured by IPsec.

However, using certificates is a great way to authenticate IPsec peers and even has some advantages over Kerberos v5 authentication, under certain circumstances. Certificates can be arranged in hierarchies that give them o good deal of flexibility in how peers trust each other’s certificates are set up. Also, certificates give you a third-party validation not available with Window’s implementation of Kerberos v5.

Certificates must be used under the following circumstances:

If the peers are in separate forests, then Kerberos v5 authentication cannot be used, however, certificates can be.
If one of the peers (or both of them) is running on a non-Windows computer, then Kerberos v5 authentication might not be able to successfully negotiate. In this case using certificates will work well.
And, if you already have a robust PKI system up and running and are used to using certificates, this is also a good way to go.

When Do I use Kerberos v5?
So, with all of this, when would we use Kerberos v5? Typically, Kerberos v5 is the authentication method of choice for Active Directory domains and forests, simply because it comes for free and is fairly automatic.

What About Pre-Shared Keys?
Using pre-shared keys is a bad idea because both parties must know the key and therefore can accidentally divulge the key to the wrong person. In large IPsec deployments this means either that al peers use the same key (meaning you have X number potential leaks) or that each peer-pair must have a unique key (which is a management night mare).

IPsec And…? - Using IPsec With Other Encryption Methods

2005-06-03T04:51:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

The question is “What combinations of security protocols can be used with IPsec and which ones cannot?” It’s a fair questions and reasonable given that your IT environments can be rather heterogeneous and use PKI, PGP, IPsec, SSL, and WKWE (Who-Knows-What-Else).

IPsec + [ SSL || PGP ||?]= Yes
As mentioned in an earlier article, IPsec and SSL are friends and you can use them in combination with no difficulties. This is true because SSL encrypts the data that will go into the IP Datagram that IPsec will, in turn, encrypt. So you get double encryption.

IPsec + PKI= Yes (and No)
If you are using PKI (asymmetric key cryptography) at the Application Layer, then Yes, for the same reasons as SSL and PGP are compatible.

However, the answer to the question “Can I use PKI keys in IPsec to encrypt the ESP Payloads?” is a definite No. The Windows implementation of IPsec uses a set of predefined algorithms for data integrity (MD5 or SHA1) and encryption (DES or 3DES) and PKI is not one of them. The reason for this is that PKI (asymmetric) keys are not suitable for bulk data encryption, due to performance and other reasons, however they are can be used to authenticate the end points (hosts).

The Difference Between IPsec and Firewalls

2005-05-19T22:58:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

At first glance (and second glance too) IPsec and firewalls seem to fulfill the same technological niche, or at least significantly overlapping niches.

Indeed this impression is partially true and caused some confusion as we battle to understand the subtleties of both technologies. So what are the differences between IPsec and firewalls that make them complimentary cousins in the network security world?

What Firewalls Do Best - Centralization
Firewalls monitor incoming and outgoing traffic to determine whether the traffic is allowed. More specifically, firewalls monitor the ports and protocols that the traffic originates from and is designated for, to determine the traffic’s “acceptability” before allowing the traffic through. Basically firewalls are border guards that check the passports of any packets coming into, or going out of, the networks they are protecting. If they don’t see the right stamps in the passports, they quote the Black Knight from Monty Python and the Holy Grail, “None shall pass!”

Firewalls can be set up and configured quickly and rules for allowing traffic can be changed easily and without having to distribute policies as is necessary with IPsec. This makes firewalls a popular choice for network protection.

What IPsec Does Better Than Firewalls - Encryption and Flexibility
However, firewalls do not secure the actual traffic going back and forth - IPsec (using ESP) does. Firewalls protect a network and not specific servers or groups of servers, thus they do not have the flexibility that IPsec and server and domain isolation provide. Also, firewalls, because they are centralized, can become a traffic bottleneck if you have a lot of traffic going in and out of your network. However, IPsec is computer-specific and once authentication happens, the rest of the negotiation and traffic is between one computer and another (IPsec doesn’t do multicast). This means, other than the negotiation phases, IPsec does not significantly reduce the overall traffic efficiency in your environment.

Difference In Default Behavior
By default a firewall is closed unless opened and it will drop packets until told to not drop them. IPsec, however, has no default behavior - it just sits there doing nothing until you tell it to do something. [In a technical sense, the IPSEC Service is always running and always doing things, like looking at traffic and then realizing it has no rules to match the traffic against - but this is a lot of busy work until it has a policy on the computer to run against].

Centralized vs. Distributed
The central and most important distinction between firewalls and IPsec is one of centrality vs. distribution. Firewalls are central and operate on all traffic the same way, whereas IPsec is distributed and the way you design your IPsec policies and distribute them determines the “distribution of protection” in your environment. [When you use AD to distribute IPsec policies, you are using “centralized distribution” and getting the best of both worlds]

Cause For Confusion
“But,” the question is, “why do we not have many problems with setting up, configuring and troubleshooting firewalls, but we just can’t get this IPsec thingy figured out?” One part of the answer is that IPsec is highly flexible. In fact, it is this highly-flexible nature of IPsec that can make policy creation and configuration a “nerd” chore. With a firewall you set it up with the standard exceptions and any customizations you need and you plug it in - voila, it is working. With IPsec you have to create rules with filter lists and actions and then add these to a policy, and then distribute them and...

Another part of the answer is that IPsec is much newer than firewall technology and the operational “bugs” have been sorted out and the learning curve flattened with time. IPsec hasn’t had enough time in the field for this curve to begin to flatten. Also, IPsec hasn’t gained the type of market-share that firewalls have (although it is catching up), so there isn’t as much experience in the field as with firewalls. This means there are fewer experts and fewer newsgroups and blogs, etc.

Thirdly, the similar nature of these two complimentary technologies can cause some confusion itself. “Do I use a firewall or IPsec?” is one of the questions being batted about. The answer is “Use both.”

Both Are Important To The Security Of Your Environment
Because you need both centralized protection and flexible protection, you need both a firewall AND domain and/or server isolation using IPsec.

NAT-T Overcomes NAT and IPsec Problems

2005-04-30T01:18:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

The last post talked about how NAT and IPsec don’t work well together. There is a solution, however, in NAT Traversal or NAT-T. Basically, NAT-T (IETF RFC 3947 and 3948) detects the presence of any NAT devices between two hosts, uses a non-IPsec port and encapsulates the IPsec traffic in UDP. NAT-T does this by inserting an additional header between the IP header and the ESP header. This header contains the original source and destination ports.

About NAT
Network Address Translation (NAT) was developed to answer the impending problems of the dwindling supply of IPv4 addresses (there can be “only” 4 billion of them, plus some spare change) and the nightmare of having to centrally distribute and manage off of these IP addresses. This must be done centrally so that everyone has an absolutely unique address. These two problems make using all unique IPv4 addresses impossible.

So certain IP address ranges were set aside (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) for “private” addresses that companies could use freely inside their domains. These private addresses were then used behind a “public” and unique IP address (centrally managed). This public IP addresses is the one you register with InterNIT or some other IP address distribution organization or company.

NAT was developed as a way of solving the problem that Bob inside company A would have the same private address as Alice inside company B. NAT also is a way of mapping the internal / private addresses with the public / unique address so that Bob and Alice can communicate across the Internet, even though they have the same IP addresses. How NAT does this is beyond the scope of this post.

How NAT-T Solves the Problems Between IPsec and NAT
In the same way that NAT was a solution to the IP addresses problems of IPv4, NAT-T is a solution for the problems between IPsec and NAT mentioned earlier. In this ever-dynamic game of technological cat-n-mouse, the IETF has come up with RFCs that define how NAT-T does this.

The heart and soul of NAT-T is UDP Encapsulation, or the encapsulation of the IPsec part of the IP packet in yet another UDP header between the ESP portion of the packet and the (copied and subsequently changed) original IP header. That way the NAT device can access and change the IP address and port number information.

NAT-T also allows two additional benefits. To quote form the OSR Online article:

“After IKE peers initiate negotiation on port 500, detect support for NAT-traversal, and detect a NAT or NAPT along the path, they can negotiate to "float" IKE and UDP-ESP traffic to port 4500…Floating to port 4500 for NAT traversal provides the following benefits: It bypasses "IPSec-aware" NATs or NAPTs that break UDP-ESP encapsulation on port 500 [and] It improves performance. The UDP encapsulation of ESP data packets is more efficient on port 4500 than on port 500.”

Sources For This Post
I want to acknowledge the following Web sites/Organizations for the information I stole gleaned form their sites:

OSR Online, strangely enough, a Web site about Windows Driver development, (www.osronline.com). the information about NAT-T was well written and concise. The article I read was “Traversing NATs and NAPTs with UDP-Encapsulated ESP Packets” - http://www.osronline.com/ddkx/network/209offl_4tev.htm

ISP Planet (www.isp-planet.com). The articles I read were:
“Slipping IPsec Past NAT” - http://isp-planet.com/technology/2001/ipsec_nat.html
“IP Security and NAT: Oil and Water?” - http://www.isp-planet.com/technology/nat_ipsec.html

Why NAT and IPsec Don't Like Each Other [Updated 4.29.2005]

2005-04-27T01:43:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

If you have ever ready articles on IPsec or NAT (Network Address Translators) and heard that IPsec can’t be used with NAT but were never told specifically why, then this post is for you.

Why NAT is A Problem for IPsec
As you might recall, IPsec (whether AH or ESP) uses a cryptographic hash value [called the Integrity Check Value (ICV) or the has-based message authentication code (HMAC)]. This has is used by the IPsec end points for data integrity. The end point runs its own has on the some of the parts of the IP packet it receives (it can do this because the end points both know the symmetric key) it then compares the has it received with the has it just created. If they are not the exact same, IPsec drops the IP packet and goes on with its life (it will generate an event if IPsec auditing is configured).

=== The paragraph below was updated 4.29.2006 ===

The problem with NAT is that this hash includes the IP addresses (in AH) and the ports used (in ESP). This means when NAT changes the IP addresses or ports in the IP header, it cannot re-calculate the hash because it is not knowledgeable about the key. IPsec will see that the hash value in the packet does not match the one it calculates and IPsec drops the packets. In ESP the NAT device cannot access and change the port information inside the encrypted TCP headers of the packets.

The Value of Domain Isolation (Part 2)

2005-04-26T23:52:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

Simplicity
Rather than using a dozen different tools, maintaining a handful of configuration files, running scripts on local computers and who-knows-what-else to achieve better security IPsec is centrally managed and policies distributed by Active Directory using one tool the MMC console and the IP Security Policies on Active directory and Active Directory snap-ins. All you have to do is create the IPsec policy on the DC and drag them over the domain folder or OU folder. Bodda-bing your done. AD will automatically distribute the new policy automatically during the next policy push.

Need to change an IPsec policy? Simply change it on the DC and AD will automatically distribute the new policy automatically during the next policy push.

Application Agnostic
Unlike SSL encryption, which requires end-point applications, such as Internet Explorer, to implement it, IPsec is “application-agnostic”, or more correctly applications are “IPsec-agnostic”.

This is because all of the IPsec magic happens on Internet layer (roughly the Transport and Network OSI layers) and applications run on the application layer (roughly the Session, Presentation and Application OSI layers). IPsec gets packets from applications, adds its little header, does the hash thing ( and some other operations if you are using ESP or tunneling) and sends them on their way to the NDIS layer (Data-link OSI layer).

When IPsec packets come in, IPsec gets them from the NDIS layer, removes the header (and performs a few other operations, like checking the hash in the packet with it’s own calculated hash) and hands it up to the Application layer. Applications are not even aware that IPsec is there and they frankly don’t care either. This means that deploying domain isolation is not hindered by your applications (except for certain network packet inspectors and intrusion-detection software. [Interestingly, you can run SSL and IPsec (ESP) together just fine.]

Hardware Agnostic (mostly)
To quote “Microsoft Windows Server 2003 TCP/IP Protocols and Services - Technical Reference” (an awesome book) by Joseph Davies and Thomas Lee - Microsoft Press, page 611:

“IPSec is an end-to-end security technology; the only nodes aware of the presence of IPSec are the two IPSec peers that are communicating. Intermediate routers have no knowledge of the security relationships and forward the IP packets, as they would any other, between the communicating peers.”

This means IPsec packets will fly around the Internet or your internal network just like any other IP packets. You don’t have to adjust any settings on your hardware…mostly.

The “mostly” part is that you might have to change a few settings on firewalls. But “How to Enable IPSec Traffic Through a Firewall” (support article 233256) will guide you thought the process. The settings are mostly about enabling the IP protocol 50 and 51 and UDP port 500.

The Value of Domain Isoaltion (Part 1)

2005-04-23T01:51:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

Perhaps you are a seasoned, battle-hardened IT veteran or perhaps you’re someone who was late to the meeting where they were assigning someone to be the “IT guy” and you, my friend, were the ~~scapegoat~~ lucky individual. Maybe your IT environment is a dozen or some servers and a handful of desktops or perhaps it is 10,000 servers and 100,000 desktops. Your staff might be you and your iPod or it might be over 30 people. It’s tough work - not for the timid. But you are part of the few, the proud, the elite, the nerd patrol. You are an “IT guy (or gal)” and proud of it - pocket-protector jokes aside.

You struggle constantly to maintain a fine and delicate balance between meeting SLAs, keeping expenses down, hiring and retaining the best people, reducing TCO, and ~~not getting busted by~~ diligently and happily conforming to HIPPA, SOX or some other regulation… oh, yea, and maintaining our sanity and hopefully getting to go home and see your family before your two-year old graduates from college.

So you have to weigh carefully each and every script, option, tool, product, process and change that comes down the pike (unless of course the powers-that-be have “reduced your decision-making overhead”). So amidst this storm of challenge and option, what is the value to you, your staff, your IT environment and the bottom line, of domain isolation?

Better Security
In these days, we are all looking for better ways to keep out the bad guys, whether at home while using IM or at work, guarding a multi-million dollar network. We put up firewalls, specially configure routers, tweak ACLs, create and enforce stringent policies, etc. “Defense in Depth” is the slogan of this new world and you are constantly looking for ways to batten down the hatches. There is good news in al of this - domain and server isolation can help… a lot.

A good deal of the threat out there is unknown computers connecting to and “leveraging” your IT computers. Domain isolation provides a rather simple and inexpensive way to mitigate this threat. Computers must authenticate themselves and be able to negotiate successfully before connecting to computers in your domain(s).

Lower TCO
Total Cost of Owning Stuff (the “S” is silent) reduction is all the rage in these days of shrinking IT budgets. “Do more with less” is the battle cry. How about “Do more with nothing”? To quote the “Introduction to Server and Domain Isolation with Microsoft Windows” paper again:

“Everything that you need to create an isolated network is already available on computers running the Microsoft® Windows® XP, Microsoft® Windows Server™ 2003, and Microsoft® Windows® 2000 Server operating systems. All that you need to do is to ensure that computers are members of your domain and to configure the appropriate Group Policy settings to require authentication for incoming communication attempts, to secure data traffic, and optionally, to encrypt data traffic. After you have applied the appropriate Group Policy settings, you add a new computer to the isolated network by making it a member of the Active Directory domain. No new hardware is required.”

So, the initial cost of domain isolation is.. well $0 (unless you have to upgrade some servers or desktops). Good so far, but TCO isn’t just about initial cost, the real metric is what between when you hit the Finish button and you retire the software in favor of something better - or you retire in favor of something better. How about maintaining, changing, adapting, and fixing domain isolation? Huh, what about that, huh?

The cool thing about domain isolation is that Active Directory does the heavy lifting (it even has one of those special belts). Need to change an IPsec policy or two? Let AD distribute them using GPO. Need to add the policies to new desktops, again send errand-boy AD.

Flexibility and Power
Domain isolation, as documented in the white papers mentioned the other day, is relatively simple to design, deploy and maintain. But what if my IT environment requires more complex policy than that? What if I have to allow communications between IPsec and non-IPsec computers? What if I have network hardware/software that doesn’t “like” IPsec (like NAT devices)?

There is more good news - domain isolation is simple and flexible. You can apadpt your IPsec policies and have AD manage them for you. In some situations, you can also create local policies. But IPsec can handle it.

Resources For More Complex Deployments (in order of ascending nerd-factor)
"Interoperability Considerations for IPsec Server and Domain Isolation"
This paper describes interoperability between IPsec-secured hosts running Windows Server 2003, Windows XP with Service Pack 2 (SP2), and Windows 2000 Server with Service Pack 4 (SP4) in a domain or server isolation scenario and hosts that cannot use IPsec, including computers running earlier versions of Windows or non-Microsoft operating systems. It is intended for IT professionals in organizations that are investigating using IPsec in Microsoft Windows to deploy server and domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=10359569-EF11-499A-9E1F-85DA3FCA608C&displaylang=en

"Improving Security with Domain Isolation"
This is a rather detailed write-up of how Microsoft IT deployed domain and server isolation. There is a lot of good advice and best practices in here from the folks who not only know IT but also have some rather close connections with the folks who actually wrote the code in Windows (wink).
http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx

“Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server”
This is a huge whitepaper from the folks at Foundstone (www.foundstone.com) and Microsoft that goes into glorious detail and scope all about IPsec including conceptual all the way to step-by-step.
Note - This is a serious, lift-with-your-legs white paper and not for the timid. IF you are relatively new to IPsec, I would strongly suggest you start with the domain isolation introduction paper I mentioned the other day.
http://www.microsoft.com/downloads/details.aspx?FamilyID=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en

“Server and Domain Isolation Using IPsec and Group Policy”
This is a PDF document that uses the fictitious Woodgrove Bank as a platform to document server and domain isolation is the type of detail and scope that inspires shock and awe, or at least awe. The “The Business Benefits” section on page 12 is a good one to look at and I promise I didn’t steal anything from there (wink). The doc also comes with installable tools and templates. The readme.txt file has a list of the files.
Note - This is a serious, lift-with-your-legs white paper and not for the timid. IF you are relatively new to IPsec, I would strongly suggest you start with the domain isolation introduction paper I mentioned the other day.
Another Note - you have to register with Microsoft to get this whitepaper and you must have a Passport account to do so.
http://www.microsoft.com/downloads/details.aspx?FamilyId=404FB62F-7CF7-48B5-A820-B881F63BC005&displaylang=en

What the Heck is 'Domain Isolation'?

2005-04-22T03:31:00Z

====================== DISCLAIMER ====================
This posting is provided "AS IS" with no warranties, and confers no rights.
====================================================

To answer this let me quote from the “Introduction to Server and Domain Isolation with Microsoft Windows” document listed below:

“With the Microsoft® Windows® operating systems, you can logically isolate your domain and server resources to limit access to authenticated and authorized computers. For example, you can create a logical network consisting of computers that share a common security framework and a set of requirements for secure communication. A logical network is a group of network nodes that is independent of the physical network topology. For example, with virtual LAN (VLAN) technology, you can create logical networks by grouping computers regardless of their physical connection to a set of switches. Each computer on the logically isolated network can provide authentication credentials to the other computers on the isolated network to prove its membership. Requests for communication that originate from computers that are not part of the isolated network are ignored.

Isolating and logically grouping computers occurs at Layer 3 (the Network layer) of the Open Systems Interconnection (OSI) model. Therefore, the isolated network can span hubs, switches, and routers across the physical and geographical boundaries of your organization network”

Domain Isolation
Basically, you create a barrier between your domain members and non-members by using IPsec policies. Computers inside your domain can talk to one another with no problems but outside computers cannot initiate communication with your domain members. Basically, all you do is create IPsec policies and distribute and assign them using AD. Of course there are a few steps involved in the process (and some great documentation for domain isolation), but that’s really all you do.

Does It Really Work?
Yup! In fact Microsoft has deployed IPsec across several domains (including the largest one). I didn’t even notice it. No bumps, hiccups, outages, no problems. (the “Improving Security with Domain Isolation” document covers the whole experience). I have set this up in a lab (using Virtual Server over Remote Desktop) and it went without a single significant problem.

Domain Isolation White Papers
This first post has been a really brief overview (I have to get back to work - wink), but there are a whole set of brand spanking-new white papers available from Microsoft on planning and deploying domain isolation. Unfortunately, they are damn-near impossible to find (they’re fixing this soon), so I will list them here:

"Introduction to Server and Domain Isolation with Microsoft Windows"
This is the place to start if you are new to IPsec or domain isolation. Also, at the end of the paper is a roadmap to all the other domain isolation docs (quoted in part below).
http://www.microsoft.com/downloads/details.aspx?FamilyId=F9D90728-1D76-4A73-8225-CE3A059B5638&displaylang=en

"Domain Isolation with Microsoft Windows Explained"
This paper provides a detailed overview of domain isolation. It explains how domain isolation protects domain member computers and the benefits of deploying domain isolation. It also provides a brief overview of how to deploy domain isolation. This paper is intended for IT professionals in organizations that are investigating using the Microsoft implementation of Internet Protocol security (IPsec) in Windows to deploy domain isolation. It assumes that you are somewhat familiar with the Microsoft implementation of IPsec and would like more detailed information about using that technology to deploy domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=FFC03439-10B8-4476-9527-4B67F90CFFF5&displaylang=en

"Server Isolation with Microsoft Windows Explained"
This paper provides a detailed overview of server isolation. It explains how server isolation protects isolated servers and the benefits of deploying server isolation. It also provides a brief overview of how to deploy server isolation. This paper is intended for IT professionals in organizations that are investigating using the Microsoft implementation of IPsec in Windows to deploy server isolation. It assumes that you are somewhat familiar with the Microsoft implementation of IPsec and would like more detailed information about using that technology to deploy server isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=15E5FC29-B52C-41A4-9EE5-D95916FFE53E&displaylang=en

"Domain Isolation Planning Guide for IT Managers"
Designed for enterprise IT managers who are investigating using IPsec in Microsoft Windows to deploy domain isolation, this paper will help you and your IT staff to gather the information required to develop a domain isolation deployment plan and to design your IPsec policies. It includes an overview of the deployment process, a step-by-step guide to the planning process, and links to resources that you can use to plan and design your deployment. It does not explain how to deploy domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=495E8245-F977-4BB4-9D17-A6B9B3E3F56F&displaylang=en

"A Guide to Domain Isolation for Security Architects"
Designed for network architects of enterprise organizations that are investigating using IPsec in Microsoft Windows to deploy domain isolation, this paper describes the implications of deploying domain isolation in an enterprise environment and explains how to assess the enterprise environment and plan domain isolation. Read this guide after you have developed a working knowledge of domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=07AD33AA-F5B3-401F-BD91-DF06F1E23077&displaylang=en

"Setting Up IPsec Server and Domain Isolation in a Test Lab"
This paper demonstrates how to set up IPsec domain and server isolation in a limited test environment. It provides procedures for setting up a basic deployment, which you can use as the basis for your own deployment. This paper is designed for network architects who are investigating using IPsec in Microsoft Windows to deploy server and domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=5ACF1C8F-7D7A-4955-A3F6-318FEE28D825&displaylang=en

"Interoperability Considerations for IPsec Server and Domain Isolation"
This paper describes interoperability between IPsec-secured hosts running Windows Server 2003, Windows XP with Service Pack 2 (SP2), and Windows 2000 Server with Service Pack 4 (SP4) in a domain or server isolation scenario and hosts that cannot use IPsec, including computers running earlier versions of Windows or non-Microsoft operating systems. It is intended for IT professionals in organizations that are investigating using IPsec in Microsoft Windows to deploy server and domain isolation.
http://www.microsoft.com/downloads/details.aspx?FamilyId=10359569-EF11-499A-9E1F-85DA3FCA608C&displaylang=en

In addition to these, Microsoft IT has a rather detailed and comprehensive paper on how they deployed domain isolation - "Improving Security with Domain Isolation"
http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx