The Value of Domain Isolation (Part 2)

====================== 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.