IP
Security (IPSec), mentioned briefly in previous sections, is
essentially a mechanism for establishing end-to-end encryption of all
data packets sent between computers. IPSec operates at Layer 3 of the
OSI model and subsequently uses encrypted packets for all traffic
between members.
IPSec is often considered
to be one of the best ways to secure the traffic generated in an
environment, and is useful for securing servers and workstations both in
high-risk Internet access scenarios and also in private network
configurations for an enhanced layer of security.
Understanding the IPSec Principle
The basic principle of IPSec
is this: All traffic between clients—whether initiated by applications,
the operating system, services, and so on—is entirely encrypted by
IPSec, which then puts its own header on each packet and sends the
packets to the destination server to be decrypted. Because every piece
of data is encrypted, this prevents electronic eavesdropping, or
listening in on a network in an attempt to gain unauthorized access to
data.
Several functional IPSec
deployments are available, and some of the more promising ones are
actually built in to the network interface cards (NICs) of each
computer, performing encryption and decryption without the operating
system knowing what is going on. Aside from these alternatives, Windows
Server 2008 R2 includes a robust IPSec implementation by default, which
can be configured to use a PKI certificate network.
Detailing Key IPSec Functionality
IPSec
in Windows Server 2008 R2 provides for the following key functionality
that, when combined, provides for one of the most secure solutions
available for client/server encryption:
Data privacy—
All information sent from one IPSec machine to another is thoroughly
encrypted by such algorithms as 3DES, which effectively prevents the
unauthorized viewing of sensitive data.
Data integrity—
The integrity of IPSec packets is enforced through ESP headers, which
verify that the information contained within an IPSec packet has not
been tampered with.
Anti-replay capability—
IPSec prevents streams of captured packets from being resent, known as a
“replay” attack, blocking such methods of obtaining unauthorized access
to a system by mimicking a valid user’s response to server requests.
Per-packet authenticity—
IPSec utilizes certificates or Kerberos authentication to ensure that
the sender of an IPSec packet is actually an authorized user.
NAT Traversal—
Windows Server 2008 R2’s implementation of IPSec now allows for IPSec
to be routed through current Network Address Translation (NAT)
implementations, a concept that will be defined more thoroughly in the
following sections.
Diffie-Hellman 2048-bit key support—
Virtually unbreakable Diffie-Hellman 2048-bit key lengths are supported
in Windows Server 2008 R2’s IPSec implementation, essentially ensuring
that the IPSec key cannot be broken.
Exploring IPSec NAT Traversal
As previously mentioned,
IPSec in Windows Server 2008 R2 supports the concept of Network Address
Translation Traversal (NAT-T). Understanding how NAT-T works first
requires a full understanding of the need for NAT itself.
Network Address
Translation (NAT) was developed simply because not enough IP addresses
were available for all the clients on the Internet. Because of this,
private IP ranges were established (10.x.x.x, 192.168.x.x, and so on) to
allow all clients in an organization to have a unique IP address in
their own private space. These IP addresses were designed to not route
through the public IP address space, and a mechanism was needed to
translate them into a valid, unique public IP address.
NAT was developed to fill
this role. It normally resides on firewall servers or routers to provide
for NAT capabilities between private and public networks. Routing and
Remote Access Service (RRAS) for Windows Server 2008 R2 provides NAT
capabilities as well.
Because the construction of
the IPSec packet does not allow for NAT addresses, IPSec traffic has, in
the past, simply been dropped at NAT servers, as there is no way to
physically route the information to the proper destination. This posed
major barriers to the widespread implementation of IPSec because many of
the clients on the Internet today are addressed via NAT.
NAT Traversal (or
NAT-T), which was introduced in Windows Server 2008 and is available in
Windows Server 2008 R2’s IPSec implementation, was jointly developed as
an Internet standard by Microsoft and Cisco Systems. NAT-T works by
sensing that a NAT connection will need to be traversed and subsequently
encapsulating the entire IPSec packet into a UDP packet with a normal
UDP header. NAT-T handles UDP packets flawlessly, and they are
subsequently routed to the proper address on the other side of the NAT.
NAT Traversal works well but
requires that both ends of the IPSec transaction understand the protocol
so as to properly pull the IPSec packet out of the UDP encapsulation.
With the latest IPSec client and server, NAT-T becomes a reality and is
positioned to make IPSec into a much bigger success than it is today.
Note
NAT-T was developed to keep
current NAT technologies in place without changes. However, some
implementations of NAT have attempted to make IPSec work natively across
the translation without NAT-T. Disabling this functionality with NAT-T
might not be wise, however—it might interfere with IPSec because both
NAT-T and the NAT firewall will be attempting to overcome the NAT
barrier.
